高效程序员的45个习惯·敏捷开发修炼之道（Practices of an Agile Developer）读书笔记

首先，这本书值得再看一遍——这次的阅读，有很多东西都是知其“形”，不知其“神”的，这导致了我对其中某些建议持怀疑态度，接受了的建议也有待商榷。

总之，先记录本书的一些信息：

Practices of an Agile Developer

高效程序员的45个习惯·敏捷开发修炼之道

美·Venkat Subramaniam和美·Andy Hunt著；钱安川、郑柯译。

人民邮电出版社，图灵程序设计丛书；2010年第一版。

于2017年12月1日读完第一遍。

 

 

 

1.

“敏捷式的单元测试正是采取了相同、相似的过程，并且还让其更上一层楼，不要扔掉桩程序，你把它保存下来，还要让其可以自动化地持续运行，你编写代码来检查其具体值，而不是手工检查那些感兴趣的变量。

用代码来测试变量的具体值（以及跟踪运行了多少个测试），已经是非常普遍的做法。你可以选择一个标准的测试框架，来帮助你完成简单的编写和组织测试的工作，如....Web Service的HttpUnit等等，实际上，对任何你可以想象到的环境和语言都有其对应的单元测试框架，.....(这有一个网址说是里面有这些框架，然而我试了一下网址已经不存在了)”

 

2.架构设计

开始模仿页面或者做工程的时候，要像书里说的一样列出一个表：

      1.对于整个项目，等待完成的任务列表(把设计分解成步骤，加上预估完成所需的时间和建立项目的时间；完成后的功能有什么）。

      2.每日的任务列表。（1和2用yes or no标注是否完成和完成时间）

      3.用户跟进。由于是做自己的项目，所以完全可以把自己当开发人员和用户来用！就像自己教自己学习一样。每写好一个（或者一部分）可用的功能，就停下来测试和反馈这个功能是否符合预期，有没有要改的地方。

      4.还有，重看这本书时补充。

 

3.C++中的注释：

单行注释写于代码中，界定符对注释写于代码开头用于说明为什么要用这个函数/这段代码及其优缺点。
上面这段话写在所有代码的开头。

 

4.怪物笔记与问题解决日志；战时笔记

以“怪物笔记”的形式总结代码笔记和代码实现案例。

以下是原因：

最近写程序的时候进入一种奇葩的状态。。。也是在逐渐理解了一些东西后才有的。
以前有构思过一个架空的魔法世界（借鉴了《地海巫师》）。在那个世界里，一个人要想释放魔法就必须念咒语，一个咒语由名字和解释组成，名字主要是元素神命名，念的解释越接近元素神的解释，威力就越大，每个元素神都有自己的元素书，里面记载了许多名字和解释，包括一些强大但没多少人知道的禁咒。举个例子：
a说“伟大的风神，请....”，当这个人还是一个菜鸟的时候，发自内心的觉得风神伟大，所以用“伟大”这个形容词会让威力越来越强（相对地，别人可能用美丽之类的形容词也可以，只要内心真的这样认为）；但是随着菜鸟越来越强，到了快比肩元素神的地步时，还用伟大反而威力就变得很差了，因为这个时候菜鸟已经不再认为元素神是伟大的了（也有异类）。基于这几点，这个世界是以理解为修为，魔法师们疯狂追寻的除了“解释”外就是魔法术的“名字”了——毕竟没几个人能到神的地步自创名字。
这个小说只写了一点点，后来没时间就没继续了，这个暂且不说了。
那么，这个小说的构造又关我现在在学的编程什么事呢？
前几天写程序的时候突然发现，编程语言=元素主神，变量（函数、api等）的命名=名字，具体的实现代码=解释——真是像啊！编程的学习道路不也是这样么，刚开始读规范学规则（学主神规定的名字和解释），学得越像越厉害，这个像却又因人而异，有些人足够强后就可以自己造轮子了（自己创名）
在我想到这些后，每次写代码的时候都中二感十足啊。。。需求就是怪物，我要写出完美的名字和实现才能把她干掉！只有最强大的魔法才能一次杀死她，不然就得用好几个魔法.....大佬就是主神，语言的建立者就是主神，什么C++神，HTML神啥的。

具体的格式参照（由于自己项目不多，所以这个格式很不成熟）：

怪物笔记

怪物名：要解决的需求的简称（附上第一次遇到的时间，以及说明是不是另一个怪物的变种——所谓变种，就是有没有与之有联系或者相似的需求）

历史传记：详细的需求解释（历史背景比如是在哪个项目第一次遇到，有哪些参考资料等）

代号：解决过程中一些重要的函数名、变量名（重在精，不要多）

击败方法：代码写上（重要的片段+其余简单部分的文字描述，或者干脆整个项目的地址贴上），相关的战时笔记（见下）

思路（最最重要的东西，可以是整个思考的过程，分点说之类，比如一开始我是.....后来我发现了一些问题，这些问题是.....解决了这些问题后我继续.....最终，我决定用.....最好，我进行以下总结.......整个过程一开始我使用了....语言和......框架，我还为此设计了一些测试模块、自动化部署（这些只是简单一提，具体的写在“卷轴制作”里）......）。

卷轴制作：是否能做成一个封装的程序快，或者是否能自动化？框架？API？问题解决日志？每天日志等（附上写好的框架、API等的地址，也就相当于下一个怪物笔记）

参考：记录一些其它的东西（比如当同样功能发现有不同的实现办法时，记录下这些办法，用十分钟时间思考各自的利弊，记录下来。很可能刚开始找不出来区别，先记着，以后遇到再说）。

关键字：用于搜索这个怪物的关键字！就像是论文的关键字一样，找到以前解决过的东西最快的办法就是把怪物笔记做成一个可搜索的笔记，并且用关键字进行快速搜寻！可以通过关键字搜索也可以全文搜索，弄成知网的那种健全的搜索机制。

“以怪物笔记的形式总结代码笔记和实现”要做个对比，即有几次不做任何设计就开始写程序与之对比优缺点，总结

战时笔记

战役名：项目名+项目完成后的地址

影响：后续的补充的运维记录、笔记等完成后继续做的一些工作。

环境：遇到的Bug、需要使用的系统环境（框架版本、语言、测试模块）等（链接到相关的怪物上）

过程：架构设计（肯定是有好几个版本的！按照出现的顺序结合后面的内容写），思考路程（和怪物笔记的不同！怪物笔记是“短的”，这里记录的是整个的！），其中每个点的详细解决过程（如果是已经在怪物笔记中记录过的，贴链接）。

战后总结：整个项目学到的东西、总结；为解决的东西，未完成的构想等。

参考：记录一些其它的东西；参考资料。

 

其实怪物笔记和书里提到的问题解决日志很像！但是仍有区别。怪物笔记是一个单独的东西，而不是一次战斗的全记录！千万分清楚了！（怪物笔记是某个实现的案例记录，问题解决日志则是按项目来写的总的案例记录！所以上面除了有怪物笔记外还设了一个战时笔记）

书里推荐的格式：

1.问题发生日期。

2.问题简述

3.解决方案详细描述

4.引用文章或网址，以提供更多细节或相关信息。

书里写的注意事项：

1.找到以前的解决方法非常关键。使用足够的关键字，可以帮助你在需要的时候发现需要的条目。

 

 

5.代码复查的检查列表，可以由之前编码中常见的错误和bug为源头借鉴设计

 

6.“要准备一台供后台运行持续构建的机器....以捕获任何发生的问题。如果你对这些领域不熟悉，去买一本设置相关环境和运行机构的书（原文有推荐：a practical guide to sucessful software proceedings，但是找不到....） ......入门工具箱starter kit系列图书可以帮你完成如何在特定环境下配置版本控制、单元测试以及自动化等具体细节。”