人月神话——第一篇阅读笔记

 

人月神话——第一篇阅读笔记

再看这本书之前我是不知道“人月”的意思的，因此我先上网搜索了“人月”的意思。得到了以下解释——软件工程里面的一个概念，人月，一个软件开发的工作量单位。如200人月，10个人开发，那算来就是花20个月就可完工。

在这本书的序言中，作者表明了这本书的内容——“对 Tom Watson 关于为什么编程难以管理的探索性问题，这本书是一份迟来的答案。”

我对书的内容进行了大致的浏览，发现有较大一部分的内容，我有点难以理解，读起来有点吃力。因此，在阅读的过程中，我会有选择性的阅读，跳过一些难以理解的问题。

书中作者写到了这一职业的乐趣。我本身是能感受到这种乐趣的，通过大一C语言和C++的学习，我接触了编程，并感受到了它带给我的乐趣。以至于在转专业的时候我选择了“软件工程”专业。作者在文中说的这一职业的乐趣，我是十分同意的。

首先是创建事物带来的快乐。当我编写出来一个符合要求的程序的时候，看着那个成功的运行结果，会有成就感，感到逾越。作者提到的做出的东西对他人有用，目前还没有体会过，目前能力有限，希望能尽早体会到这方面带给自己的愉悦感。程序员的工作方式也的确十分有趣，正如作者所说——“程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有这样的介质——创造的方式如此得灵活，如此得易于精炼和重建，如此得容易实现概念上的设想。”这种工作的形式也的确是我喜欢的。因此我十分赞同作者说的——“编程非常有趣，在于它不仅满足了我们内心深处进行创造的渴望，而且还愉悦了每个人内在的情感。”

当然，作者也提到了“职业的烦恼”——“然而这个过程并不全都是喜悦。我们只有事先了解一些编程固有的烦恼，这样，当它们真的出现时，才能更加坦然地面对。”我虽然还没有把编程作为我的职业，但是我也可以感受到编程并不总能给我带来喜悦，又是也会带来各种各样的苦恼。

首先就是编程过程中对于完美的追求，首先在语法上的要求是十分严格的，不能出任何差错。程序也必须有较好的健壮性。其次，编程是为了满足别人提出的需求——“个人的权威和他所承担的责任是不相配的”。还有，再编程的过程中会有对他人代码的依赖。作为学生，我有这样的感触，有时会需要从网上下载资源作为参考。此时就会面临一系列的问题。别人分享到网上的代码很有可能——“设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例），或者文档记录得很糟”。或者是无法完全满足自己的需要。此时就需要我们花费时间去研究和修改。再有，在设计程序的时候是比较有趣的，可是若将自己的思想进行落实，将会面临一些问题。寻找和修改bug是繁琐且枯燥的。同时，技术是不断进步的——“一旦设计被冻结，在概念上就已经开始陈旧了”。

“这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。对于许多人而言，其中的乐趣远大于苦恼。”

作者对项目进度这一问题进行了分析，我觉得比较有道理，并学到了一些知识。

“我们对估算技术缺乏有效的研究”。所有的编程人员都是“乐观主义者”，我们在系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。造成这种乐观主义的弥漫是因为——“计算机编程基于十分容易掌握的介质”。正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有 bug。也就是说，我们的乐观主义并不应该是理所应当的。在单个的任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。

作者认为以“人月”作为估计和进度安排中使用的工作量单位是不对的。因为人员数量和时间不是可以相互替换的。因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。

软件经理很早就认识到优秀程序员和较差的程序员之间生产率的差异，但实际测量出的差异还是令我们所有的人吃惊。在他们的一个研究中，Sackman、Erikson 和 Grand 曾对一组具有经验的程序人员进行测量。在该小组中，最好的和最差的表现在生产率上平均为10:1；在运行速度和空间上具有 5:1 的惊人差异！

可是作者也发现了是小型、精干队伍概念上的问题——“对于真正意义上的大型系统，它太慢了。”此时便出现了一个矛盾——对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。

Mills 建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。

由此有了以下位置——首席程序员、副手、管理员、编辑、秘书、程序职员、工具维护人员、测试人员、语言专家。

计算机系统有很大程度的概念差异和不一致性。这通常并不是因为它由不同的设计师们开发，而是由于设计被分成了由若干人完成的若干任务。作者认为，在系统设计中，概念完整性应该是最重要的考虑因素。由此面临了一个矛盾——“概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现”与“进度压力却要求很多人员来开发系统”之间的矛盾。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是之前作者提到的一种崭新的组建编程开发团队的方法。

面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法——挑战估算的结果。后者是固有的主观感性反应。此时，结构师是在向开发人员的做事方式提出挑战。想要成功，结构师必须——牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；对上述的建议保持低调和平静；准备放弃坚持所作的改进建议。结构师在开发第二个系统时会出现一系列问题。他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能。

标签：神话,乐趣,第一篇,编程,系统,笔记,程序员,作者,设计
来源： https://www.cnblogs.com/ruangongyouxi/p/10422845.html