一、注重实效的哲学
1.负责。准备告诉别人什么做不到前，先演练一遍，他人可能会说：试过这个吗？提供选择和解决方案，
而不是借口，需要重构，建立原型，测试，别的资源？提出要求和寻求帮助
2.软件的熵。杜绝破窗户，一个破窗会让优秀的系统加速腐烂。
3.石头汤的故事，设计合理的需求目标系统愿景，团结一切力量，大家都觉得参与正在发生的更容易成功。
“我们要增加点。。。可能更好”并假装这不重要。
防止被温水煮青蛙，时刻关注周围的变化。
4.质量与需求之间的权衡。让用户及早的反馈并改良软件。
5.投资自己，提高价值。每年学习一门新语言，每季度阅读一本技术书籍，还有非技术书籍，参加组织打听别人在干什么，
试试不同的开发环境，跟上潮流。
6.交流。没有有效的交流，一个好想法就只是一个无人关心的孤儿。了解用户需求，设计文档，提案和备忘录以申请资源，
报告状态。大部分的时间需要花在交流上。
知道你要说什么？规划，写出提纲，提炼知道准确为止，问自己“这是否讲清楚了我要说的内容？”
了解听众的需要，兴趣，能力，避免枯燥让人厌烦的空谈。针对不同的人，投其所好，让听众感到兴奋。
选择时机。风格文档美观。让听众参与，做倾听者，及时回复。
二、注重实效的途径
1.避免重复。开发者之间的重复，安排项目资料管理员，促进交流，存放实用例程和脚本。
2.正交性。组件高内聚，低耦合。
可以提高生产率：容易测试，复用。可以降低风险。
项目团队分工明确，降低重叠。看一看每个需求改动时涉及多少人就可以判断正交性。
设计，模块化、组件、分层设计。“如果显著的改变某个特定功能背后的需求，有多少模块受影响？”正交系统中应该是1个。
编码，得墨忒耳法则（Law of Demeter），如果要改变对象的状态，让对象替你去做。
3.曳光代码，先构建简单能工作能演示的系统，再依次完善各个组件的功能，完成连接，逐步达到目标。
4.原型与便笺，制作架构原型
主要组件的责任是否得到了良好的定义？
组件之间的协作是否得到了良好的定义？
耦合是否得以最小化？
能否确定重复的潜在来源？
接口定义和各项约束是否可以接受？
每个模块在执行的过程中能否访问到所需的数据？是否能在需要时进行访问？
三、工具
纯文本，shell，用好一种编辑器，源码控制，调试就是解决问题，文本操纵语言
1.代码生成器
被动代码生成器，只运行一次，生成的结果一直使用。创建带注释的源文件，生成查找表。
主动代码生成器，每次需要结果时就运行。
不要太复杂，本质上是printf语句。
四、注重实效的偏执
早崩溃，如果它不可能发生，用断言确保它不会发生。
异常 异常应保留给意外事件，把异常用于异常的问题。
资源分配与释放，要有始有终。
五、弯曲或折断
1.解耦与得墨忒耳法则
耦合的症状：
这样的C/C++大型项目：用于链接某个单元测试的命令比测试程序自身还要长。
对某个模块“简单”的改动会传遍系统中的一些无关模块。
开发者害怕改动代码，因为他们不清楚哪些代码会受影响。
与性能的权衡，大量包装的方法也会带来运行时开销和空间开销。
2.元程序设计
让代码可配置----容易适应变化
使用元数据描述应用配置选项：调谐参数，用户偏好，安装目录等。
为一般情况编写程序，把具体情况放在别处----编译的代码库之外。将抽象放进代码，细节放进元数据。
3.时间耦合 并发与次序
分析工作流，以提高并发性
使用黑板协调工作流
六、当你编码时
1.不要靠巧合编程，要深思熟虑的编程
依靠可靠的事物，不要依靠巧合或假定，如果无法说出各种特定情形的区别 ，给以最坏的假设。
不要做历史的奴隶，如果已有代码不适用，抛弃它进行重构。
2.算法估算
3.重构
重复。违反了DRY原则
非正交的设计。你发现有些代码或设计可以变得更为正交
过时的知识。事情变了，需求转移了，你对问题的了解加深了。代码需要跟上这些变化
性能。为改善性能，你必须把功能从一个区域移到另一个区域
提示：不要试图在重构时增加功能。重构前确保拥有良好的测试，尽可能经常运行这些测试，这样一旦有破坏就能马上知道。
采取短小，深思熟虑的步骤，并在每个小步骤后测试。