《软件工艺》——前言

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

前言

用“工艺学”来比喻软件开发,这可以看成是对软件开发的一次追根溯源:优秀的软件开发者们一直都知道,编程的确就是一门工艺技巧。不论软件开发者拥有多少纷繁芜杂晦涩难懂的知识,但最终左右着应用程序开发的仍是那种不可言说的感觉和经验。举个最简单的例子:也许有人能够了解Java语言所有深奥幽暗的技术细节,但除非这个人能培养起自己对于软件的审美感觉,否则他永远无法真正精通应用程序的开发。而与此相反,一旦某个人获得了那种软件开发的感觉,特定的技术细节就变得几乎完全无关紧要了。优秀的开发者总是在不断地学习、使用最新的技术和技巧,对于他来说,学习一门新的技术只是软件开发者生涯中的家常便饭而已。

“软件工程”这个词是由NATO属下的一个研究组在1967年提出的,这个研究组还提议召开一次会议,专门讨论“软件所面临的问题”。1968年,由NATO科学委员会主办的这次会议在德国迦米许*召开,会议提交的报告就被命名为《软件工程》[1]。在这份报告中,Peter NaurBrian Randell这样写道:“我们之所以选择了‘软件工程’这个颇具争议性的词,是为了暗示这样一种意见:软件的生产有必要建立在某些理论基础和实践指导之上——在工程学的某些成效卓著的分支领域中,这些理论基础和实践指导早已成为了一种传统教义。”

和他们一样,本书之所以选择了这样一个颇具争议性的书名(并提出了很多颇具争议性的观点),是为了暗示这样一种意见:软件开发的实践者们有必要开始关注软件开发的工艺。软件工艺是如此重要,因为它让我们摆脱“制造业”的隐喻(这个隐喻正是软件工程所带来的),并让我们开始关注从事软件开发工作的。软件工艺带来了另一种隐喻:拥有技术的软件开发者抱定决心要掌握自己所从事的工艺,对自己的劳动成果负责并以之为荣。

软件工艺并非与软件工程或者计算机科学针锋相对格格不入。与科学和工程学相比,软件工艺是另一种完全不同的教义,但又能与这两者很好地共存,并从中获益。现代的铁匠能够因为更好的工具、原料和知识而获益;同样,软件工艺也能够因为更好的计算机、可复用的组件和更先进的编程语言而获益。铁匠们在自己的工作中融入了技巧和艺术,从而超越了科学和工程学的范畴;同样,软件工艺能够指导开发者生产出优秀的应用程序及系统,因此也可以超越计算机科学和软件工程学的范畴。对于这一论点,最好的佐证大概就是UNIX和现在的GNU Linux了——这两个系统之所以能够获得如此巨大的成功,完全是因为它们的创建者拥有精巧的手艺、高超的技术和无私的奉献精神。

很长时间里,人们一直试图强迫商用软件的开发适应软件工程的要求。这种削足适履的做法引发了不少的问题,而软件工艺则给这些问题带来了答案。软件工程的发展,很大程度上是为了满足NATO成员国开发超大型国防系统的需要。而商用软件的开发与军用系统、政府系统的开发却有着天壤之别:商用软件的规模通常比较小,并且开发时间通常不能超过18个月。只有极少数商用软件是由超过20人的团队所开发的,大多数开发团队都不会超过10人。对于拥有200人以上的大型团队,软件工程能够很好地解决他们所遇到的问题;但对于“团队中的个人应该如何锻炼自己的技艺”这个问题,软件工程却几乎没有任何论述。

软件工程鼓励在软件开发中使用人海战术[2]。软件工程不但没有解决“如何培养拥有高超技艺的开发者”这个问题,反而试图降低对软件开发工作的技术要求——软件工程认为:只要投入更多的人手,所有的问题都可以得到解决。这实际上就是在暗示:如果可以拥有大量技术水平较低的开发者,那么我们就不需要那些技术超群的“高手”。

尽管人海战术有时能够成功,但最终得到的软件多半也是垃圾:它们多半臃肿迟钝,总是无法令人满意。用户被眩目的图片和动画搞得晕头转向,但就是无法真正掌握软件的用法。由于无力学会使用整个软件,他们会有强烈的挫折感,并只使用很小一部分功能来满足自己的需要,而更多的功能则根本无人问津。

软件不一定非得要像这样的。

我时常看到这样的软件开发团队:他们开发出真正有价值的应用程序、为用户的业务提供了实实在在的帮助,却因为没有遵循软件工程的最佳实践而懊恼不已。其实,他们大可不必这样想。在我看来,唯一能够检验团队能力的标准,就是看他们能否按时发布用户需要的软件、并在随后的时间里不断地补足、扩展这个软件。按时发布第一个版本固然重要,但始终及时地发布后续版本、并保证每个新版本都在原来的基础上有所提升,这可能是更加重要的。

常常有人问我“如何雇佣好的开发者”。面对这个问题,我的回答总是:去找那些成功地开发过几个应用程序、并在交付后仍然留在项目组中直到下一个升级或维护版本发布的开发者。能够交付最初的产品,就说明这个人有能力开发出可用的产品;参与第二个版本的开发则使他有机会反思自己最初的开发方式带来的效果。如果某个开发者把这样的过程重复了三遍,我敢打赌他在软件开发工艺方面已经拥有了足够的技能和经验,这将使他能够继续获得成功。

在本书的书名中,我把软件工艺称为“新的渴求”。之所以这样说,是因为我发现软件开发社群中的很多人开始盲目地追逐新技术,而忘记了真正重要的东西。软件开发的终极目标是要创建出高质量的、坚固的软件程序,并使之为用户创造价值。现在,我们的当务之急就是要培养出新一代的合格开发者,让他们拥有实现这一目标的能力。

“为用户创建应用程序”的过程曾经是妙趣横生、激动人心的,但软件工程几乎完全抹杀了这种令人愉悦的体验。现在,软件工艺将把软件开发过程中的乐趣和激动重新还给软件开发者。



* 译者注:Garmish,位于阿尔卑斯山区,德国度假胜地。

[1] Peter NaurBrian Randell编辑,《软件工程》(Software Engineering: A Report on a Conference Sponsored by the NATO Science Committee),NATO1969

[2] Steven Levy,《黑客》(Hackers),Penguin Books1994p. 88

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
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值