（《软件工艺》一书即将由人民邮电出版社出版，详情参见http://www.china-pub.com/computers/subject/huodong/ry12.23/tyzt.htm。本文是Pragmatic Programmer一书的作者David Thomas为该书所作的序言。）
序言本书提出了一些相当棘手的问题。
对于工作量少于100人年的项目，软件工程仍然适用吗？软件工程与生俱来的专业化趋势真的是一个好主意吗？甚至于，软件的开发真的可以用工程学的术语来描述吗？
本书也提出了一些相当敏感的问题：那些缺乏经验的开发者，是否享受了过高的薪资待遇？那些资深的开发者，是否应该比企业中绝大多数人都拿得更多？那些出现至今还不足十年的工具，是否应该在长期的项目中使用？
在这一切的最核心处，本书提出了一个最大的问题：我们应该如何重组软件构造的过程，使其能够如我们所愿地有效运转？
对于这些问题，本书也提出了一些颇具争议性的答案：本书认为，我们一直对一个简单的事实视而不见——编写软件的，不是硕大无朋的方法学，也不是一丝不苟的组织结构，而是人。当今，在软件开发的领域中，我们正在面临一个日益严重的危机。为了扭转这种不利的局面，我们需要培养出优秀的软件开发者。而为了达到这个目的，Pete*回顾了一个数百年来一直兴旺发达的系统，并期望从中获得启示——那就是工艺学。
“工艺”这个词是一种象征，象征着高质量的产品。但它的含义却还不仅限于此。从完整的意义上来说，工艺学是一个自给的系统。在这个系统中，师傅负责安排学徒的工作和培训，而学徒也有可能取代师傅，每个人地位的高下完全取决于他生产出的产品的优劣。学徒、工人和技师，所有人都在同一个团队中一起工作，并彼此学习。顾客则根据团队的声望来做出选择，而团队也只接受那些他们认为有可能提高他们声望的工作。
在我们的产业中，这个完整的工艺学系统能起作用吗？说实话，我也不知道。许多根深蒂固的习惯都必然会反对这种“工艺学”的观点。不过，我的确知道，作为学徒接受师傅的言传身教而最终成为高手，这样的成长途径是行之有效的，因为我就经历了这样的成长过程。
应该说我很幸运，进入了一所优秀的大学，在那里我学到了很多的理论（不过，在我上大学的时候，需要学的理论比现在可少多了）。但是，真正让我的大学生活显得与众不同的，还是那段学徒经历。那时，一位研究生带着我一起工作。他并没有明确地要教给我什么，但他用实际行动让我看到了一个优秀程序员的思维方式。月复一月，我在他的身边工作，从他那里吸收了大量实用的知识。不论是设计、编码还是调试，我从他那里学到的知识比在任何一门课上学到的都多。
后来，我又在伦敦加入了一个刚刚开工的项目。在那个项目中，我扮演了另外一种学徒的角色。我的新老板用他的所作所为告诉我：软件开发不仅仅是一项技术工作，同时也是一项人文工作。他帮助我理解了软件开发中与商业相关的这一部分，并教给我如何在拥有一定技术实力的基础上建立起良好的企业人际关系。
从这两次截然不同的学徒经历“毕业”之后，作为一个开发者，我已经比开始时强了太多太多。由于拥有这样一段经验，所以我完全相信：如果要学习一门手艺，与高水平的师傅一起工作是最佳的途径。
正如我刚才说的，本书在“如何训练下一代开发者”方面提出了很有价值的观念。不仅如此，本书还涉及到了软件的哲学。工艺学所针对的是个人的能力：对你的工作，对你个人的发展，对于你的职业，工艺学能给你更多的帮助。它并不干涉你开发软件的工作方式。你可能在通过了CMM 5级的企业中朝九晚五循规蹈矩地工作；也可能为了实现又一个惊天动地的新点子而一周工作100小时，靠咖啡因来驱散倦意。你可以使用RUP、XP或者SCRUM——或者根本不使用任何标准的过程。不管工作如何组织，只有当技艺高超的开发者编写出高质量的、合乎需要的代码时，只有当他们满足客户的需要时，整个软件开发过程才是真正有价值的。方法学无法造就技艺高超的开发者；只有给予工艺学以足够的认可并按照工艺学的指导去实践（当然，还需要留意本书中的其他观点），技艺高超的开发者才可能出现。如果你能花一些时间来阅读本书，来思考Pete McBreen提出的难题，必定会对你自己和你的职业生涯大有裨益。
David Thomas
The Pragmatic Programmers* 译注：本书作者Pete McBreen。
本文地址：http://com.8s8s.com/it/it37430.htm