读完了5-11章，收获颇丰，现在想分享一下自己的心得体会和一些要领。
作者提到有一种普遍的倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，所以第二个系统是设计师们所设计的最危险的系统。想到作者举的两个例子，一个是被嵌入到 7090 的 IBM 709 系统，709 是对非常成功和简洁的 704 系统进行升级的二次开发项目。709 的操作集合虽然被设计得如此丰富和充沛，但却只有一半操作被常规使用。Stretch 计算机的结构虽极富有创造性，极端复杂，非常高效。但不知为什么，同时也感觉到粗糙、浪费、不优雅，以及让人觉得必定存在某种更好的方法可以代替他。这些都是过分开发第二个系统带来的画蛇添足所引起的后果。就像是我自己的编程，通常第一次编得时候我会尽量的想让他简洁一点，避免出错。第二次再去丰富他。可是这个时候我经常会去纠结一些特别小的细节，或者总会不经意地再加一堆小东西，结果原本能运行的程序反而崩了，而且程序反倒变得很混乱，貌似很复杂的样子，但是根本找不到重点在哪儿，偏离了问题本身。作者提出了一些避免画蛇添足的方法，我觉得有一些对现在的我来说也是很实用的，虽然无法跳过二次系统。但可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能，时刻保持对特殊诱惑的警觉，不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。
"因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现”。巴比伦塔的管理教训令人印象深刻，，为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。建立怎样的组织架构是项目成功的关键。而组织架构的成功建立离不开交流。团队应该以尽可能多的方式进行相互之间的交流。非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。举行常规项目会议，会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。一定要记住交流和交流的结果组织是成功的关键。如果想做出好的作品，一定要学会与优秀的人沟通交流，不断发现bug，不断弥补完善自己。
做好文档工作很重要。书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。每个文档可以作为检查列表或者数据库。及时得做好文档记录，可以帮助我们都向着相同的方向前进。文档使各项计划和决策在整个团队范围内得到交流。只有书面计划是精确和可以沟通的。通过遵循文档开展工作能帮助我们清晰和快速地设定自己的方向。以前经常不理解老师为什么经常要我们写程序分析总结。现在想想通过文字记录可以帮助我去找到自己的不足点，从而确定努力的方向。而且我还可以通过对这些总结周期性的回顾，知道哪些需要重点进行更改和调整，不断完善程序。
唯一不变的就是变化本身。目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免。抛弃原型概念
本身就是对事实的接受——随着学习的过程更改设计。未雨绸缪很重要。我们在平常的编程中也是，要在提交自己的作品之前，先预想一下它可能会出现的错误，比如程序丢了怎么办，这就需要我们提前做好备份。变化是不可避免，随时有可能会发生的，我们唯一能做的就是未雨绸缪，提前做好万全的准备。
emmmmm大概就是这些。