人月神话

　　最后一篇读书笔记，我并不想一章节的形式去总结了，我想从整体出发，整理一下我读完这本书的感受。 　　我和大多数人一样在高考结束后，填报志愿时都有纠结过专业的选择。今后要做什么工作，从事什么行业，笔者在茫茫专业中选择了软件工程，当时觉得软件开发是一件相当具有创造性的活动，能够通过编程把脑海中的想法加以实现，能够通过编程解决生活中的实际问题，能够通过编程完善一些APP的功能...... 　　经过大学期间紧凑的软件开发技术训练，以及课外项目实践，笔者编程能力和软件开发能力有了一定的提升，而自己对软件开发的乐趣也发生了一些变化，不再满足于单纯的创造带给笔者的乐趣，屏幕上输出的“Hello, world!”已经不能让笔者眼前一亮，而是追求将高复杂度的模块组件拼装在一起，形成完整的系统。例如在某次课程作业中，为了满足多种非功能需求，需要对整体系统进行详细的架构设计，并应用多种未接触过的技术和框架，尽管开发过程充满了挑战，bug频出，接口易变，但是在克服完重重障碍后，得到一个高可用、高性能的完整系统，完成时的成就感是无可比拟的。 　　　要想学好软件工程趣是最好的老师。我们王老师也经常这样跟我们说要去培养自己的兴趣，但是兴趣的培养也不是一朝的，特别是在大学里学习,大学生活就像社会一样,一切由你选择,你可以选择去干你喜欢的事,所以兴趣尤为重要。学好软件工程这个专业,总的来说,就是要耐得住寂寞。

《人月神话》是大学刚开始就很熟悉的一本书，似乎都要在书架上摆上它才能表明软件工程学生的身份。时至今日我再读它，因为有了系统开发的经验，很多的内容都通过记忆得到了验证，读来与大一时的“虽然不懂你在讲什么但好像很有道理” 的体会有了明显的不同。这里选择一些感触较深的章节写一些自己的理解。 焦油坑 入坑前，都会觉得自己战无不胜，就像陷入焦油坑的巨兽，自以为有着庞大的身躯就能在各种的地形中安然度过。在填写志愿的时候，对未来充满希望的孩子们还不知道自己将面临什么，只觉得代码的世界奇妙酷炫，然而代码对于软件系统的开发来说只是水面上的冰山。前人的智慧告诉我们如果没有认真地进行分析、设计、进度计划，真正开始开发后总会让自己陷入令人痛苦的麻烦。事实上，这种麻烦在我前期做过的绝大多数项目中都出现了，但是当你咬着牙从中脱身，还是会体验到创造与实现的快乐，通过这些经历和课程学习，我也慢慢能总结归纳经验教训，让自己今后能尽量少地陷入这样的“焦油坑”中。 画蛇添足 过度设计的现象常常存在，据我的观察，这种现象往往出现于极度追求完美的人和刚刚经历过首次开发设计不足的经验教训的人。过度设计的系统在最初就引入了过多的复杂性，导致开发举步维艰，这个问题或许在一个架构师有了一定经历后就自然能够解决，但是“第二个系统”的困境出现时，我们可以有意识地约束自己做出一些舍弃。 为什么巴比伦塔会失败 巴比伦塔的制造是一个神话故事

我们都知道，在实际的工程项目中，正确的文档结构很重要，如果没有正确的文档 结构则可能会影响到进度，另外要及时更新团队文件，有的时候因为种种原因，没有及 时更新文件而导致进度的推迟，这些都是很有必要的考虑因素，及时更新不仅仅是给主 管看更是要所有人都看到当前的最新情况，另外团队成员之间要有或者说要保证有一定 的交流，团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决 上述交流问题的关键措施。 另外要注重数据的表现形式，有的人喜欢看文字性的数据说明，有的人喜欢看表格 的形式的，所以要针对不同的人去整理出来不同的形式，另外要作为一个要持续的项目 正式的文档是必要的，之前在一个不太正式的小组中过，都是学生，没有很多经验，在 很多地方都不太清楚，正是因为没有建立完善的文档，导致有次会议上探讨的东西都没 有留下很多记录，导致下次总结时，没有人可以准确说明白上周所有的事项，而导致了 进度的延误，给我留下了深刻的印象。 来源： https://www.cnblogs.com/xp-thebest/p/12250783.html

　　用了将近一周的时间，终于把人月神话读完了。本想着今天把读书笔记全部发完，但是老师要求每天都要发表博客，所以我决定分三天发表。我看的是40周年中文纪念版。相比于原版增加了一些作者根据今天软件工程管理现状添加的一些新的观点与评论，看看哪些过时了，哪些依然有效。 　　人月神话在开头有一句荷兰谚语：Een schip op het strand is een baken in zee.[A ship on the beach is a lighthouse to the sea.] ----DUTCH PROVERB.意思是：岸上的船儿，如同海上的灯塔，无法移动。刚开始我感觉这句话牛头不对马嘴的，它想表达什么，岸上的船没用吗，那为什么还把它比喻成海上的灯塔。就这样我带着满腹的疑问与好奇开始读这本书。 　　第一章讲的是焦油坑，焦油坑是作者用来形容大型系统开发的一个概念。史前时代，恐龙、猛犸象、剑齿虎这些大型食肉动物碰到焦油坑也是没有办法挣脱的，而且越用力就越容易被沉入坑底。这种场景就像极了我们平时写程序时的尴尬，很多问题堆积到一块，以至于太过复杂，不知道从哪里下手。现在想到王建民老师的教导，对解决焦油坑真是恰到好处。老师说的很对分而治之，把大的问题分为一个个小的问题逐个解决，前台后台分开写，DAO层SERVERLATE层在分开写，一个工程的开发也是这样

人月神话的作者是Freder ick Prooks,Jr,Prooks博士是北卡罗来纳大学的一个计算机博士。 在他撰写的人月神话的第一章中，提到了人数和开发效率之间的问题。并不是人月多，开发效率越高，当任务划分到不能再划分时，再增加人数也是没有用的。 编程的乐趣在于创造，人总是可以从创造一个东西中获取快乐，看着一个东西从无到有的出现，本身就是很令人快乐的事情。 来源： https://www.cnblogs.com/jiaoaoshirenjinbu/p/12248801.html

你看看这标题，忒吸引人了。贵族专制、民主政治和系统设计。这就很使我想知道为啥系统设计能和贵族专制和民主政治联系起来； 贵族专制讲的就是这个概念的完整性系统设计必须由一个人来完成。（个人认为只能一个人.）但是一个人的决定不是任何时候都是正确的，所以这就有了民主政治的出现。在系统设计的时候，概念的完整性系统设计虽然由一个人来构建，但是这个人又不是死的，这种人肯定是善于吸收他人优良的意见和有很强的逻辑性。民主政治恰好给了其他程序猿发表意见的机会，这样就可以使得程序猿的意见可能得到应用。也极大的避免了概念性系统设计出现纰漏;等等 下面这章 “画蛇添足”在未看他的内容的时候我心里差不多已经可以想到这本说想要讲的是什么了。但是事实证明和我所想的还是有一些差别.喜欢其中的一句话：“一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，功能 x 不超 过 m 字节的内存和 n 微秒。这些值会在一开始作为决策的向导，在物理实现期间充当指南和对所有人的警示！“。 现在来看“为什么巴比伦塔会失败？”,说实话我并不知道他是谁，我还特意去搜了搜这个人的成就和贡献，对这个人有了一定的了解后才继续阅读《人月神话》的； 作者将巴比伦塔失败的原因之一归结于缺乏交流，缺乏组织。而我们能从中的来的教训之一在大型软件开发，要无比重视 交流 的重要性。本书初版之后四十余年的现在

在程序设计时，也要考虑空间的合理安排。根据类似软件的大小进行合理规划 。如果一个软件正常只需要20mb的存储空间，就最好不要让他变成100mb。由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，就像硬件开发人员会设立元器件数量目标，控制元器件的数量，想出一些减少零件的方法。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。编程需要技术积累，需要开发很多公共单元构件。每个项目要有能用于队列、搜索和排序的例程或者宏库。对于每项功能，库至少应该有两个程序实现：运行速度较快和短小精炼的。上述的公共库开发是一件重要的实现工作，它可以与系统设计工作并行进行。 像手册一样，技术纲领就是一个软件的“说明书”。那么文档大致需要： 做什么：目标。定义了待完成的目标、迫切需要的资源、约束和优先级。 做什么：产品技术说明。以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键的部分。 时间：进度表 资金：预算 地点：工作空间分配 人员：组织图。它与接口说明是相互依存的，如同 Conway 的规律所述：“设计系统的组织架构受到产品的约束限制，生产出的系统是这些组织机构沟通结构的映射。1”Conway接着指出，一开始反映系统设计的组织架构图，肯定不会是正确的。如果系统设计能自由地变化，则项目组织架构必须为变化做准备。

在做项目的时候，难免有分歧。有的人就觉得自己的好，想要应用自己的东西，画蛇添足，造成混乱。那么如何避免呢？ 结构式最好牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；对上述的建议保持低调和平静； 准备放弃坚持所作的改进建议。结构师如何避免画蛇添足——开发第二个系统所引起的后果？是的，他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能。项目经理如何避免画蛇添足？他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。 那么规划了这么多，光说不做是不行的。而且，要展现在书面上，文件中，最好有个项目手册。能让所有人都明白整个的架构和一些细节，都能理解。这和我们的统一建模语言UML课所学的差不多。都是做出能让客户和工程师都能理解并且进行交流的东西。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。手册不但要描述包括所有界面在内的用户可见的一切

人月神话的观点：是与非这一章，也是20周年版本新增的内容，20年的发展让初版的一些观点变得过时，但是仍然有不少观点仍然适用，因而作者在这一章里把之前的每一章的主要观点都抽离出来，并对已经过时了的观点做了说明，可以说这一章是整本书的精华了吧。 20年后的人月神话这一章很长很长，算是一篇单独的文章，讨论了很多软件开发相关的技术和管理思想，其中包括：1.概念完整性和结构师的重要性。2.开发第二个系统所引起的后果一 盲目的功能和频率猜测。3.图形界面的成功。4.没有构建舍弃原型一瀑 布模型是错的。5.增量开发模型更佳一渐进地精化。6.关于信息隐藏，Parnas是正确的。7.人月到底有多少神话色彩?一Boehm的模型和数据。8.人就是一切。9.放弃权力的力量。10.最令人惊讶的新事物是什么?数百万的计算机。11.全新的软件产业一 塑料薄膜包装。 今天读完人月神话之后，因为有很多地方都不是很懂，所以趁热打铁，去微博和知乎看了很多关于这本书的讲解，帮助我对这本书有了更进一步的理解。虽然书名是人月神话，但是它并不是说一个记述神话的小说本，它主要讲述了管理，特别是软件设计中的一系列问题及其相应的特点，并且做出了一系列的预言。而这一系列的预言引发了大量的争论，其中就有人月神话。 作为软件工程专业的学生，在这本书里我获得了大量的认同感。特别是书中提到的观点，比如：过分的设计是为画蛇添足

这本书虽然有做过一些细小的修订，用更新的思想进行扩充，但我还是认真阅读了这本书的第一版序言。其中，作者提到在很多方面，管理一个大型的计算机编程项目和其他行业的大型工程很相似，这一点虽然我没有亲身经历过，却能感同身受作者的思想和态度，我想，任何一件或大或小的完整工程都是有相通之处的，甚至是每一件事情。 在接下来的叙述中，作者把过去几十年的大型系统开发，比作一个可以让大型的和强壮的动物剧烈挣扎无果然后淹没的焦油坑，读到这里，不禁让我疑惑，但后面的解释让我豁然开朗，作者说大多数开发人员确实可以开发出可运行的系统，但各种团队，或大型或小型、或庞杂或精干，一个接一个“淹没”的主要原因就是那些表面上看起来好像没有一个单独的问题会导致困难，每一个都能被解决，但是当它们相互纠缠和积累起来的时候，团队的行动就会变得越来越慢，对问题的麻烦程度，是超乎每一个团队成员想象的。这跟我们在学习的过程中，问题不能积累是一样的道理，不随时解决到后期就变成无从下手的大麻烦。所以，解决问题的办法就是先去理解它，理清思路找到突破点。 作者清晰的分析了编程的系统产品以及作为一名程序员的苦恼，这让我对未来的职业规划有了更细致的认识和了解。让我知道了简单程序不仅可以升级为编程产品，还能作为接口组成编程系统，最终演变成编程系统产品。这些编程特有的烦恼：必须追求完美，由他人设定目标、供给资源、提供信息