Misc: No Silver Bullet与《万历十五年》读后感

No Silver Bullet, Essence and Accident in Software Engineering

读后感

这篇文章出自《人月神话》作者Frederick P. Brooks之手，并被收藏于《人月神话》的周年版之中。Brooks在文章中详细阐述了自己对于软件工程中两个
主要问题的一些观点，并给出一些解决的方法。

Brooks认为，软件工程之中的所有问题可以归结为两种：Essential task和Accident task。前者是主要问题，后者是次要问题。前者是指整个软件的架构
设计、算法设计、数据存储等大而广的问题，后者大意是指实际编码和操作上的问题。Brooks论道，后者之所以不是主要问题，是因为随着软件体系的发展
和成熟，那些"accident difficulties"已经不会对软件构造造成大的影响了。比如，随着高级语言如Ada、Fortran的出现，程序员再也不需要花费大量的时
间调试复杂难维护的汇编代码，而可以专注于软件本身的逻辑。前者之所以是主要问题，是因为它是软件的关键、精髓所在。为了衡量他所说的"重要性"，
Brooks在文章的开篇就提出，如果解决某一个问题能够减轻整个软件团队百分之九十的负担，那么它就是主要问题。显然，在这个标准之下，前者才是主要
问题。

Brooks在文章中详细地阐述了这两个方面，并针对一些问题给出解决方法。然而，它在文章开篇(甚至题目)就说，解决这个问题并没有捷径。也就是，
No Silver Bullet。Brooks将No Silver Bullet一词隐喻于狼人的传说中。在传说中，狼人被视为最可怕的猛兽，因为狼人在月光下从人们熟悉的"人"变为
人人惧怕的"狼人"；反观软件构造的过程也是如此：一不小心，一个开发前期的漏洞就会给整个软件开发带来致命的打击，比如需要重构。在狼人传说中，
人们寻求一种银弹(silver bullet)，期望这种银弹能够一招致命消灭狼人；在软件构造过程中，也有人想着会有一种"银弹"，或者说方法，是能人们能够使用
这个方法解决所有的问题。

银弹是没有的。Brooks从四个方面阐述了他所说的Essential task之所以essential，并且难以轻易解决的原因。第一是复杂性(Complexity)。
Brooks说，软件之所以复杂，大概是因为它的规模太庞大了。但是，这种规模上的庞大并不像诸如建筑物之类的东西的庞大一样，因为在软件中，
没有很相似的东西（如果有的话那么我们就可以用将其规约到同一个函数内的方法进行重构了），所有的组件都有其自身的特点，而且在不同的情况下也有
不同的状态。在这种情形下，各个组件之间的交互变得难以描述，程序员们很难对系统进行有效地扩展。第二是一致性(Conformity)。关于这个一致性，
Brooks讲得比较模糊，但是从他给的比喻中可以推断出这种一致性大意应该是指软件开发中各种问题的是否都"处于某个范围之内"。他说，爱因斯坦相信
应该有一条简洁有力的理论来描述这个宇宙，人们也相信，对于各种各样的软件开发问题，应该也有那么理论来描述，或者说，这些问题在某个程度上都有
某些内在的一致性。很不幸的是没有。第三是易变性(Changeability)。这是显而易见的。软件不像其他汽车、建筑物和电子芯片等东西，汽车可以很少会
被召回，建筑物也很少被拆掉重建，电子芯片业很少会重新组装，但是软件却不一样，软件重构是经常发生的事。第四是不可见性(Invisibility)。在其
他行业，人们很容易发明可视化方法来辅助开发，比如电子电路设计会有电路图，飞机铸造也会有流程图和架构图，但是软件却没有，即使是一些流程
图、组件关系图也只是部分地、表面地描述软件。

所以，解决Brooks所说的Essential task的银弹是没有的。但是，解决Accident task的方法随着时间流逝却不断推陈出新。越来越多的高级语言替代
了曾经的底层语言，越来越成熟的操作系统和标准化使得程序员受开发环境的约束越来越少。如此种种，不胜枚举。

Brooks接着在文章中列举了一些被认为能够解决Essential task的方法，分析了他们的优点和局限性。比如，像Ada之类的高级编程语言，面向对象
编程语言，人工智能方法，专家系统，自动编程(Automatic programming)，图形化编程(Graphical programming)等。在此不一一赘述，有兴趣者可以看
看那篇文章。但是，Brooks认为这些都无一例外地有其局限性，并不是它所期望的解决方法。

诚然，银弹是没有的，但是Brooks却从自己的经验和思考出发，给出了几条它认为有用的方法，或者说准则。这一部分是我最喜欢的部分，阅读时
明白了很多我一直不懂的概念，也想明白了一些我一直似懂非懂的问题。

第一，买软件，而不是构造软件(Buy versus build)。Brooks说，购买软件的钱远远少于自己构造软件的支出。他认为，软件开发的趋势是，
一方面，人们会趋向于购买和使用统一的软件或服务，因此这种软件或服务能得到长期良好的维护；另一方面，人们的也能够减少支出。总的来说，软件
开发的成本和风险会被平摊到多数人不是某些人之中。再者，随着平台标准化的发展，软件也越来越跨平台了，人们开发的软件再也不是针对于某些型号
的机器，而是所有的机器，所以兼容性也不再是问题了。其实这很像现在的云服务的应用。人们不再自己搭建服务器而是购买各大厂家的云服务器，
因为自己搭建和管理服务器的支出远远大于购买云服务的支出，而且，各大厂家的云服务在一定程度上都是”兼容”的。

第二，完善需求和快速原型(Requirement refinement and rapid prototyping)。大家都知道需求是软件存在的根本原因，但是在处理需求问题时
很多人却看不到问题的症结所在。Brooks说，客户永远不知道自己想要什么，直到你呈现给它看。即使是有经验的、整天和软件工程师打交道的人也未必
能够说明白他们自己的确切需求。所以，很重要的一点是，在最开始的时候，必须要有一种能够在一开始就能够快速“展现需求”的方法，然后再不断地完善
需求，这就是快速原型(Rapid prototyping)。通过快速原型的方法，我们可以快速地向客户展示“他们的”需求，然后才能接着完善需求。否则，客户从
一开始就不能确切地想清楚自己需要什么，到最后，只能导致软件的重构。

第三，迭代开发(Incremental development)。在这里，Brooks讲了一个很有意思的比喻，颠覆了我对迭代开发的理解。Brooks说，人的大脑是自然界
最复杂的物体之一了（或许没有之一），这么复杂的东西，是不断地生长(grow)出来的，而不是一下子构建(build)出来的。复杂的软件也是如此，应该
一步步地"生长"(grow)，而不是从头到尾一下子构建出来(build)。这就是迭代开发中迭代的意义。对于这一点，我也有自己的体会和理解。作为一名软件
工程专业的学生，我一直把自己当作一名工程师而不是一名理论家对待，工程师的职责在于有效地解决实际问题。在构建一个项目的时候，我觉得，我们
的第一步应该是使得这个系统能够运行起来，换句话说，我们应该首先切切实实地弄清楚这个系统到底能不能这样做，通过哪些手段能够做出来。这之后，
才慢慢扩展这个系统。Brooks说，“enthusiasm jumps when where there is a running system even a simple one”，在我看来简直是最生动的比喻。
软件工程师和项目管理员不一样，项目管理员不管编码，但是软件工程师需要，项目管理员一开始会写出一大堆需求、文档，软件工程师却的首要任务是
把软件内在的逻辑、可行性和各种构造软件的途径搞清楚。常常有人混淆了软件工程师和项目管理员的职责。当然，你可以既是项目管理者又是软件工程师。

第四是，培养优秀的设计师。如Brooks所言，设计是Essential task的核心之一。但是，Brooks却没有给出详实的方法，只是给出了几点建议，希望
软件行业注意培养优秀的设计师。

为什么又扯到了《万历十五年》这本事呢？原因是我这两天一直在读这本书，从书中也发现了很多让我深深认同的观点，我想这些观点其实也适用于软件
工程这个领域，所以一并记录下来。

《万历十五年》一书中，作者黄仁宇以万历十五年(1587)为时间轴，通过描述明朝万历年间的六个大人物来展现了明朝的由盛到衰的历史。作者一直在书中
强调的一点是，明朝之所以注定要衰亡，之所以多灾多难，原因并不仅仅在于人们通常所说的“封建制度的落后”那么简单，这种说法太笼统。作者强调的是，
在我们这个国家，一直是试图以道德，或者说意识形态来统治国家。之所以独尊儒术之所以大兴八股，完全是因为在上层领导者的心中，只要老百姓安安分分
地种田，子尊父，臣敬君，那么民风就会淳朴，社会就能安定，国家就可以长治久安，根本就不需要法律。所以，国家一直没有成熟的法律，也没有尝试去制
定成熟的法律来维护国家的运转。但是，事实是，人非圣人，“高屋建瓴”的意识形态和老百姓的日常生活并不能做到有机的结合，吃不饱了，人们就会去抢
去偷，甚至杀人越货。在现代化的国家，为了解决这个矛盾，依靠的是法律。但是中国没有。在这种情况下，就出现了明里一套暗里一套的情形了，也就是作者
所谓的“阴/阳”。阳即是人们在封建道德下呈现给大众的那一面，阴即是人们背地里的私心和阴谋。那些大政治家大将军，无一不是如此。学会很好地调和阴阳
的，就能够仕途通畅，人生如意；不懂这个的，只能命途多舛。比如大军事家戚继光，扫除倭寇镇守边关，至今留名。但是，虽然生前以严于律己著称，暗地里却
依然贿赂高官，并且也收受贿赂。但是值得声明的是，作者所说的“阴”并不一定指“阴谋诡计”，翻译为“人情通达”或许更恰当。戚继光之所以收受贿赂，完全是
因为明朝官俸极低，官员们如果只是靠官俸收入连养活自己都困难，更不用说打点人情了。而戚继光要一人独挑大梁铲除倭寇，必然会有很多阻碍，所以他也只能
经常花钱买人情，好完成自己的目标。

讲了这么多，并不是为了写书评，而是我觉得书里有一点真的讲得很在理：依靠意识形态而不是技术来统治国家是行不通的。

我想，这也适用于我们这个行业（其他行业也大概如此吧）。如果一个人干任何事都只是站在“高层”看，而没有落实到具体，没有考虑到理论与具体的粘合，那么
他所做的注定不能成功。理论指导实践，实践检验理论，这是真理。如果流于形式，最后的结果也只能是形式。共勉。

😃