程序员修炼之道读后感(八)

 

注重实效的团队

不要留破窗户——对软件质量负责，要及时修复缺陷和错误，可以考虑配置一个“质量官员”；

煮青蛙——确保每个人都主动监视环境变化，要不要设置一个“首席水情检测官”呢？

交流——沉默寡言的团队是最糟糕的团队，导致文档、设计、编码……一切工作的混乱；

不要重复你自己——还是要团队内的交流（项目资料管理员）；

正交性——项目活动不会孤立发生，Organize Around Functionality Not Job Functions.围绕功能，而不是工作职务进行组织；

自动化——确保一致和准确的方式是使团队所做每件事情自动化；

给团队每个成员足够空间，支持他们，让他们在项目中以自己的方式闪亮。

 

无处不在的自动化

我们需要保证项目的一致性和可重复性，而人工流程不能保证一致性，也无法保证可重复性，因此我们应该尽可能的使用自动化。

一切都要自动化

Don’t Use Manual Procedures.不要使用手工流程

通过一些自动化工具，如cron等，使任务（例如备份、夜间构建等）在无人照管的情况下自动地、周期地运行。

让如makefile进行如项目编译、生成代码、回归测试、信息生成（包括Web信息）以及最终的构建等，此类工具还有Ant

构建自动化：在晚上进行完整构建，运行所有测试

自动化管理：包括了资料与网站自动生成，一些工作流程自动化等；

推荐书目《项目自动化之道-如何建构、部署》

 

无情的测试

Test Early,Test Often,Test Automatically.早测试，常测试，自动测试

测试如捕鱼，捕什么鱼用什么测试

好的项目拥有测试代码可能比产品代码还要多

Coding Ain’t Done ‘Til All the Test Run.要到通过全部测试，编码才算完成

测试种类：

1． 单元测试：对某个模块进行演练的代码

2． 集成测试：组成项目的主要子系统能工作，并很好协同

3． 验证和校验：满足客户需要吗？

4． 资源耗尽、错误和恢复

5． 性能测试、压力测试和负载测试

6． 由真实用户在真实环境条件下进行可用性测试

测试方法：

1． 回归测试：测试输出的对比

2． 测试数据：大量的、强调边界条件的、展现特征统计属性的数据

3． 演练GUI系统

4． 对策是进行测试：Use Saboteurs To Test Yout Testing.通过“蓄意破坏”测试你的测试。（故意引发一些测试）

5． 彻底测试：覆盖分析（Coverage Analysis）Test State Coverage,Not Code Coverage.测试状态覆盖，而不是代码覆盖

6． 测试时间：当项目开始后，随时测试，千万不要流到最后一分钟

Find Bugs Once.一个Bug只抓一次.

 

全都是写

文档和代码时同一底层模型的不同视图，不要让文档变成二等公民

将文档与代码进行结合，使用如JavaDoc之类的工具自动产生文档

Treat English(Chinese) as Just Author Programming Language.把英语（中文）当作又一种编程语言

Build Documentation In, Don’t Bolt It On.把文档建在里面，不要拴在外面.

匈牙利表示法：把变量类型信息放在变量名自身里.

不应出现源码注释：

1． 文件种的代码导出的函数列表

2． 修订历史

3． 该文件使用其他文件列表

4． 文件名

可执行文档：例如数据库Schhema或带有标记的纯文本

DocBook是一种机遇SGML的标记语言

 

极大的期望

项目的成功是由它在多大程度上满足了用户的期望来衡量

Gently Exceed Your Users’ Expectations.

温和地超出用户的期望

管理期望（managing expectations）：主动控制用户对他们能从系统中得到什么应该抱有的希望.

如果你和用户紧密协作，分享他们的期望，并同他们交流你正在做的事情，那么当项目交付时，就不会发生多少让人吃惊的事情了.

 

傲慢与偏见

Sign Your Work.在你的作品签名

尊重别人的代码，对自己的代码负责，使自己的签名变成质量的保证。为自己的代码负责，告诉别人“这就是我的代码”