• 持续保持代码干净、简单。
• 重构，使你觉得任何有必要的时候都可以大胆的改进。对模式加深认识：不死搬硬套，要知道该何时用，以及如何逐步引入。
• 着眼于应付未来变化的设计，知道现在做出的决策可能要过后进行修改。
• 知道如何将设计传达给必要的人，用代码、图表和最重要的：交谈。

　　“……哈佛商学院的Leslie Perlow，作为人种学者，对多个国家的几支软件工程师团队进行了一项研究。这几个团队在做类似工作时的工作效率几乎一样。但Perlow发现，这些团队工作方式不同，对成员的影响也截然不同。”

　　“在印度，工程师们遇到问题时会直接找团队里的其他专家。他们之间相互的承诺关系使每个人的工作时间往往很长，因为每个人都觉得必须让同事找得到自己。”

　　“在中国，工程师们工作时很少互相说话。所有的帮助请求都汇总到项目经理那里。这使得每个人都严重依赖项目经理。”

　　“在匈牙利……”

　　“Perlow说，这三个团队都相信没有其他的工作方式，他们只是按照全球市场的要求来行动。然而印度团队的做法会让人筋疲力尽；中国团队受制于上司；只有匈牙利团队的做法使员工拥有自己的生活……”

　　“……曾经的我就是一个为技术而技术的人，当一个项目启动的时候，我首先考虑的就是如何展现自己的功力，如何编写优雅的程序，而忽视了根本性的问题：需求。真正让一个软件产生价值的就是需求。少了需求，软件的意义也就荡然无存了。当一个人做事连自己的目标都搞不清楚的时候，不做错事，已经要感谢上天的眷顾了。没有正确的目标，其它的努力只是让自己在未卜之途上越走越远。有许多部影片为我们展示了邪恶科学家的威力，他们不是不努力，只是弄错了方向……”

　　“……谈到设计，最好的设计标准还是那条经典的“高内聚，低耦合”。了解了这么多的设计手法，体会那么多的设计原则，到最后，基本上都能归结到这条标准上来。设计的过程是一个分分合合的过程，先是把系统分拆，再把功能相近的东西合并，这样就形成了一个模块，有人叫服务、子系统、类、组件、函数、方面……，都是一回事。设计者需要考虑的就是让（各个模块实现者）怎么去做这个游戏，以便让各人能够独立工作而不致于相互影响，这就需要请出“高内聚，低耦合”作为衡量标准。模块之间的合同就是我们常说的“接口”，它可能是函数调用，可能是参数传递，可能是共享数据，也可能是远程调用。总之，有了合同好办事，谁的问题谁负责……”