《软件工艺》——序言

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

序言

本书提出了一些相当棘手的问题。

对于工作量少于100人年的项目,软件工程仍然适用吗?软件工程与生俱来的专业化趋势真的是一个好主意吗?甚至于,软件的开发真的可以用工程学的术语来描述吗?

本书也提出了一些相当敏感的问题:那些缺乏经验的开发者,是否享受了过高的薪资待遇?那些资深的开发者,是否应该比企业中绝大多数人都拿得更多?那些出现至今还不足十年的工具,是否应该在长期的项目中使用?

在这一切的最核心处,本书提出了一个最大的问题:我们应该如何重组软件构造的过程,使其能够如我们所愿地有效运转?

对于这些问题,本书也提出了一些颇具争议性的答案:本书认为,我们一直对一个简单的事实视而不见——编写软件的,不是硕大无朋的方法学,也不是一丝不苟的组织结构,而是。当今,在软件开发的领域中,我们正在面临一个日益严重的危机。为了扭转这种不利的局面,我们需要培养出优秀的软件开发者。而为了达到这个目的,Pete*回顾了一个数百年来一直兴旺发达的系统,并期望从中获得启示——那就是工艺学。

“工艺”这个词是一种象征,象征着高质量的产品。但它的含义却还不仅限于此。从完整的意义上来说,工艺学是一个自给的系统。在这个系统中,师傅负责安排学徒的工作和培训,而学徒也有可能取代师傅,每个人地位的高下完全取决于他生产出的产品的优劣。学徒、工人和技师,所有人都在同一个团队中一起工作,并彼此学习。顾客则根据团队的声望来做出选择,而团队也只接受那些他们认为有可能提高他们声望的工作。

在我们的产业中,这个完整的工艺学系统能起作用吗?说实话,我也不知道。许多根深蒂固的习惯都必然会反对这种“工艺学”的观点。不过,我的确知道,作为学徒接受师傅的言传身教而最终成为高手,这样的成长途径是行之有效的,因为我就经历了这样的成长过程。

应该说我很幸运,进入了一所优秀的大学,在那里我学到了很多的理论(不过,在我上大学的时候,需要学的理论比现在可少多了)。但是,真正让我的大学生活显得与众不同的,还是那段学徒经历。那时,一位研究生带着我一起工作。他并没有明确地要教给我什么,但他用实际行动让我看到了一个优秀程序员的思维方式。月复一月,我在他的身边工作,从他那里吸收了大量实用的知识。不论是设计、编码还是调试,我从他那里学到的知识比在任何一门课上学到的都多。

后来,我又在伦敦加入了一个刚刚开工的项目。在那个项目中,我扮演了另外一种学徒的角色。我的新老板用他的所作所为告诉我:软件开发不仅仅是一项技术工作,同时也是一项人文工作。他帮助我理解了软件开发中与商业相关的这一部分,并教给我如何在拥有一定技术实力的基础上建立起良好的企业人际关系。

从这两次截然不同的学徒经历“毕业”之后,作为一个开发者,我已经比开始时强了太多太多。由于拥有这样一段经验,所以我完全相信:如果要学习一门手艺,与高水平的师傅一起工作是最佳的途径。

正如我刚才说的,本书在“如何训练下一代开发者”方面提出了很有价值的观念。不仅如此,本书还涉及到了软件的哲学。工艺学所针对的是个人的能力:对你的工作,对你个人的发展,对于你的职业,工艺学能给你更多的帮助。它并不干涉你开发软件的工作方式。你可能在通过了CMM 5级的企业中朝九晚五循规蹈矩地工作;也可能为了实现又一个惊天动地的新点子而一周工作100小时,靠咖啡因来驱散倦意。你可以使用RUPXP或者SCRUM——或者根本不使用任何标准的过程。不管工作如何组织,只有当技艺高超的开发者编写出高质量的、合乎需要的代码时,只有当他们满足客户的需要时,整个软件开发过程才是真正有价值的。方法学无法造就技艺高超的开发者;只有给予工艺学以足够的认可并按照工艺学的指导去实践(当然,还需要留意本书中的其他观点),技艺高超的开发者才可能出现。如果你能花一些时间来阅读本书,来思考Pete McBreen提出的难题,必定会对你自己和你的职业生涯大有裨益。

David Thomas

The Pragmatic Programmers



* 译注:本书作者Pete McBreen

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值