每日博客

*在项目开始之前

需求之坑：需求往往没有被良好地表达，需求、政策与实现往往模糊不清，然而这对于编程很不利，因为需求需要与实现隔离，需求不应有太大变动而政策时常变化。要从用户的角度思考问题。

为了理清需求，可以建立需求文档。需求文档需要有好的形式化，应该由目标驱动。文档应该保持抽象，规定需要的功能即可，过于拘泥细节会限制后续发挥。文档需要远视，不要对一些可能改变的规则进行默认，比如上个世纪将年数默认为19开头，只用存储后两位。为了达到远视，不需要增加许多莫名其妙的功能，而是应该对功能进行抽象，而不要嵌入代码中。

不要不断地增加新特性；为项目维护一个词汇表便于沟通；将需求文档公开用于讨论，就像许多别的文档一样。

解开不可能的问题：对于问题的约束有真正的约束，也有一些是表面上的约束。要找到那些真正意义上的约束并给予尊重，对表面上的约束可以适当予以摒弃。

解决“不可能的问题”时，可以问自己这些问题：有更容易的方法吗？我是在解决实际问题还是被技术细节转移了注意力？这件事情为什么是一个问题？什么使它难以解决？它必须以这种方式完成吗？它真的必须完成吗？

等你准备好：有时候要依靠直觉，直觉觉得仍有疑虑时不该开始。为了将疑虑与单纯的拖延区分，可以通过开始构建原型检查自己的疑虑在什么地方，或者自己只是单纯懒于工作。

规范陷阱：规范重要，但不应归于细致流于琐碎。自然语言本身十分晦涩，过于琐碎的规范往往不能精确地描述意图描述的细节，而且会限制程序员的发挥空间。

圆圈与箭头：通过形式方法描述项目很流行，但有一些缺点：1. 形式化的表达需要由人来阐释含义，不如原型的展示清楚明白。2. 形式方法似乎鼓励专门化，但专门化会带来人力的浪费和不好的编码体验。一个小组应该分工，但不应该被分裂成几个不必要的部分。每个人都应该了解项目系统的大体。3. 形式方法往往无法描述系统的动态性。

形式方法只是一个工具，可以使用，但不要被限制。……事实上这个原则似乎适用于所有工具，包括ide、语言、框架等。

*注重实效的项目

项目开发中的注意事项与小技巧。

注重实效的团队：针对团队，前述的技术全都有效。

不要留破窗户：在团队中，不要容许小的、没有人愿意去修改的小错误。

煮青蛙。随时注意项目和环境的新变动，注意项目范围的扩大、新的特性和需求等。不要让变动失控。

交流：文档、术语应该一致。为了加强交流，可以使用一个团队名称，尤其是奇怪的名称，以带来归属感。（我们组的名称就挺奇怪的……）

不要重复自己：要有良好的交流与分工，开发过程中职能不要重复。如果不该自己负责的地方出现了问题，不要自己解决，而应该去找负责人。

正交性：用模块功能将成员分组，而不要根据分析师、程序员、测试人员这样的等级划分将成员分组，每个团队自给自足。分析、编程、测试是不正交的，而且隐含了等级关系，不利于合作。

自动化。

知道何时停止：要给别人空间，尤其是组长要给组员空间。

无处不在的自动化：不要做重复的工作。

用批处理文件/脚本实现可自动化的内容。用cron等工具实现周期性的行为，如备份、网站构建等。

项目编译时，用makefile生成代码、编译、测试。要将构建自动化，定期编译并测试。如果构建与常规构建不同，如有特殊的版本号或某个优化方式，可以用单独的make目标表示，并一定要另外测试。

对项目自动化管理。如果用网站实现内部沟通，网站应该自动生成，这同样是DRY原则的应用。批准流程也可以自动化。

无情的测试：要积极地测试，最好自动化测试。

主要的测试类型有：

单元测试，对单个模块进行测试。

集成测试，对模块集成的子系统进行测试，其实是单元测试的拓展。

验证和校验，检查系统是否满足用户需求、是否能够处理现实数据。

资源耗尽、错误及恢复。可能的限制包括：内存、磁盘、CPU带宽、磁盘带宽、网络带宽、视频分辨率、挂钟时间、调色盘……要尽量检查环境限制。如果失败，要保存状态、避免工作丢失。

性能测试。

可用性测试。

测试的方法包括：

回归测试，改动代码后检查测试输出与之前是否一致，以检查在改动时有没有破坏功能。

测试数据，可以从现实世界获取或人工合成。人工合成的数据包括随机数据和特殊的极端数据。

测试GUI。首先测试GUI背后的逻辑，确定没有问题之后用工具或人工测试GUI。遗憾的是测试GUI的工具大多不完善。

对测试进行测试，故意引发bug，观察测试系统能否捕捉。

彻底测试是不可能的。（完美永远是不可能的……）

普通测试的时间应该尽可能频繁，一旦代码存在就要测试。可以自动化测试。压力测试之类的特殊测试可以不那么频繁，但仍要定期测试。

如果发现过一个bug，那么要将这个bug加入测试集，而不要相信这个bug不会复现。

全都是写：讲文档的写法。文档分为内部文档（源码注释，设计与测试文档）和外部文档。

对于内部文档：

代码中的注释应该解释代码要做何事及为何这么做，而不应该解释如何做。如何做会与代码重复。代码中的变量名应该清晰易懂，贴合功能。注释中不应该出现：代码中的函数列表，修订历史，文件使用的其它文件列表，文件名。这些都可以通过其它工具得到。

可执行文档：可以对文档进行解析，分析出模式自动生成代码，如数据库schema。

文档很容易过时，所以在网站显示往往比打印更方便。

可以使用标记语言，如html（我又想到了markdown）编写文档，这样更方便、功能更强大，且内容和外观可以解耦。

极大的期望：满足用户需求很重要，所以最好时时就需求进行沟通，避免取得的进展不是用户想要的。不过为了避免用户缺乏惊喜，有必要比需求略多一点特性。

傲慢与偏见：有必要对代码进行署名，可以带来自豪感，同时减少糟糕的编程。但是要避免领地意识。

总结：这本书给了我很多启发，我对于大型编程更加了解。

另外，第一次写读书笔记格式有些难看，下次我会进行改进。