《程序员修炼之道》简略笔记：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章：注重实效的项目

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

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

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

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

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

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

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

[转载+电子书下载]《程序员修炼之道》笔记与感想
[转载]<程序员修炼之道 >笔记与感想 1 我的源码让猫给吃了不要寻找借口,从自身找原因 2 软件的熵一句话:不以善小而不为,勿以恶小而为之. 从初期就要做好规范,不要因为是poc这 ...
《程序员修炼之道》笔记（一）
这几天开始看<程序员修炼之道>,也许不少人看了书的标题,第一时间会觉得这是鸡汤一类的书.但至少以我自己的感受来看,这是很棒的书,现代人文主义不是提倡自我意识嘛,自己感觉好的就是好的.况且人 ...
程序员修炼之道阅读笔记02
本周阅读了程序员修炼之道(从小工到专家)的第四章<注重实效的偏执>.第五章<弯曲,或折断>.第六章<当你编码时>的相关内容,对其中一些值得我们学习的地方进行了摘录. ...
程序员修炼之道阅读笔记01
读过这本书之后,我觉得这本书主要是在讲一个优秀的程序员应该具有的特点,素质和应该怎么去做.真正是一个程序员从小工到专家的修炼之路. 对于第一章"注重实效的哲学"有如下总结和理解 1 ...
《程序员修炼之道》笔记(九)
*续第八章注重实效的项目 1. 无处不在的自动化文明通过增加我们不假思索就能完成的重要操作的数目而取得进步. 无论是构建和发布流程.是书面的代码复查工作.还是其他任何在项目中反复出现的任务,都必 ...
《程序员修炼之道》笔记(八)
第八章注重实效的项目随着你的项目开动,我们需要从个体的哲学和编码问题转向讨论更大的.项目级的问题.我们将不深入项目管理的具体细节,而是要讨论能使项目成功或失败的几个关键区域. 1. 注重实效的团队 ...
《程序员修炼之道》笔记(二)
第二章注重实效的途径 1. 重复的危害 a) DRY-Don't Repeat Yourself.系统中的每一项知识都必须具有单一.无歧义.权威的表示. b) 重复是怎样发生的 Imposed Du ...
《程序员修炼之道》笔记(四)
第五章弯曲,或折断为了赶上今天近乎疯狂的变化步伐,我们需要尽一切努力编写尽可能宽松灵活的代码.否则,我们可能就会发现我们的代码很快就会变得过时,或是太脆弱,以至于难以清理. 1. 解耦与得墨忒耳法 ...
《程序员修炼之道：从小工到专家》阅读笔记03
<程序员修炼之道:从小工到专家>阅读笔记03 第六章当你编码时靠巧合编程应该避免靠巧合编程,避免依靠运气和偶然的成功.而要深思熟虑的编程. 怎样深思熟虑的编程:1)总是意识到你在做什么 ...
《程序员修炼之道》读书笔记（二）--第三周
<!doctype html> The pragmatic programmer(2).md 程序员修炼之道(二) 读书笔记--第三周第二章注重实效的途径 DRY原则:系统中的每一项只 ...

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

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

最新文章

热门文章