《程序员修炼之道：从小工到专家》第七第八章读书笔记

第七章 在项目开始之前
第36节 异想天开的需求

1. 追求完美： 完美不是在无所需增加的情况下达到的，而是在没有冗余之时实现的。因此，我们应该避免收集过多需求，而是专注于深入挖掘需求，围绕核心功能不断打磨。

2. 与用户共同工作： 挖掘需求需要与用户一同工作，以用户的思维方式思考问题。

3. 制定需求文档： 强调需求文档的目标驱动本质，配以UML用例图，有助于明确项目需求。

4. 保持抽象： 需求制定时应保持一定的抽象，避免过于具体，需求不同于架构和设计，它只是对所需的简要描述。

5. 维护词汇表： 通过维护词汇表来澄清术语的含义，避免混淆。

6. 内网发布需求文档： 将需求文档发布到内网，使参与人员随时查看和提出意见。

第37节 打破不可能的谜题

1. 戈尔迪斯结的启示： 像亚历山大大帝一样，面对看似不可能解决的问题，需要转换思路，找到突破口，不受先人观念的束缚。

2. 问题回顾： 在处理问题时，反思是否有更容易的解决方法，是否关注真正的问题，避免被外围技术问题转移注意力。

3. 重新诠释需求： 通过重新诠释需求，有时可以让整个问题消失，就像戈尔迪斯结的奇迹。

第38节 准备就绪

1. 倾听疑虑： 当反复出现的疑虑时，需要认真倾听并给予足够时间理解，可能会变成更坚实的问题。

2. 避免拖延： 对于一些问题，不要轻易做出承诺，及时构建原型并推进，避免有效等待与拖延之间的界限。

第39节 规范陷阱

1. 重要性与陷阱： 编写规范是重要的，但要避免不断增加规范项，注重实效，不要过于详细，避免束缚开发者的发挥。

2. 开发文档不宜过详： 避免编写过于详细的开发文档，注重简洁，不限制开发者的思考。

第40节 圆圈与箭头

1. 超越限制： 圆圈和箭头在设计文档中用于解释，但也可能推翻先前的设定，保留弹性空间。

2. 谨慎采用技术： 不盲目采用技术，将其融入开发实践和能力的语境中，实效的程序员对工具和方法学持批判态度。

第八章 注重实效的项目
第41节 实效的团队

1. 团队建设： 注重实效的开发者对整体团队有帮助，团队应确保不容忍代码质量问题。

2. 煮青蛙策略： 制定检测员角色，检查团队整体进度，保持团队协作。

3. DRY原则： 避免重复工作，指派管理员专门维护重复的资料，确保团队高效运作。

4. 正交性： 对于较大的团队，按照项目进行组织划分，而不是按工作职务，保持功能性的划分。

5. 自动化： 通过自动化确保一致性和准确性，尝试在团队所做的每件事情都能自动化。

6. 知道何时停止： 给团队成员足够的空间和支持，不要过度规定。

第42节 无处不在的自动化

1. 文明进步： 自动化在不加思索的完成重要操作方面取得文明的进步。

2. 选择适当的自动化工具： 针对不同场景选择适当的自动化工具，如Cron、Makefile、生成代码、CI/CD工具等。

第43节 无情的测试

1. 找到自己的Bug： 注重实效的程序员受到找到自己Bug的驱使，早测试、常测试、自动化测试是必要的。

2. 测试方向： 测试涵盖单元测试、集成测试、验证和校验、异常测试、性能测试、可用性测试等。

3. 测试方法： 包括回归测试、测试数据、GUI系统测试、对测试进行测试、彻底测试等。

4. 测试时机： 尽早测试，测试应该是自动完成的，确保在提交代码时测试已全部通过。

第44节 全都是写

1. 代码与文档结合： 代码应与文档紧密结合，认真对待注释和文档，它们是不可或缺的。

2. 注释格式： 使用特定格式进行注释，根据语言或IDE推荐的注释格式。

3. 可执行文档： 利用工具提取注释内容生成文档，如JavaDoc、jazzy等。

第45节 极大的期望

1. 项目成功的度量： 项目成功应该基于在多大程度上满足用户期望来衡量，与客户多交流期望，了解他们的需求。

2. 制造惊喜： 适当制造惊喜，采用通用技巧提升项目体验，如气球式帮助、快捷键、日志文件分析器等。

第46节 傲慢与偏见

1. 不逃避责任： 注重实效的程序员乐于接受挑战，不逃避责任，要在作品上签名，保持公共的代码所有权。

2. 与业务知识分享： 乐于分享业务知识，与他人沟通，让代码带有质量保证。

3. 遵循原则： 遵循Kent Beck的建议，采用公共的代码所有权，结对编程，避免匿名带来的危险。