《程序员修炼之道》简略笔记：5-8章

囫囵吞枣地看完了。书的道理很浅显，也提出一些实际的做法。在 以后的工作中多回顾吧。

第5章：弯曲，或折断

这一章，主要是讲代码会不断变化，如何去应对这些变化。

解耦。编写羞怯的代码：不向别人暴露你自己，不与太多人打交道。这里有个例子，对传输的参数进行示例说明：应该直接提供你所需的东西，而不是自行“挖通”调用层次。

一种写法是：

public void plotDate(Date date, Selection selection){    TimeZone tz  = selection.getRecorder().getLocation().getTimeZone();    ....}

但是更好的写法是：

public void plotDate(Date date, TimeZone tz){    ....}plotDate(someDate, someSelection.getTimeZone());

因为，第一种方法，将三个类耦合在一起（Selection, Recorder, Location）。增加了我们的类所以来的类的数目。如果系统一个地方改了，那么别的地方也要更改。比如，Location可能不再直接包含TimeZone，那么这里的代码也需要更改。在第二种方法中，我们不关心TimeZone是来自与Recorder还是Recorder的某个对象。

传说的函数的得墨忒耳法则。这个法则规定，某个对象的任何调用方法都应该只属于以下情形的方法：1.它自身;2传入该方法的任何参数;3,它创建的任何对象;4,任何直接持有的组建对象。

但是，有时也会根据实际情况，如改善性能等，进行反规范化。如数据库的schema设计。（还没有概念）

元程序设计。元数据是关于数据的数据。元数据是对任何应用进行描述的数据——应用该怎样运行、它应该使用什么资源等。其实在平常都有这些的接触，如windows下的初始化文件（ini文件），java的property文件等。还有一些存储用户偏好的文件。所以，为一般情况编写程序，把具体情况放在别处——在编译的代码库之外。以纯文本方式表示配置元数据。有两种情况。一是配置变更时，需要重启。一是能在运行时重新加载其配置的程序。各有优劣，更根据实际情况选择。

时间耦合。通过研究工作流，使并行度最大。

它只是视图。里面提到的发布/订阅，与QT的signal/slot机制，有相关性。还有常用到的MVC，对于同一份数据，有多个表示等情况，也很实用。

黑板。协同与合作？比如QT的images.qrc?大家都可以看到有什么在里面。也可以避免重复。

第6章：当你编码时

编码不是机械工作。

靠巧合编程。积极地参与编码过程。在WS的一次提交，因为不理解各widget的parent关系问题，参考现有的组建，将parent全设置为0。虽然程序能运行，但是在析构时会出现问题，所以不对。因为不理解，只是能运行便认为可以了。

算法速率。嗯，之前提到了。常识的估算。简单循环——o(n)，嵌套循环——o(m * n)，二分法——o(ln(n))，分而治之——o(nln(n))，组合——涉及到阶乘，所以使用启发式算法去解决。

重构。不要容忍破窗户。在以下情况，需要重构：重复、非正交、过时的知识、性能。为了重构，确保拥有良好的测试。

易于测试的代码。编写代码，让代码易于测试。编写单元测试，比如在java的每个类里加一个main函数，使用C++的#ifdef来选择性进行等等。还有测试设备。或者是类似hudson这种持续构建工具，自动化测试等。

邪恶的向导。有一些向导会帮我们生成很多代码。但是有风险，如果这些代码你不知道他们的作用。

第7章：在项目开始之前

需求之坑。“完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的。”找出用户为何要做特定事情的原因，而不只是他们目前做这件事的方式。如在WS时，用户需要在打开wifi后，自动连接后不自动退出，因为有时需要进行wifi热点的选择。但在我们的实际工作中，大部分时间其实用户不是希望所有的都不自动退出，而是要提供给他们可选择的方式。所以，我们最终的实现方式是，在wifi设置时，不自动退出，其他情况自动退出 。

好的需求文档会保持抽象。但并不是含糊不清。抽象比细节活得更长久。

还有“紧身衣”效应。没有给编码者留下任何解释余地的设计剥夺了他们发挥技巧和艺术才能的权利。如上面我们的wifi配置问题。

再抹一层薄薄的薄荷。我们很容易被吸进“只是再增加一个特性”的大漩涡。

圆圈与箭头。盲目地采用任何技术，而不把它放进你的开发实践和能力的语境中，这样的处方肯定会让你失望。

第8章：注重实效的项目

这一章对整个项目进行总体的操控。

回顾前面章节的一些内容。不留破窗户，煮青蛙，交流，不要重复自己，正交性，自动化，知道何时停止绘画。

自动化，管理整个项目，当然要自动化的方式来减少手动操作量，也减少失误。

无情的测试。各种测试，性能测试、可用性测试等。单元测试、集成测试等。对整个系统而言，很重要。保证系统的正确性。

全都是写。记录文档同样重要。但是文档也可使用自动化生成的方式，保证与代码一致。

极大的期望。多与用户交流，保证在正确的道路上行驶。同时，额外的一英里，温和地超出用户的期望。