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

一、注重实效的哲学

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原则

非正交的设计。你发现有些代码或设计可以变得更为正交

过时的知识。事情变了，需求转移了，你对问题的了解加深了。代码需要跟上这些变化

性能。为改善性能，你必须把功能从一个区域移到另一个区域

提示：不要试图在重构时增加功能。重构前确保拥有良好的测试，尽可能经常运行这些测试，这样一旦有破坏就能马上知道。

采取短小，深思熟虑的步骤，并在每个小步骤后测试。