读《人月神话》

本应该大三的时候读这本书的，当时软件工程课的老师也向我们推荐过，还列为课外必读的参考书，不过那会不怎么爱学习，就没有读。其实现在想想，当时就算读了，也不过是囫囵吞枣，是理解不了多少的，因为根本就没有多少的工程实践经验，很多东西根本理解不了。就跟老师当时还推荐的《设计模式》一样，其实基本上可以说是完全看不懂的，当然我现在也没看过，应该说是前几年翻过一些，不过实在是看不下去。

书中的例子年代比较久远，可能很多事物现在觉得很平常，当时就是不敢想象了，不过思想总是不会过时的，所以就算是过去了几十年，这本书仍然有众多的读者；就是是过去几十年，书中提出的"没有银弹"的观点，到如今仍然正确。

软件这个领域确实不同于以往的任何领域，比如建筑、制造等领域，在以往的领域中，流水线的发明大大的提高了生产效率，只需增加流水线，增加工作人员，虽然生产效率不会提高，但是产量会提高。而软件领域则不同，对于一个软件产品，没有人能够将它流水线化，然后每个人生产其中的一部分。对于大的软件产品而言，是可以细分成模块的，模块也能细分，但是却不能无限细分，而且模块与模块之间并不是完全不相关的，并不能像制造领域，大的产品是由小的零件组合起来，只要小零件符合规定要求，那么拿过来就能用。但是对大的软件而言，却不能这样。一个原因是大型软件是非常复杂的，没有人能够完全明白其中的每一个细节，不同的模块之间需要通信，必须组合起来测试，不能实现完全的"热插拔"。这个问题至少现在还没有"银弹"，没有人或者公司提出或实践了什么突破性的理论或技术，能够完全解决这个问题，这也导致现在大型软件非常难开发、维护代价昂贵。

另外一个就是软件开发的方法。如今，瀑布模型的应用应该非常非常少了，现在一般都是采用敏捷开发：将系统分成若干小模块分别开发，首先构建整体框架并保证系统能运行，对每个模块进行增量开发，保证任何时刻系统都是能运行的，直至最后系统的完成。其中，"保证系统任何时刻都是可运行的"这点非常重要，这也是我在2011年在雅虎实习学到的非常重要的知识。当时刚去实习，mentor让我开发一个数据显示系统，其实就是调用一些库，将数据以flash的直观方式显示出来。刚开始我的做法是实现每个小的部分，然后把它们合起来，有问题再分别改，因为我喜欢看到自己合成组装的东西一次性就能跑起来的那种很爽的感觉。很显然，过了一天仍然没做完，mentor就问题哦进度如何，我就说如何如何，mentor就问能跑起来看看吗，我就回答说我还在搭底层的模块，搭完了才能跑。mentor就教育我说应该先搭个大框架出来，保证能运行，然后慢慢添加模块进去实现完整功能，这样不仅方便调试而且开发效率更高，因为系统一旦能运行，不管运行结果是对还是错，至少是从0到1的突破，对开发人员的激励作用是很大的，现在大型的软件及互联网公司基本都是采用这种开发模式。后来的经历也让我更加深刻地理解了这种思想。

几十年过去了，软件领域出现了一些新的编程语言，新的编程开发工具，在很大程度上提高了软件的开发效率，现在人们能以更高的效率开发更大型的软件。但是本质问题仍然没有解决，能否像传统工程领域一样，增加人手就能提高对应的产出？什么时候能够实现软件的组装：可以从市场是购买相应的小模块，组合成复杂的软件系统？真正到了这个时候，软件也就实现了流水线生产，《人月神话》也就可以扔了。

会有这么一天吗？