人月神话读后感

        人月神话摈弃神话色彩后，其本质上便是人与时间的关系，而引申到编程上是对于时间这一概念的有效利用度，因为编程注重结果，所以完成工程项目的必要时间是必须的，而在一个问题上花费合理的时间解决，预示着这个项目的效率与寿命，

过长会使其效益下滑，过短会让它稳定性受怀疑，Brooks教会了我们如何从枯燥烦闷的长时编程中寻找乐趣，想着我们最终完成的项目成果，一切也便有了坚持的信念。

 然而这个过程并不全都是喜悦。我们只有事先了解一些编程固有的烦恼，这样，当它
们真的出现时，才能更加坦然地面对。
首先，必须追求完美。因为计算机也是以这样的方式来变戏法：如果咒语中的一个字
符、一个停顿，没有与正确的形式一致，魔术就不会出现。
（现实中，很少的人类活动要求
完美，所以人类对它本来就不习惯。
）实际上，我认为学习编程的最困难部分，是将做事的
方式往追求完美的方向调整。
其次，是由他人来设定目标，供给资源，提供信息。编程人员很少能控制工作环境和
工作目标。用管理的术语来说，个人的权威和他所承担的责任是不相配的。不过，似乎在所
有的领域中，对要完成的工作，很少能提供与责任相一致的正式权威。而现实情况中，实际
（相对于正式）的权威来自于每次任务的完成。
对于系统编程人员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程
序，而往往这些程序设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例）
，
或者文档记录得很糟。所以，系统编程人员不得不花费时间去研究和修改，而它们在理想情
况下本应该是可靠完整的。
下一个烦恼——概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。
伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动。程序编制工作也不例外。

另外，人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂

度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。
最后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或
者终于完成的时候，
却已显得陈旧过时。
可能是同事和竞争对手已在追逐新的、
更好的构思；
也许替代方案不仅仅是在构思，而且已经在安排了。
现实情况比上面所说的通常要好一些。当产品开发完成时，更优秀的新产品通常还不
能投入使用，而仅仅是为大家谈论而已。另外，它同样需要数月的开发时间。事实上，只有
实际需要时，才会用到最新的设想，因为所实现的系统已经能满足要求，体现了回报。
诚然，产品开发所基于的技术在不断地进步。一旦设计被冻结，在概念上就已经开始
陈旧了。不过，实际产品需要一步一步按阶段实现。实现落后与否的判断应根据其它已有的
系统，而不是未实现的概念。因此，我们所面临的挑战和任务是在现有的时间和有效的资源
范围内，寻找解决实际问题的切实可行方案。
这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。
对于许多人而言，其中的乐趣远大于苦恼。而本书的剩余部分将试图搭建一些桥梁，为通过
这样的焦油坑提供一些指导。

这便是对于编程的一种态度，我们可以烦恼，可以质疑，但最终我们仍旧会征服它，做人不要过分焦虑，车到山前必有路，既然无法停止，为什么不继续下去