《软件工艺》——译者序

(《软件工艺》一书即将由人民邮电出版社出版,详情参见http://www.china-pub.com/computers/subject/huodong/ry12.23/tyzt.htm。本文是我作为译者为本书所作的序言。)

译序

时隔一年之后,当我再次到AMAZON寻找这本《软件工艺》时,它的评价不知何时已经悄悄地变成了四星半,销售排行也已经到了5,000多名——熟悉AMAZON的读者应该知道,在AMAZON能得到四星半评价的已经是精品好书,四位数的销售排行就更能证明它的品质。可是,一年前看到的批评仍然历历在目:“过时的例子”、“混乱的逻辑”、“东拉西扯不知所云”……当这些尖锐的言辞与“所有软件管理者的必读书目”一类溢美之词并列时,我不得不再次认真地思索:这究竟是一本怎样的书?

Pete McBreen说,这本《软件工艺》是一本“极具煽动性”的著作。而在我看来,用“煽动性”来评价它只嫌太客气,或许“颠覆性”会是一个更贴切的词。自1968NATO会议以降,软件工程的话语就始终把持着软件业(以及软件学科)的言路。一切的软件问题都不由自主地被归咎于“软件危机”,同样自然地,一切的解决方案都不由自主地被划入“软件工程”的范畴。从记事以来……呃,我是说,从上大学以来,我们的一切讨论都围绕着软件工程展开:这样做是否符合软件工程?如何对软件工程加以改进?企业应该如何开展软件工程?凡此种种。在语词的不断重复与变调之间,“软件工程”逐渐被捧上了神坛,成为一种信仰,并因此失去了它旧有的价值与意义。君不见,即令是软件工程的反对者,也只能说出“我们不要软件工程”这样的话——仍然未脱软件工程的话语霸权。

Pete McBreen是一个极其敏锐的人,并且对语词背后的意蕴有着深刻的体认,这或许与他年少时在英国所受的教育有关吧。他一针见血地指出:软件并不是工程,“软件工程”仅仅是一个多少有些不够贴切的隐喻而已。是的,一个隐喻,正如我们常说的“桌子腿”、“针眼”一样,这是一个深入人心、渗透极广的隐喻。但是,尽管每个人都知道绣花针并没有长眼睛,我们却常常忘记了软件工程作为隐喻的本来身份,真心诚意地把软件作为一种工程来对待了。软件工程的困境与读到这本《软件工艺》时本能的拒斥,殆出于此。

钱钟书曾说,反其道以行也是一种模仿。而对于目前软件工程的反对者们,另一个更恰当的比喻是“反转的胶片”——胶片的颜色与照片完全相反,但两者记载的信息却是毫无二致。作为一个真正意义上的颠覆者,Pete McBreen为软件开发找到了另一个隐喻(以及随之而来的另一套语词),那就是本书的标题——软件工艺(software craftsmanship)。

对于这套工艺学的语词,我一直有着淡淡的隐忧。在西方,工艺学传统多半与文艺复兴的人本主义联系在一起,而在对现代性的反动中,文艺复兴一直是吸引大众的旗帜。因此,可以想象,“软件工艺”这样一个隐喻对于欧美程序员有着不可抵挡的诱惑。而在中国,“学而优则仕”的传统价值观固有地鄙薄工艺学的实践者,“五四”以降现代性的话语又早已根深蒂固,所以我实在不敢乐观地期望这个译本的读者能够让“软件工艺”的思想畅行无阻。好在Pete McBreen并不是一个太喜欢夸夸其谈的作者,书中的论述虽然大胆,却是有理有据。既然Fred Brooks的“没有银弹”已经深入人心,相信以逻辑思维见长的软件开发者们能够抛开对软件工程的迷信,随作者一道认识软件工程的局限,并由此生发对软件工艺的思索。倘如此,这本书也就算不辱使命了。

在你开始正式阅读本书之前,请允许我给你打一针预防针:这本书可能颠覆你浸淫其中数年甚至十年的软件观,所以书中的很多观点可能让你感到出离惊奇甚至出离愤怒。请你不要马上把它扔到墙角去,阅读的过程也就是习惯一种话语方式的过程。当你逐渐习惯软件工艺的话语方式之后,或许能从中找到一些自己需要的东西。

为这个译本,我要感谢UMLChina的站长潘加宇,是他把这本书硬塞到我的手上,让我没有与这本精彩的著作失之交臂。我还要感谢我的女友、本书的合译者马姗姗,她优雅的文笔弥补了我言辞的生涩,她的支持与鼓励让我能够在工作之余顺利完成此书的翻译。谢谢你,亲爱的姗姗。

最后,希望你能从这本《软件工艺》中找到别样的触动和欣喜——就像我曾经的阅读体验。

熊节

200389日星期六 凌晨

杭州

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
This book asks some tough questions. Is software engineering appropriate for projects of less than 100 developer-years? Is the specialization inherent in software engineering a good idea? Can software development even be expressed in engineering terms? It also asks some sensitive ones: Are less experienced developers paid too much, and should senior developers be paid more than almost anyone else in their organization? Should tools that are less than ten years old be used on long-term projects? And at its heart, this book asks the big question: How can we reorganize the process of building software so that it works? The book has some controversial answers: It suggests that we've lost sight of a simple truth—large methodologies and formal structures don't write software; people do. To fix a growing crisis in software development, we need to start by producing better developers. To do that, Pete looks back to a system that has worked well for hundreds of years—craftsmanship. Craftsmanship is far more than a tag for high-quality work. In the full meaning of the word, craftsmanship is a self-sustaining system in which masters arrange for the training of their replacements and where status is based purely on the work you've done. Apprentices, journeymen, and craftsman all work together as a team, learning from each other. Customers select these teams based on the team's reputation, and teams accept only work that they feel will enhance their reputation. Can this full system of craftsmanship work in our industry? Frankly, I don't know. Many entrenched interests will certainly oppose the idea. But I do know that being apprenticed to masters works. It worked for me. I was lucky enough to attend a great university, where I learned much theory (there was less theory back then). What really made the experience shine, however, was an apprenticeship that I served. One of the graduate students took me under his wing. He didn't explicitly teach me, but he showed me by example how a great programmer thinks. Working next to him month after month, I absorbed more practical knowledge about design, coding, and debugging than any course could impart. Later, I joined a start-up in London where I served a different sort of apprenticeship. My new boss showed me that software development was as about people as it was about technology. He helped me understand the business side of the equation and taught me how great development builds personal relationships from a base of technical strength. I “graduated” from these two very different apprenticeships a far, far better developer than I started out. Based on my personal experience, I'm a believer. Working with masters is the best way to learn a craft. This book offers more than ideas about training the next generation of developers. It is also about a philosophy. Craftsmanship stands for taking personal responsibility: for your work, for your personal development, and for your profession. It doesn't matter how you develop software. You could be working 9-to-5 in a CMM level 5 shop, or you could be pulling 100-hour, caffeine-drenched weeks developing the next cool first-person shooter. You could use RUP, XP, or SCRUM—or no process at all. Whatever the structure of your work, the real value in software development is added when skilled developers write high-quality, appropriate code, delivering what the customer needs. Methodologies don't produce these skilled developers. Honoring and practicing craftsmanship, along with the other ideas in this book, just might. You'll do yourself and your career a favor if you spend some time with Pete McBreen's tough questions. David Thomas The Pragmatic Programmers

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值