前言
本文为《人月神话（40周年纪念版）》试读博文
摘要
- 这是一本软件工程领域的经典之作，第一次笔者听到这个书名还是在大学的一次技术研讨会上，现在已经过去两年多，借此机会来重新研读一下此书。
- 我将通过一个准程序员的视角来阐述自己对本书的浅见，希望大家给予指点批评！
正文
焦油坑是啥？
首先映入眼帘的是野兽与野兽打架的场景..几只野兽挣扎着半天也无法逃脱这个坑，如同过去几十年大型的系统开发，他们中大多数开发出了可运行的系统，但是却因为极少数的项目满足了目标、进度和预算的要求。因此，他们一个接一个地淹没在了焦油坑中。
我觉得：一个项目的开发是一个复杂的动态系统，没有最优化结果，只有顾客满意的答案。索要考虑的因素也很多，必须全面策划，平衡因素，团队的高效，协调一致，才能保证目的的成功！简单的说就是顾客是上帝。
那么职业的乐趣所在呢
还记得那个经典语句吗，HelloWorld！这几乎是所有语言学习当中，第一个范例程序。从当初第一次学习C，但是不知道有啥用，到后来第一次解决错误（称之为bug),在到后来做出一个小项目，最后默默的想成为一个不错的程序员。
想必每次调试成功的自豪感是难以言表的，代码是死的，但是在程序员的雕琢下活生生的编程了一个功能，一个项目，未来甚至会创造出与人一样会思考的机器人（人工智能？）
放下一切杂念，只是单纯的关心这个程序问题，一心一意的把它解决；希望自己的劳动成果可以被他人使用。
这种完成编程之后的一丝愉悦，就是唤醒每个人内心的情感的体现；也满足了对于创造的渴望。
有开心就有苦恼了呗
对于程序追求完美、难以控制工作环境和目标会让程序员感到烦恼；但更重要的是，对其他人的依赖是一件很难受的事情，依赖别人写的程序却发现设计的并不合理，文档也没有，最后不得不去研究修改，这是很可怕的。
程序员不喜欢过多的去受到依赖和约束，更不喜欢一大堆的文档，尤其是当这些文档没有记录清楚的时候。
寻找琐碎的bug，这种重复性的工作，让人心生烦恼。最让人难过的就是辛苦开发出来的系统最后没有得到使用。
职业的酸甜苦辣
码农这个词，经常被提到，编码常常被认为是一种无价值和创造性的活动，他们理想化的认为需求和设计可以做的足够详细，
引用
编码仅仅是一种体力劳动，这是对每一位程序员的不尊重。
处于最后一道工序的编码人员，他们产出的代码最终形成的形成了软件系统和产品，当他们的价值往往并不能得到相应的承认
其实，我想说，如果你都没当过码农，你又有啥资格说他/她，这不好那不好呢。
向进度落后的项目中增加人手，只会使进度更加落后。 -Brooks法则
乐观主义
一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
这其实是一个错误的结论！假设一切都会运转良好，而不会遇到任何的风险和问题。而恰恰实际情况是在实际开发中遇到一个疑难问题耽误几天或一周的时间。
人月
用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话，因为它暗示了人员数量和时间是可以相互替换的。
系统测试
- 在进度安排中，由于顺序限制所造成的影响，没有哪个部分比单元调试和系统测试所受到的牵涉更彻底。而且，需要的时间依赖于所遇到的错误、缺陷的数量及其难以捕捉的程度。理论上，缺陷的数量应该为零。
- 但是，由于我们的乐观主义，通常实际出现的缺陷数量比预料的要多得多。
- 因此，系统测试进度的安排常常是编程中最不合理的部分。
空泛的估算
基于可靠基础的估算出现之前，项目经理需要挺直腰杆，
坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强
得多。
重复产生的进度灾难
- 简单、武断地重复一下Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。
- 这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。
- 总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大
后续
人力（人）和时间（月）之间的平衡远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。
看到这里的人估计很少了吧，，附上两幅图给大家：
哆啦a梦此时此刻会从他的神奇口袋里，拿出啥呢？？
>
>
>
>
天啊，竟然是人月神话，，，所以说这本书是一本难得的经典，大家一定要看哦，就让这本书伴我走向程序员的新征途吧！