软工圣经：《人月神话》

Fred Brooks是世界上第一批获得计算机科学博士学位的人之一，在1999年获得了计算机领域的最高奖——“图灵奖”，还在 1985年荣获了美国国家技术奖。曾任职于美国国家科技局和国防科学技术委员会。

前言

偶然机会，看到了《人月神话》这本书，打开了我对程序开发新的认识。之前的我还是沉浸在互联网的一潭死水，根据需求去开发，完成目标为己任，对于项目、团队的概念不会有更深层次的探讨。看了这本书之后让我感受到颇深。比如书中提交到没有银弹、外科手术团体等概念，用到当今互联网的项目以及团队丝毫没有任何违和感。后来我去了解这本书的作者布鲁克斯的经历，终于知道为什么这本书叫《人月神话》，一个不可能实现并且是不切实际的问题最终得到解决，你会发现这真的是可以称得上神话。

这本书主要探讨了软件工程中的一些核心概念，并且还提出了许多经典的软件开发原则，比如项目管理、软件复杂性、团队合作和进度计划等。这本书阅读价值性极高，并且文中提到的观点可以适用在自己以后的开发中，所以这里推荐给大家。

感悟与收获

程序开发对我们程序猿来说是再熟悉不过的了，是一个庞大的庞大且极其复杂的工程，需要产品、UI、前端、后端、UE、运营、项目经理等等，我们在开发过程中也都是采用分工合作，自己做自己擅长的工作。但是有个问题，不知道阅读本文的读者发现没有：随着项目参与者的增加以及分工的细化，人与人之间的沟通需求呈指数增长。花在沟通上的时间逐渐超过了因分工而省下的时间。简而言之，随着参与人数的增加，情况不是越来越有利，而是越来越混乱。

在这里跟大家分享一下文中提到几个比较重要的观点，是怎么解决上面的问题的。

外科手术团体

文章中说到一支好的软件开发团队应比作外科手术队伍，并对开发团队每个成员的角色进行了相应的定位。
这个比喻真的是恰到好处，我们做项目就好比是做一场手术，医生每个人都有自己负责的工作，如果某个部位出错，都可能导致手术的失败，失败的话就会对病人的身体造成影响，严重甚至危及生命。然而对于程序开发，我们也是每个人负责自己擅长的工作，分工明确，这样才能确保项目质量，提高工作效率以及团队战斗力。

没有银弹

我比较喜欢文中提到的没有银弹的说法。“银弹"一词描述那些特别有效并似乎可以解决问题的方法。后来被广泛用来指代那些能够快速解决问题的方法，这个说法有点像那些街头巷尾兜售的"神药”。

书中提到的没有银弹说：软件工程是一个极其复杂的系统，没有任何一种特效方法可以永远提高效率。不论是创业、进行项目，还是抚养孩子，所有复杂的事情都是如此。面对的问题是独特的，解决问题的资源也是独特的，机会也是独特的。我们在开发中可能一味寻求某个功能实现，当时解决是困难的，但是我们可以层层解决，一次性解决是可以的，但是耗费的时间，资源可能就有点浪费。可以先暂时性解决问题，或不追求性能方面，之后不断迭代。
我觉得真正擅长解决问题的专家永远不会寻求一劳永逸的解决方案，他们只是将自己打造成一个擅长明确定义问题，然后不断迭代解决问题的独特系统**。

风险与价值的量化

文中提到的忽视对价值的量化原因，确实是我们在开发中经常遇到的，比如：项目规模太小，我们不确定如何做；我们没有选择，只是必须完成它；上级主管要求完成这个系统；收益的多少取决于市场，特别是市场的未来发展情况；这个系统只是为了替代现有系统；命令是由上级下达的，我们只需要执行；收益的不确定性太大，我们无法确定。
我们对一个项目的价值认知通常比对其风险的认知差得多，量化风险本身就具有挑战性，而量化价值则更加困难。如果无法清晰地了解项目的价值，单纯关注风险是没有意义的，因为我们无法确定是否值得承担这样的风险，风险与价值是相互关联的。风险与价值相对应，预期价值与预期成本相匹配。

测试和集成

详细检查项目完整性和明确性。对我们开发人员来说无法单独完成这项工作。文中提到了自上而下的设计，逐步细化这个方法对我们来说可太有用了。无论是针对大型还是小型软件项目。文中提到自上而下设计可以从四个方面减少错误，来降低失败的风险，具体如下

• 清晰的结构更容易准确描述需求和模块功能。
• 模块的分割和模块间的独立性可以避免或减少系统级别的错误。
• 细节的抑制或推迟有助于更容易识别结构上的缺陷。
• 设计在每个阶段都可以进行测试，使得测试可以更早地开始，重点可以逐渐放在不同的级别上。

我们可以从上面的四个方面来检查项目的完整性和明确性，有目的，有目标就好办事啦哈哈。

最后

《人月神话》中的每一个地方都与我们程序开发息息相关，这本书影响的不仅仅是我们日常工作开发，乃至我们的生活，真的很受启发，再次安利给大家。

附

如果你也喜欢这本书的话，可以通过下面的链接购买。
《人月神话》购买链接