06程序员修炼之道:从小工到专家之六

Chap8 注重实效的项目

 

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

 

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

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

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

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

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

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

自动化。

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

 

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

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

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

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

 

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

主要的测试类型有：

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

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

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

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

性能测试。

可用性测试。

测试的方法包括：

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

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

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

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

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

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

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

 

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

对于内部文档：

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

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

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

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

 

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

 

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