程序员修炼之道
第七章
在项目开始之前
启动太快是一个问题，但等的太久可能会更糟。
1.需求之坑
完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的。
- 挖掘需求，而不是搜集需求，与用户一同工作，以像用户一样思考
- 建立需求文档
- 使用用例图
- 规定过度，制作需求文档时一大危险就是太过具体，好的需求文档要保持抽象
- 看远些，抽象比细节活的更长久。所以设计的时候，也要更长远的考虑
- 特性膨胀，需求蔓延，可以参考石头汤与煮青蛙，合适的管理需求
- 维护词汇表，维护数据字典，词汇表真的是很重要，新人很容易被你的专业术语弄懵，想想打开数据库，三四十个不认识的表，你内心有多崩溃。
- 把话说出来，将文档写在web上
2.解开不可能解开的谜题
弗里几亚的国王系出一个没有人能解开的结，据说解开的人将会统治整个亚洲，亚历山大大帝来了，用剑劈开了这个结，只是对需求做了小小的不同的解释
- *度，在盒子外面思考，鼓励我们找出可能不适用的要求，并忽略他们。不要在盒子外面思考，要找到盒子
-
一定有更容易的方法！如果再处理问题的时候，发现非常困难，感觉好像是自己走错了路，你认为这个问题是不能解决的，那么退回一步，问问自己
有更容易的方法吗？
你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
这件事情为什么是一个问题？
是什么使它如此难以解决？
它必须以这种方式完成吗？
它真的必须完成吗？
3.等你准备好
倾听反复出现的疑虑，等你准备好再开始。当你面对一件任务时，如果你反复感觉到疑虑，或是体验到某种勉强，要注意它。
- 是良好的判断，还是拖延？
4.规范陷阱
对于一些事情，做胜于描述
4.圆圈与箭头
不要做形式方法的奴隶
-
形式方法的缺点
大多数形式方法结合图和某些说明问题来捕捉需求
形式方法似乎鼓励专门话
我们喜欢编写有适应能力的动态系统，使用元数据让我们在运行时改变应用的特征 是否使用形式方法，批判的去看待方法学，并从各种方法学中提取出精华，融合成不断进步的工作习惯
第八章
注重实效的项目
1.注重实效的团队
- 不留破窗户，团队作为整体，不应该容忍破窗户
- 煮青蛙，确保可以持续的监视周围环境的变化
- 交流，开发者互相交流才能更加高效，为你的项目取一个名字
- 不要重复你自己，团队指定某个成员担任资料管理员，负责文档和代码仓库，指定多人负责工作的各个方面
- 正交性
- 自动化，自动化生成代码，自动化的测试等
- 知道何时停止绘画，抵抗不断画下去的诱惑
2.无处不在的自动化
- 项目的编译
- 生成代码
- 回归测试
- 构建自动化，以前使用过Jenkins一键部署构建，很方便。Docker也可以学一学
- 自动化管理
- 网站生成，使用内网来进行项目交流
- 批准流程
3.无情的测试
早测试，常测试，自动测试
要通过全部的测试，编码才算完成
- 测试什么？
- 单元测试
- 集成测试
- 验证和校验
- 资源耗尽，错误和恢复
- 性能测试
- 可用性测试
- 怎样测试？
- 回归测试
- 测试数据
- 演练GUI系统
- 对测试进行测试
- 彻底测试
- 何时进行测试？任何产品代码一旦存在，就需要进行测试
- 把网收紧，一旦测试人员找到了某个bug，这应该是测试人员最后一次发现这个bug
4.全部是写
把文档当做整个开发过程的完整组成部分加以接受
-
代码中的注释，注释源码给你了完美的机会，让你把项目中难以描述的，容易忘记的，却又不能记载到别的地方的东西记载下来。但有些东西不应该出现在源码注释中，如：
文件中的代码导出的函数的列表
修订历史
该文件使用的其他文件的列表
文件名 可执行文档
- 技术文档撰写者
- 打印还是编排
- 标记语言
5.极大的期望
温和的超出用户的期望
- 交流期望，主动控制用户对他们能从系统中得到什么应该抱有的期望
- 额外的一英里，要让用户惊讶，而不是惊吓。给他们的东西要比他们期望的多一点