《高效程序员的45个习惯-敏捷开发修炼之道》

转自：http://blog.163.com/xychenbaihu@yeah/blog/static/1322296552013023030673/

敏捷精神：一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法

 

一. 态度决定一切
      选定了要走的路，就是选定了通往的目的地。

• 1. 做事：

                     指责不会修复bug, 把矛头对准问题解决的方法，而不是人。一个重大的错误应该被当作是一次学习而不是指责他人的机会。

              团队成员在一起工作，应相互帮助，而不是相互指责。

• 2. 欲速则不达：

                      不要因为时间紧迫给自己找借口，而坠入快速简单的修复之中。在没有真正解理代码之前，不要急于进行bug修复。

              必须要投入时间和精力来了解代码是如何工作的，保证修复后的代码是整洁、敞亮的，修复本身是没有副作用的。

• 3. 对事不对人：

                      每个人都会有好的想法，也会有不对的想法，团队中的每个人都需要自由地表达观点。

              让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。团队leader既要做到不带个人情绪，又要做到不盲目接受所有观点。

• 4.排除万难，奋勇前进：

                     做正确的事，要诚实，要有勇气说出实情。

 

二. 学无止境
      即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。

• 5. 跟踪变化：跟踪技术变化，你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯：
  （1）迭代和增量式学习，每天计划用一段时间来学习新技术，时间不在长，贵在长期坚持
  （2）了解最新行情，优秀技术、业内咨询博客，技术社区的邮件列表都是不错的选择
  （3）参加研讨会议，计算机大付在世界各地举行，有机会就参加，这是向专家学习的很好的机会
  （4）如饥似渴的阅读，技术和非技术的好书，或者是一些专业期刊、杂志，都是不错的选择
• 6. 对团队投资：搭建团队学习平台，建立积极的团队学习分享的氛围，让每个团队成员都觉得自己越来越聪明。（午餐会议）
• 7. 懂得丢弃：“沉舟侧畔千帆过，病树前头万木春”，要果断的丢弃旧的、不再合时宜的技术、习惯，积极地学习新的。
• 8. 打破砂锅问到底：不要满足于别人告诉你的表面现象，要不停问直到你明白问题的根源。
• 9.把握开发的节奏：保持项目迭代的节奏，编码、测试、代码review、集成、发布，尽量保证每个迭代周期是比较固定有规律的。如果知道什么时候开始下一个节拍，跳舞就会更加容易。软件开发亦是同样的道理。

三. 交付用户想要的软件
       没有任何计划在遇敌后还能继续执行。

• 10. 让客户决定：开发者（或项目经理）能做的一个重要决定就是：决定什么不该决定。业务方面的决定，让用户来做。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
• 11.让设计指导而不是操纵开发：设计满足实现即可，不必过于详细。
  （1）好的设计是张地图，它也会进化。它指引开发向正确的方向前进，它不是殖民地，它不应该标识具体的路线。开发者不要被设计操纵。
  （2）好的设计是正确的，但不是精确的。它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。
• 12. 合理地使用技术：不要一味的追求酷炫的新技术，根据需要选择合适的技术。
• 13. 保持可以发布：保持你的项目时刻可以发布。代码check in之前保证：更新到最新代码，所有单元测试通过。
• 14. 提早集成，频繁集成：搭建自动化的持续集成系统，提早集成，频繁集成，持续而有规律地进行集成。决不要做大爆炸式的集成。
• 15. 提早实现自动化部署：一开始就实现自动化部署。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。QA人员要像测试软件本身功能一样测试部署。
• 16. 使用演示获得频繁反馈：开发的时候，要保持应用可见。每隔一周或两周，的邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
• 17. 使用短迭代，增量发布：使用1~4周左右的迭代周期，发布带有最小却可用功能的产品。
• 18. 固定价格就意味着背叛承诺：不要提供固定报价，要基于真实的工作来评估。主团队和客户一起，真正地在当前项目中工作，做具体实际的评估。

四. 敏捷反馈
       一步行动，胜过千万专家的意见。

• 19. 守护天使：编写能产生反馈的代码，单元测试是不错的实践。使用自动化的单元测试，好的单元测试能够让你的代码问题提供及时的警报。可以使用一些成熟的单元测试框架，比如gtest for C/C++, PyUnit for python, Junit for Java, etc。
• 20. 先使用它再实现它：测试驱动开发，编程之前，先写测试
• 21. 不同环境， 就有不同问题：使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。
• 22. 自动验收测试：为核心的业务逻辑创建测试，让你的客户单独验证这些测试，要让他们像一般的测试一样可以自动运行。
• 23. 度量真实的进度：不要用不恰当的度量来来欺骗自己或者团队，要评估那些需要完成的待办事项，可以做成待办事项列表，完成一项移除一项，真实的度量剩下的工作量。
• 24. 倾听用户的声音：每一个抱怨背后都隐藏了一个事实，找出真相，修复真正的问题。没有愚蠢的用户，只有愚蠢、自大的开发人员。

 

五. 敏捷编码
      任何一个笨蛋都能够让事情变得越来越笨重，越来越复杂，越来越极端。需要开才的指点以及许多的勇气，才能让事情向相反的方向发展。

• 25. 代码清晰的表达意图：代码必须明确的说出你的意图，而且必须富有表达力。这样可以让代码更易于被别人阅读和理解。代码不让人迷惑，也就减少了发生潜在错误的可能。一言以蔽之，代码应该意图清晰，表达明确。 要编写清晰的代码而不是讨巧的代码。
• 26.用代码沟通：使用细心选择的、有意义的命名，最好能让代码能够自注释。如果要加注释，必须要加有意义的注释，注释主要是为了描述代码意图和约束：
  （1）目的：为什么需要这个方法？
  （2）前置条件：方法需要什么样的输入，对象必须处于何种状态，才能让这个方法工作？
  （3）后置条件：方法成功执行后，对象现在处于什么状态，有哪些返回值？
  （4）异常：可能会发生什么样的问题？会抛出什么样的异常？
• 27. 动态评估取舍：动态评估权衡，考虑性能、便利性、生产力、成本和发布时间。如果性能表现足够了，就将注意力放在其它因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
• 28. 增量式编程：在很短的编码、构建、测试循环中编写代码。保持代码在比较短的周期内（比如写完一个功能点）是可编译通过的，单元测试通过的，随着代码功能的完善，不断的完善单元测试。切身感受到的好处是，在写了几行代码之后，你会迫不及待地希望进行一次构建、测试循环。在没有得到反馈时，你不想走得太远。
• 29. 保持简单：简单不是简陋，开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。但是，强行让代码变得优雅与过早优化类似，同样会产生恶劣的影响。
• 30. 编写内聚的代码：让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
• 31. 告知，不要询问：查询与命令分开，查询只做查询，不要做修改代码的逻辑，绝对不允许一个看起来无辜的查询去修改对象的状态；命令用来完成某项明确的修改操作。不要抢别的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。
• 32. 根据契约进行替换：针对is-a的关系使用继承，针对has-a或use-a的关系使用聚合（委托）。继承要遵守“子类不应该要求更多，不应该承诺更小”的原则，相对于继承，聚合（委托）更为灵活，适应能力也更强。

六. 敏捷调试
你也许会对木匠那毫无差错的工作印象深户。但我向你保证，事实不是这样的，真正的高手只是知道如何亡羊补牢。

• 33. 记录问题解决日志：不要在同一处跌倒两次。维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似的问题时，就可以很快找到并使用了。
• 34. 警告就是错误：对于一个优秀的开发者来说，是绝不允许自己的代码有警告的。把警告视为错误是一种优秀的习惯。Check-in带有警告的代码，就跟check-in有错误或者没有通过单元测试的代码一样，都是极差的做法。
• 35.对问题各个击破：有解决问题时，要将问题域与其周边隔离开，特别是大型应用中。二分法是不错的实践，通过二分法隔离，不断缩小问题的范围，直到定位问题。
• 36. 报告所有的异常：对于异常，如果能正常捕捉处理的，请尽量处理；如果不能捕捉处理的，请向上传播。发生异常时，请提供足够的提示信息，或者是记录异常相关的日志，这对以后的跟踪工作很有帮助。
• 37. 提供有用的错误信息：提示的错误信息，一定要是对跟踪问题有帮助的。发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。

七. 敏捷协作
       我不仅发挥了自己的全部能力，还将我所仰仗的人的能力发挥到极致。

• 38. 定期安排会而时间：使用站立会议，每天开始工作前，团队成员一起开15分钟左右（最长不要超过30分钟）的站立会议。一方面帮助团队成员熟悉相互之间的工作，另一方面，可以更好的把控项目进度。
• 39. 架构师必须写代码：优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师—-不知道系统的真实情况，是无法开展设计的。
• 40. 实行代码集体所有制：在团队中实行任务轮换制，让每个成员都可以接触到不同部分的代码，要以提升团队整体的知识和专业技能。另外，还可以降低团队成员离开所带来的风险。
• 41. 成为指导者：给予别人指导，也是提升自己的一种方式，并且让其他人亦开始相信你可以帮助他们。分享自己的知识很有趣—-付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整个团队的实力。
• 42. 允许大家自己想办法：给别人解决问题的机会。“授人以鱼，三餐之需；授人以渔，终生之用”，指给他们正确的方向，而不是直接提供解决方案。每个人都能从中学到不少东西。
• 43. 准备好后再共享代码：绝不提交尚未完成的代码。故意check-in编译未通过或者是没有单元测试没有通过的代码，对项目来说，应被视做玩忽职守的犯罪行为。
• 44. 做代码复查：代码复查即我们通过所说的codereview, 对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成果。通常的做法是搭建 codereview系统，有经验的开发者来review开发经验比较少的开发者的代码，提高代码质量的同时，帮助团队成员成长。
• 45.及时通报进展和问题：发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。这样，有情况发生时，就不会让人感到突然。