一、注重实效的哲学

1.负责。准备告诉别人什么做不到前，先演练一遍，他人可能会说：试过这个吗？提供选择和解决方案，

而不是借口，需要重构，建立原型，测试，别的资源？提出要求和寻求帮助

2.软件的熵。杜绝破窗户，一个破窗会让优秀的系统加速腐烂。

3.石头汤的故事，设计合理的需求目标系统愿景，团结一切力量，大家都觉得参与正在发生的更容易成功。

“我们要增加点。。。可能更好”并假装这不重要。

防止被温水煮青蛙，时刻关注周围的变化。

4.质量与需求之间的权衡。让用户及早的反馈并改良软件。

5.投资自己，提高价值。每年学习一门新语言，每季度阅读一本技术书籍，还有非技术书籍，参加组织打听别人在干什么，

试试不同的开发环境，跟上潮流。

6.交流。没有有效的交流，一个好想法就只是一个无人关心的孤儿。了解用户需求，设计文档，提案和备忘录以申请资源，

报告状态。大部分的时间需要花在交流上。

知道你要说什么？规划，写出提纲，提炼知道准确为止，问自己“这是否讲清楚了我要说的内容？”

了解听众的需要，兴趣，能力，避免枯燥让人厌烦的空谈。针对不同的人，投其所好，让听众感到兴奋。

选择时机。风格文档美观。让听众参与，做倾听者，及时回复。

二、注重实效的途径

1.避免重复。开发者之间的重复，安排项目资料管理员，促进交流，存放实用例程和脚本。

2.正交性。组件高内聚，低耦合。

 可以提高生产率：容易测试，复用。可以降低风险。

项目团队分工明确，降低重叠。看一看每个需求改动时涉及多少人就可以判断正交性。

设计，模块化、组件、分层设计。“如果显著的改变某个特定功能背后的需求，有多少模块受影响？”正交系统中应该是1个。

编码，得墨忒耳法则（Law of Demeter），如果要改变对象的状态，让对象替你去做。

3.曳光代码，先构建简单能工作能演示的系统，再依次完善各个组件的功能，完成连接，逐步达到目标。

4.原型与便笺，制作架构原型

主要组件的责任是否得到了良好的定义？

组件之间的协作是否得到了良好的定义？

耦合是否得以最小化？

能否确定重复的潜在来源？

接口定义和各项约束是否可以接受？

每个模块在执行的过程中能否访问到所需的数据？是否能在需要时进行访问？

三、工具

纯文本，shell，用好一种编辑器，源码控制，调试就是解决问题，文本操纵语言

1.代码生成器

被动代码生成器，只运行一次，生成的结果一直使用。创建带注释的源文件，生成查找表。

主动代码生成器，每次需要结果时就运行。

不要太复杂，本质上是printf语句。

四、注重实效的偏执

[阅读笔记］程序员修炼之道