标签：低耦合 构建 提高 生成器 编辑 报告 帮助 特定 解决问题
一、注重实效的哲学
1.负责。准备告诉别人什么做不到前，先演练一遍，他人可能会说：试过这个吗？提供选择和解决方案，
而不是借口，需要重构，建立原型，测试，别的资源？提出要求和寻求帮助
2.软件的熵。杜绝破窗户，一个破窗会让优秀的系统加速腐烂。
3.石头汤的故事，设计合理的需求目标系统愿景，团结一切力量，大家都觉得参与正在发生的更容易成功。
“我们要增加点。。。可能更好”并假装这不重要。
防止被温水煮青蛙，时刻关注周围的变化。
4.质量与需求之间的权衡。让用户及早的反馈并改良软件。
5.投资自己，提高价值。每年学习一门新语言，每季度阅读一本技术书籍，还有非技术书籍，参加组织打听别人在干什么，
试试不同的开发环境，跟上潮流。
6.交流。没有有效的交流，一个好想法就只是一个无人关心的孤儿。了解用户需求，设计文档，提案和备忘录以申请资源，
报告状态。大部分的时间需要花在交流上。
知道你要说什么？规划，写出提纲，提炼知道准确为止，问自己“这是否讲清楚了我要说的内容？”
了解听众的需要，兴趣，能力，避免枯燥让人厌烦的空谈。针对不同的人，投其所好，让听众感到兴奋。
选择时机。风格文档美观。让听众参与，做倾听者，及时回复。
二、注重实效的途径
1.避免重复。开发者之间的重复，安排项目资料管理员，促进交流，存放实用例程和脚本。
2.正交性。组件高内聚，低耦合。
可以提高生产率：容易测试，复用。可以降低风险。
项目团队分工明确，降低重叠。看一看每个需求改动时涉及多少人就可以判断正交性。
设计，模块化、组件、分层设计。“如果显著的改变某个特定功能背后的需求，有多少模块受影响？”正交系统中应该是1个。
编码，得墨忒耳法则（Law of Demeter），如果要改变对象的状态，让对象替你去做。
3.曳光代码，先构建简单能工作能演示的系统，再依次完善各个组件的功能，完成连接，逐步达到目标。
4.原型与便笺，制作架构原型
主要组件的责任是否得到了良好的定义？
组件之间的协作是否得到了良好的定义？
耦合是否得以最小化？
能否确定重复的潜在来源？
接口定义和各项约束是否可以接受？
每个模块在执行的过程中能否访问到所需的数据？是否能在需要时进行访问？
三、工具
纯文本，shell，用好一种编辑器，源码控制，调试就是解决问题，文本操纵语言
1.代码生成器
被动代码生成器，只运行一次，生成的结果一直使用。创建带注释的源文件，生成查找表。
主动代码生成器，每次需要结果时就运行。
不要太复杂，本质上是printf语句。
四、注重实效的偏执
标签：低耦合 构建 提高 生成器 编辑 报告 帮助 特定 解决问题
原文地址：http://www.cnblogs.com/mlj318/p/6277282.html
