《程序员修炼之道——从小工到专家》阅读笔记03

第七章——在项目开始之前

不要搜集需求，挖掘它们。需求是对需要完成的某件事情的陈述。

“搜集”一词似乎在暗示，一群快乐的分析师，随着背景音乐播放的温柔的《田园交响曲》，寻觅散布在四周地面上的智慧金块。“搜索”暗示着需求已经在那里——你只需找到它们，把它们放进你的篮子，就可以愉快地上路了。              （写这句话呢，纯粹是觉得比较有意思>_<）

与用户一同工作，以像用户一样思考。开采需求地过程也是开始与用户群建立和谐地关系、了他们对你正在构建地系统的期许和希望的时候。需求不是架构。需求不是设计，也不是用户界面。需求是需要。

制作需求文档时的一大危险是太过具体。抽象比细节活得更长久。

倾听反复出现的疑虑等你准备好再开始。

编写规范是一项重要职责。对有些事情，“做”胜于“描述”。

不要做形式方法的奴隶。我们使用形式方法，但始终要记住，形式开发方法只是工具箱里的又一种工具。昂贵的工具不一定能制作出更好的设计。

第八章——注重实效的项目

质量是一个团队问题。团队作为一个整体，不应该容忍小错误。在团队中，应确保每个人都主动的监视环境的变化。团队中的开发者必须相互交谈。不要重复你自己，这样的重复会造成工作的浪费。围绕功能、而不是工作职务进行组织。确保一致和准确的一种很好的方式是使团队所做的每件事情自动化。自动化是每个项目团队的必要组成部分。同时知道何时停止。（内容和前面的有一点重复）

不要使用手工流程。提倡生成代码，以根据公共来源派生知识。让计算机去做重复、庸常的事情，它会做得比我们更好，我们有更重要、更困难的事情要做。

早测试，常测试，自动测试。bug发现的越早，进行修补的成本就越低。事实上，好的项目拥有的测试代码可能比产品代码还要多。要到通过全部测试，编码才算完成。你需要测试的主要类型有：单元测试，集成测试，验证和校验，资源耗尽、错误及恢复，性能测试，可用性测试。怎样测试：回归测试，测试数据，演练GUI系统，对测试进行测试，彻底测试。测试状态覆盖，而不是代码覆盖。任何产品代码一旦存在，就需要进行测试。一个bug只抓一次。

把英语当作又一种编程语言。为项目制作的文档基本上有两种：内部文档和外部文档。把文档建在里面，不要拴在外面。

代码应该有注释，但太多的注释可能和太少一样糟。下面是不应出现在源码注释中的一些内容：文件中的代码导出的函数的列表，修订历史，该文件使用的其他文件的列表，文件名。文档和代码是同一底层模型的不同视图，对待文档要像对待代码一样用心。

额外的一英里。给用户的东西要比他们期望的多一点，给系统增加某种面向用户的特性所需的一点额外努力将一次又一次在商誉上带来回报。随着项目的进展，听取你的用户的意见，了解什么特性会使他们真的高兴。你可以相对容易地增加、并让一般用户觉得很好地特性包括：气球式帮助或工具提示帮助，快捷键，作为用户手册的补充材料的快速参考指南，彩色化，日志文件分析器，自动化安装，用于检查系统完整性的工具，运行系统的多个版本、以进行培训的能力，为他们的机构定制的splash屏幕（交互式软件显示的初始画面）。只是要记住不要因为增加这些新特性而破坏系统。

在你的作品上签名。过去时代的手艺人为能在他们的作品上签名而自豪，你也应该如此。“这是我编写的，我对自己的工作负责。”你的签名应该被视为质量的保证。

好的程序员总是在学习。有两个世界级的程序员专业协会：Association for Computing Machinery(ACM) 和 IEEE Computer Society 。我们建议所有的程序员都加入其中一个，或是两个都加入。成为专业协会的成员有许多好处。讨论会和本地的会议能让你有大量机会接触兴趣相投的人，而特别的兴趣团体和技术委员会能给予你机会、参与制订全世界使用的标准和指导方针。你还将从他们的出版物中学到许多知识，从高级的行业实践讨论直到低级的计算理论。

一个注重实效的程序员。