微信图片_20190226222914.jpg
软件工程与其他所有行业最大相径庭的一点，可能在于唯有在这一领域，关于失败的专注要多于成功的，软件工程的成功只有一种——按时按照要求完成交付（虽然在大部分情况下这只是一种幻想）——但失败却有着无穷无尽的可能，曾经看到一篇描述某欧洲国家政府软件项目的未经证实的文章，预期两三年完成，实际做了十二年，写了六百多万行代码，换了好几拨软件工程师，项目还陷入在无穷无尽的泥沼中难以自拔。倘若这个故事属实，大概是软件工程中又一个值得出一本专著的“杰作”了，和这个故事相比，《梦断代码》里的失败简直可以说是小巫见大巫了。
关于软件工程失败的经典之作，非《人月神话》莫属，这本书将IBM360系统失败的故事上升到理论高度，总结出一系列关于软件工程复杂性的规律，就IBM而言当然是一种不幸，但对作者布鲁克斯来说可谓失之东隅收之桑榆，《人月神话》对软件工程行业的影响之巨大，不是某一个软件系统可以比拟的。这本书提到的最基本的观点之一，是增加人（程序员）与月（时间）之间的矛盾，软件工程和工程建设项目不同，不能通过简单的提高人数来加快进度，有些过程就如十月怀胎一样，即使叫来一百个孕妇，要完成任务同样需要40周的漫长时光。人数增加带来的效率提升会被越来越高的沟通的复杂性所抵消，到一定阶段可能对软件工程带来负面而不是积极的作用。但软件工程复杂性的本质又使得现代软件工程几乎不可能由独立的一个用户完成，复杂性与效率之间的矛盾，使得人与月的完美搭配难如神话。
自《人月神话》之后，注入《软件开发的滑铁卢》、《死亡之旅》、《软件极限》（这本书被形容为由被诅咒的程序员战士写下的《伊利亚特》）等大批著作，都是对失败的软件项目的复盘和反思，但所有的这些反思，并没有能从根本上提高软件项目的成功率。更多的项目之所以没有被宣布为失败，很大一部分程度上是因为项目的实施者（或者用户）接受了充满缺陷的成品、同意追加了成本或者延长项目交付时间，软件工程中的时间黑洞永远让人无法看清其本质，在《梦断代码》中，这一过程被以充满史诗感的叙事风格详细而从容的讲述出来。
《梦断代码》讲述了OSAF开源基金会开发日历管理软件Chandler的过程，前后两打程序员，3年时间，4732个bug，耗费百余万美元，只为了打造（听上去似乎很容易，但想来应该不至于简单）一款全功能的日历软件。作者对软件行业的典故、背景与理论了如指掌，在叙事时常常加入宏大的历史背景与理论，正是这些部分让本书充满了史诗般的叙事感，而每个人物也并不仅仅是作为程序员而存在，更像是小说中一个个有血有肉的人物。从一开始读到Chandler项目，就有种隐隐的不详感，这并不需要很强的直觉或者推理，在我使用软件的历史中，对于这样一款软件闻所未闻，单是从这个角度来看，Chandler在与其（假定的）竞争对手Outlook或者iCalendar的对决中一定未能获得成功。即使项目并未失败，大概也已经不了了之了。
但即使对结局有了一定程度的预判，也并不影响本书阅读的趣味性和实用性。项目中的每个人基本上都是全力以赴投入到Chandler项目中去的，并且其中大部分人都才华横溢，这样一个团队却未能打造出成功的产品，在相当程度上都是有很大的启发性的。软件工程可能是少有的几种用心也不一定会做好的工作，其本质与软件的脆弱性不无关系，在《梦断代码》中，作者形容到：如果我们以软件工程的水平去实施工程建设项目，那么仅靠一口气就能让这座充满缺陷的大厦倒塌掉。
随时时代的进步，git之类工具的出现，以及后来软件工程的不断变革，大部分互联网公司的软件开发模式也发生了变化，台阶型的新版本推陈出新已经逐渐减少，大部分软件都进入了不断更新迭代的方式，依靠大量用户的使用和测试来发现缺陷并不断改进。但这样的方法仍然并不完善，致命的缺陷往往会随着迭代更新直接暴露在用户面前，苹果前一阵facetime缺陷就让一大批人隐私泄露，但在当下的软件工程中，这一类缺陷是很难避免的。从这个角度，像《梦断代码》一类的作品，更像是当时项目的墓志铭，为后人介绍项目失败的全过程，以及从中得到的教训，而软件工程自身新的发展与特点，则并没有在书中详述，而是需要读者在项目实施时不断摸索与持续学习了。
网友评论