第36节
主要讨论了在项目开始之前的一些准备步骤和流程。作者强调了需求识别的重要性，并提出需求是与用户共同完成的“发现”过程，而不仅仅是收集他们的意见。需求在某种程度上应该保持抽象，因为需求不等同于架构或设计。作者还提到了一个词汇表的维护，这是为了消除歧义，并确保大家对需求有共同的理解。此外，项目的需求文档应该在内网上公开，这样所有的相关人员都可以访问、查阅，提出他们的意见和建议。
第37节
这一节为我们提供了一个新的思考方式，那就是如果面对一个看似无法解决的问题，我们应该转变思路，尝试去找问题的本质，看看能否通过重新定义需求来使这个问题消失。
第38节
鼓励我们在遇到重复问题时，尽快解决，我们可以通过快速构建原型、迭代，并寻求更好的解决方案。
第39节
关于编写规范的问题，作者警告我们不要对开发者设置过度严格的规定。过于详细的规定可能会限制开发者的创新能力。
第40节
提醒我们要对先前设定的限制有所认识，并努力不让自己被陷入细节，陷入微不足道的部分而无法全面观察问题。也不能盲目地运用所有的技术，而是应该根据实际需求来选择最合适的。
第41节
对如何打造一个注重实效的团队做了深入的探讨，一些重要的原则包括：不能容忍代码质量问题，需要保持团队的交流，避免重复的努力，确保任务的正交性，实现工作流的自动化，并给团队成员足够的空间去创新和做决策。
第42节
提倡使用自动化，因为自动化可以保证过程的一致性和重复性，从而提高效率。
第43节
再次强调了早期频繁的自动化测试的重要性，指出三个基本问题：应该测试什么、如何测试、何时测试。
第44节
提醒我们在编写代码的同时，要注意代码和文档的相互结合，使用特定的注释格式，这样可以生成可执行的文档，让其他人理解我们的代码成为可能。
第45节
重申了理解并满足用户期望的重要性，并强调与客户进行深度交流以更好地理解他们的需求和期望的重要性。
第46节 提出了注重实效的程序员应该认真对待职责，应对挑战，并且要愿意为自己的工作成果负责。他还提出了一个思考点，那就是应该考虑建立公共的代码所有权，这样可以让所有人都有责任和动力去维护和改进这些代码。
标签：需求,小工,问题,程序员,修炼,自动化,应该,代码 From： https://www.cnblogs.com/xuan-2004/p/17801298.html