45个好策略
李笑来老师说过：所有学习上的成功，都只靠两件事：策略和坚持，而坚持本身就应该是最重要的策略之一。
一：态度决定一切
1：做事的态度。把矛头对准问题，而不是人。勇于承认，团队应互相帮助，而不是互相指责。
2：欲速则不达。防止快速修复造成的代码沼泽地，要了解代码后重构保持代码整洁。
3：对事不对人。要专业而不是自我，消极的态度会扼杀创新。“你不需要很出色才能起步，但是你必须起步才能变的很出色。”
4：排除万难，奋勇前进。你必须有勇气向前冲锋，做你认为对的事情。
二：学无止境
1：跟踪变化。迭代和增量式的学习、了解最新行情、参加本地用户组活动、参加研讨会议，如饥似渴的阅读。
2：对团队投资。提供或者营造团队的学习氛围，让每个人都觉得自己越来越聪明。
3：懂得丢弃。学习新的东西，丢弃旧的东西。丢弃掉阻止你前进的旧习惯。
4：打破砂锅问到底。要明白问题的根源。（但问到点子上）
5：把握开发节奏。项目开发要有一致和稳定的节奏。
三：交付用户想要的软件
1：让客户决定。业务需要开发者和业务互相配合来开发（记录客户做出的决定）
2：让设计指导而不是操纵开发。设计满足实现即可，不必过于详细。好的设计是一张地图，它也会进化。设计指引你的方向，而不应该标示具体的路线。好的设计是正确的而不是精确的。
3：合理的使用技术。根据需求选择技术。Don’t build what you can download（不要开发你能下载到的东西）
4：保持可以发布。保持已提交的代码可以行动（本地运行测试、检出最新代码、提交代码）
5：提早集成，频繁集成。想规避代码集成这个主要的风险，只有提早集成，持续而有规律的集成。
6：提早实现自动化部署。安装或者部署应该是简单、可靠以及可以重复的，要从第一天起就开始交付。
7：使用演示获得频繁反馈。需求就像是流动着的油墨。如能与客户频繁协商，根据反馈来开发，每个人都将受益。
8：使用短迭代，增量发布。短迭代让人非常专注以及有效率。
9：固定的价格就意味着背叛承诺。基于真实的工作评估。
四：敏捷反馈
1：守护天使。要依赖单元测试。它是优质股，值得投资。
2：先用它再实现它。编码之前先写测试。只有在具体理由的时候才开始编码，这样你可以专注于设计接口，而不会被很多实现的细节干扰。
3：不同环境，就有不同的问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。
4：自动验收测试。客户也可以运行测试。
5：度量真实的进度。清楚项目的真实进度是一项强大的技术，不要用不恰当的度量来欺骗自己或者团队。
6：倾听用户的声音。每一个抱怨背后都隐藏一个事实，找出真相并修复它。
五：敏捷编码
1：代码要清晰的表达意图。代码必须明确说出你的意图，而且富有表达力。编写清晰而不是讨巧的代码。
2：用代码沟通。不要用注释来包裹你的代码。使用细心选择的有意义的命名，用注释描述代码意图和约束，注释不能替代优秀的代码。
3：动态评估取舍。没有最佳解决方案，有价值的东西要得到。
4：增量式编程。它可以精炼并结构化你的代码。
5：保持简单。简单不是丑陋。Less is more。使代码容易理解和使用。
6：编写内聚的代码。让类的功能尽量集中，让组建尽量小。
7：告知，不要询问。将命令与查询分离开来。
8：根据契约进行替换。通过替换遵循接口契约的类，来添加并改进功能与特性。要多使用委托而不是继承。
六：敏捷调试
1：记录问题解决日志。不要在同一处跌倒两次。保留解决方案是解决问题的一部分。
2：警告就是错误。将警告视为错误。
3：对问题各个击破。在大型应用种，在解决问题时，要将问题与周边隔离开。
4：报告所有异常。处理或者向上传播所有异常。
5：提供有用的错误信息。展示尽量多的支持细节，不过别让用户陷入其中。
七：敏捷协作
1：定期安排会面。立会，时间达成共识。
2：架构师必须写代码。“PPT架构师”。
3：实行代码集体所有制。让开发人员轮换完成系统不同领域中不同模块的不同任务。
4：成为指导者。分享自己的知识。
5：允许大家自己想办法。给别人解决问题的机会。指给他们正确的方向，而不是解决方案。
6：准备好后再共享代码。绝不要提交尚未完成的代码。
7：做代码复查。对于提升代码质量和降低错误率来说，代码复查是无价之宝。
8：及时通报进展和问题。