软件工程的变迁

 本文是从 What Happened to Software Engineering? 这篇文章翻译而来。

　　在过去的几年里，在世界范围内，软件开发方法发生了一些变化。还不是很久以前，最主要的软件开发生命周期(SDLC)方法论是瀑布模型方法(Waterfall Method)，它使用非常明确的阶段把开发过程分割成诸如设计、测试等工程步骤。软件开发行业，目前还是一种新兴的行业，人们正在努力寻找一种可以重复的、可预知的软件开发过程方法。

　　对于软件开发过程，最好的参考模型看起来应该是物理学工程，就像土木建造工程。诸如详细需求说明书、设计说明书以及技术说明书的等材料应该早在任何程序代码编写前就开始动工编写和完成，就跟修桥、盖大楼、修路、修大坝等物理建筑修建过程一样。

　　为了更好的向这种物理学工程靠拢，诸如“软件工程师”和“软件架构师”等工作职位也开始在软件开发中被接受。

　　这种风格的工程管理在建筑工程中使用的非常成功。然而在软件工程中却出现了大量的失败，还有更多的项目最终严重超出预算或工期延误。导致这种现象的因素很多，但最主要的一个因素应该是软件和硬件上变化的速度和业务需求上变化的速度。软件行业里的这种变化—做个比喻—就像是每18个月一款新型的汽车的出产都需要你对道路进行全面的重新设计。

　　当一个土木工程师去修建一座跨河大桥来连接河两边的道路时，工程师会非常清楚的知道道路跨河的精确地理坐标位置。行驶的车辆在数年里也不会发生重大的改变。桥梁工程师只需要按照之前已经被上千次的验证过的建筑工艺把河两边的路连接到一起。

　　对于软件系统，因为技术或业务发生了变化，在建设过程中(在所有需求和设计文档完全完成后)需求需要做重大修改的情况并不罕见。如果把这种情况放到修桥的事情上，相当于当桥的地基打好后，再把桥的搭建位置往河的下游移6公里。

　　为了面对出现的这些问题，软件工程师开发出了很多新的技术和实践方法来重新定义软件建设开发过程步骤，以此来提高软件的质量、代码重用率和生产率。有一些新的的实践方法对代码规范、命名规则进行了定义(和强制要求)，鼓励使用那些经过验证过的软件设计模式，鼓励使用诸如单元测试框架等工具和驱动测试开发(TDD)等技术方法，鼓励采纳行为驱动开发(BDD)、持续集成、结对编程等实践方法。这些技术有效的减少了问题的出现，改进了建设开发过程，成为了公认的软件工程做好的实践方法。

　　当对开发过程阶段的实践方法有了改进发展后，针对项目过程中其它阶段—诸如需求定义、系统设计、质量管控、测试等—的研究改进也相继出现。它们包括Scrum，极限编程，Kanban(Lean制造工艺的一种修订)…

　　这种针对开发上的变迁现在被人们归结为敏捷方法论(Agile Methodologies)。事实上，大部分用来改进软件开发的实践方法，例如TDD，持续集成等，都是沿着改进开发过程的思路发展起来的，它们后来都被统称为敏捷方法。

　　如今，敏捷方法论正迅速的从边缘角色发展向主流技术，甚至渗透到了很多大公司的软件开发团队里。敏捷革命给软件行业带来了巨大的变化，很多在使用老的瀑布模型软件开发方法时程序员会面对的问题，现在都被凸显出来。

　　各种的会议，开发论坛，课程都起来讨论如何更好的使用敏捷方法，人们都关注于像“如何最好的管理backlog，重构，spring计划，以及其他过程问题“的论题——这些都是极其重要的、需要被那些打算采用敏捷方法的开发团队认真理解、正确使用的概念。

　　所有敏捷运动留下来的产物都是用于创造高质量软件的工艺实践方法。大多数敏捷方法论主要针对的是过程管理问题，不涉及到其中的开发技术(Kent Benk 和极限编程是例外)。这是敏捷方法论假设的一个前提：你已经很好的掌握了编程技术！

　　不幸的是，在我做顾问和敏捷指导的职业生涯中，我经常发现他们技术工艺水平远远达不到敏捷方法论的要求。这导致了在敏捷方法上出现了很多错误的认识，抓不住敏捷方法的特征重点。或者，对他们来说，敏捷方法的意义只之在于把来自于瀑布模型开发方法下出现的“软件工程“这个词给搞臭了。

　　我们是学习了前人的基础上才发展成一个产业的。即使在过程上的革新也是要参考我们已经知道的东西，吸收那些好的，摒弃那些不好的。像测试/行为驱动开发、持续集成、结对编程这样的优秀软件工程实践方法，如果我们视如不见，那我们其实是忘了我们最终的目的：开发出高质量的软件。

　　其它类型的过程管理方法跟敏捷方法一样，它们对实现我们最终的目标有着同样重要的意义，所以，不要倒洗澡水时把孩子也泼了出去。我现在有很多的头衔，包括演讲家，敏捷教练，作家。而本质上，我是一个软件工程师。而我为此自豪。