《程序员修炼之道》读书笔记（8）：注重实效的项目

本文主要是介绍《程序员修炼之道》读书笔记（8）：注重实效的项目，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

第8章：注重实效的项目

随着项目开动，我们需要从个体的哲学与编码问题，转向为项目级别的问题。

本章将讨论影响项目成败的几个关键区域。

41《注重实效的团队》

本书在先前讨论了帮助程序员个体更好的方法，这些方法对团队也有效。
下面将针对团队，来重述前面部分章节。

不要留破窗户。团队不应该容忍那些小小的、无人修正的不完美。
煮青蛙。团队更容易被煮熟，因为每个人都觉得别人会在监视环境的变化。
交流。不仅团队内部需要交流，团队也需要和外部交流。
DRY。消除团队成员之间的重复。
正交性。我们喜欢围绕功能、而不是工作职务进行组织。
自动化。尽量自动化，这很重要。
知道何时停止绘画。抵抗不继续画下去的诱惑。

42《无处不在的自动化》

让一切尽可能地自动化。尽量避免手动流程。

例如：

项目编译
生成代码
回归测试
构建

还可以让一些管理方面地事物自动化，例如：

网站生成（在线文档、报告等）
批准流程

我们有很多工具可以帮助我们自动化，比如命令行、make、各种脚本等等。或者也可以自己开发工具。

让计算机去做重复、庸常的事情——它们会做得比我们更好。我们有更重要、更困难的事情要做。

43《无情的测试》

早测试
常测试
自动测试

测试什么？

单元测试。对某个模块演练得代码
集成测试。子系统之间能否协同。
验证和校验。看是否能满足需求。
资源耗尽、错误及恢复。资源包括：内存空间、磁盘空间、CPU带宽、挂钟时间、磁盘带宽、网络带宽、调色板、视频分辨率等。
性能测试。
可用性测试。真正让用户测试。

怎样测试？

回归测试。把当前得输出和之前得输出对比。
测试数据。你可能会用到现实数据和合成数据。
演练GUI系统。
对测试进行测试。确保测试确实起效。
彻底测试。事实上你不可能确定所有BUG都被找到了，但是有些工具可以帮助你，比如覆盖分析。

何时进行测试？

尽快
如果有限制，则确保它出现在计划中。

如果有BUG漏过测试网——增加新的测试，以便下一次抓住它。

44《全都是写》（文档）

你应把文档视为开发过程中的完整组成部分。如果可能的话，可以将文档放在代码中。

为项目制作的文档分为两部分：

内部文档：源码注释、设计、测试等等。
外部文档：用户手册等。

关于代码中的注释：

代码应该有注释，但是太多注释和太少注释一样糟糕。

一般而言，注释讨论为何要做某件事、他的目的。
至于如何去做，代码已经说明了。因此就不需要注释了，而且违反了 DRY。

注释给了你机会，可以把那些难以描述、容易忘记、却又不能记载在别的地方的东西记录下来，例如：

工程上的权衡
为何要做出某些决策
放弃了哪些方案
任何不明了的事儿

JavaDoc所提倡的注释程度似乎是合适的：

/*** Find the peak (highest) value within a specified date* range of samples.* @parm aRange Range of dates to search for date.* @parm aThreshold Minimum value to consider.* @return the value, or null if no value found greater than or equal to the threshold.*/public Sample findPeak(DateRange aRange, double aThreshold);

不应该出现在文档中的：