第七章 在项目开始之前
第36节 异想天开的需求
-
追求完美： 完美不是在无所需增加的情况下达到的，而是在没有冗余之时实现的。因此，我们应该避免收集过多需求，而是专注于深入挖掘需求，围绕核心功能不断打磨。
-
与用户共同工作： 挖掘需求需要与用户一同工作，以用户的思维方式思考问题。
-
制定需求文档： 强调需求文档的目标驱动本质，配以UML用例图，有助于明确项目需求。
-
保持抽象： 需求制定时应保持一定的抽象，避免过于具体，需求不同于架构和设计，它只是对所需的简要描述。
-
维护词汇表： 通过维护词汇表来澄清术语的含义，避免混淆。
-
内网发布需求文档： 将需求文档发布到内网，使参与人员随时查看和提出意见。
第37节 打破不可能的谜题
-
戈尔迪斯结的启示： 像亚历山大大帝一样，面对看似不可能解决的问题，需要转换思路，找到突破口，不受先人观念的束缚。
-
问题回顾： 在处理问题时，反思是否有更容易的解决方法，是否关注真正的问题，避免被外围技术问题转移注意力。
-
重新诠释需求： 通过重新诠释需求，有时可以让整个问题消失，就像戈尔迪斯结的奇迹。
第38节 准备就绪
-
倾听疑虑： 当反复出现的疑虑时，需要认真倾听并给予足够时间理解，可能会变成更坚实的问题。
-
避免拖延： 对于一些问题，不要轻易做出承诺，及时构建原型并推进，避免有效等待与拖延之间的界限。
第39节 规范陷阱
-
重要性与陷阱： 编写规范是重要的，但要避免不断增加规范项，注重实效，不要过于详细，避免束缚开发者的发挥。
-
开发文档不宜过详： 避免编写过于详细的开发文档，注重简洁，不限制开发者的思考。
第40节 圆圈与箭头
-
超越限制： 圆圈和箭头在设计文档中用于解释，但也可能推翻先前的设定，保留弹性空间。
-
谨慎采用技术： 不盲目采用技术，将其融入开发实践和能力的语境中，实效的程序员对工具和方法学持批判态度。
第八章 注重实效的项目
第41节 实效的团队
-
团队建设： 注重实效的开发者对整体团队有帮助，团队应确保不容忍代码质量问题。
-
煮青蛙策略： 制定检测员角色，检查团队整体进度，保持团队协作。
-
DRY原则： 避免重复工作，指派管理员专门维护重复的资料，确保团队高效运作。
-
正交性： 对于较大的团队，按照项目进行组织划分，而不是按工作职务，保持功能性的划分。
-
自动化： 通过自动化确保一致性和准确性，尝试在团队所做的每件事情都能自动化。
-
知道何时停止： 给团队成员足够的空间和支持，不要过度规定。
第42节 无处不在的自动化
-
文明进步： 自动化在不加思索的完成重要操作方面取得文明的进步。
-
选择适当的自动化工具： 针对不同场景选择适当的自动化工具，如Cron、Makefile、生成代码、CI/CD工具等。
第43节 无情的测试
-
找到自己的Bug： 注重实效的程序员受到找到自己Bug的驱使，早测试、常测试、自动化测试是必要的。
-
测试方向： 测试涵盖单元测试、集成测试、验证和校验、异常测试、性能测试、可用性测试等。
-
测试方法： 包括回归测试、测试数据、GUI系统测试、对测试进行测试、彻底测试等。
-
测试时机： 尽早测试，测试应该是自动完成的，确保在提交代码时测试已全部通过。
第44节 全都是写
-
代码与文档结合： 代码应与文档紧密结合，认真对待注释和文档，它们是不可或缺的。
-
注释格式： 使用特定格式进行注释，根据语言或IDE推荐的注释格式。
-
可执行文档： 利用工具提取注释内容生成文档，如JavaDoc、jazzy等。
第45节 极大的期望
-
项目成功的度量： 项目成功应该基于在多大程度上满足用户期望来衡量，与客户多交流期望，了解他们的需求。
-
制造惊喜： 适当制造惊喜，采用通用技巧提升项目体验，如气球式帮助、快捷键、日志文件分析器等。
第46节 傲慢与偏见
-
不逃避责任： 注重实效的程序员乐于接受挑战，不逃避责任，要在作品上签名，保持公共的代码所有权。
-
与业务知识分享： 乐于分享业务知识，与他人沟通，让代码带有质量保证。
-
遵循原则： 遵循Kent Beck的建议，采用公共的代码所有权，结对编程，避免匿名带来的危险。