高效程序员

<p><strong><span style="color: #ff0000; font-size: medium;">态度篇</span></strong></p>
<p><strong>1. 做实事</strong></p>
<p>不要抱怨，发牢骚，指责他人，找出问题所在，想办法解决。对问题和错误，要勇于承担。</p>
<p><strong>2. 欲速则不达</strong></p>
<p>用小聪明、权宜之计解决问题，求快而不顾代码质量，会给项目留下要命的死角。</p>
<p><strong>3. 对事不对人</strong></p>
<p>就事论事，明智、真诚、虚心地讨论问题，提出创新方案。</p>
<p><strong>4. 排除万难，奋勇前进</strong></p>
<p>勇气往往是克服困难的唯一方法。</p>
<p><strong><span style="color: #ff0000; font-size: medium;">学习篇</span></strong></p>
<p><strong>5. 跟踪变化</strong></p>
<p>新技术层出不穷并不可怕。坚持学习新技术，读书，读技术杂志，参加技术活动，与人交流。要多理解新词背后的所以然，把握技术大趋势，将新技术用于产品开发要谨慎。</p>
<p><strong>6. 对团队投资</strong></p>
<p>打造学习型团队，不断提高兄弟们的平均水平。</p>
<p><strong>7. 懂得丢弃</strong></p>
<p>老的套路和技术，该丢，就得丢。不要固步自封。</p>
<p><strong>8. 打破砂锅问到底</strong></p>
<p>不断追问，真正搞懂问题的本质。为什么？应该成为你的口头禅。</p>
<p><strong>9. 把握开发节奏</strong></p>
<p>控制好时间，养成好习惯，不要加班。</p>
<p><strong><span style="color: #ff0000; font-size: medium;">开发流程篇</span></strong></p>
<p><strong>10. 让客户做决定</strong></p>
<p>让用户在现场，倾听他们的声音，对业务最重要的决策应该让他们说了算。</p>
<p><strong>11. 让设计指导而不是操纵开发</strong></p>
<p>设计是前进的地图，它指引的是方向，而不是目的本身。设计的详略程度应该适当。</p>
<p><strong>12. 合理地使用技术</strong></p>
<p>根据需要而不是其他因素选择技术。对各种技术方案进行严格地追问，真诚面对各种问题。</p>
<p><strong>13. 让应用随时都可以发布</strong></p>
<p>通过善用持续集成和版本管理，你应该随时都能够编译、运行甚至部署应用。</p>
<p><strong>14. 提早集成，频繁集成</strong></p>
<p>集成有风险，要尽早尽量多地集成。</p>
<p><strong>15. 提早实现自动化部署</strong></p>
<p><strong>16. 使用演示获得频繁反馈</strong></p>
<p><strong>17. 使用短迭代，增量发布</strong></p>
<p><strong>18. 固定价格就意味着背叛承诺</strong></p>
<p>估算应该基于实际的工作不断变化。</p>
<p><strong><span style="color: #ff0000; font-size: medium;">用户篇</span></strong></p>
<p><strong>19. 守护天使</strong></p>
<p>自动化单元测试是你的守护天使。</p>
<p><strong>20. 先用它再实现它</strong></p>
<p>测试驱动开发其实是一种设计工具。</p>
<p><strong>21. 不同环境，就有不同问题</strong></p>
<p>要重视多平台问题。</p>
<p><strong>22. 自动验收测试</strong></p>
<p><strong>23. 度量真实的进度</strong></p>
<p>在工作量估算上，不要自欺欺人。</p>
<p><strong>24. 倾听用户的声音</strong></p>
<p>每一声抱怨都隐藏着宝贵的真理。</p>
<p><strong><span style="color: #ff0000; font-size: medium;">编程篇</span></strong></p>
<p><strong>25. 代码要清晰地表达意图</strong></p>
<p>代码是给人读的，不要耍小聪明。</p>
<p><strong>26. 用代码沟通</strong></p>
<p>注释的艺术。</p>
<p><strong>27. 动态地进行取舍</strong></p>
<p>记住，没有最佳解决方案。各种目标不可能面面俱到，关注对用户重要的需求。</p>
<p><strong>28. 增量式编程</strong></p>
<p>写一点代码就构建、测试、重构、休息。让代码干净利落。</p>
<p><strong>29. 尽量简单</strong></p>
<p>宁简勿繁。如果没有充足的理由，就不要使用什么模式、原则和特别的技术。</p>
<p><strong>30. 编写内聚的代码</strong></p>
<p>类和组件应该足够小，任务单一。</p>
<p><strong>31. 告知，不要询问</strong></p>
<p>多用消息传递，少用函数调用。</p>
<p><strong>32. 根据契约进行替换</strong></p>
<p>委托往往优于继承。</p>
<p><strong><span style="color: #ff0000; font-size: medium;">调试篇</span></strong></p>
<p><strong>33. 记录问题解决日志</strong></p>
<p>不要在同一地方摔倒两次。错误是最宝贵的财富。</p>
<p><strong>34. 警告就是错误</strong></p>
<p>忽视编译器的警告可能铸成大错。</p>
<p><strong>35. 对问题各个击破</strong></p>
<p>分而治之是计算机科学中最重要的思想之一。但是，要从设计和原型阶段就考虑各部分应该能够很好地分离。</p>
<p><strong>36. 报告所有的异常</strong></p>
<p><strong>37. 提供有用的错误信息</strong></p>
<p>稍微多花一点心思，出错的时候，将给你带来极大便利。</p>
<p><strong><span style="color: #ff0000; font-size: medium;">团队协作篇</span></strong></p>
<p><strong>38. 定期安排会面时间</strong></p>
<p>常开会，开短会。</p>
<p><strong>39. 架构师必须写代码</strong></p>
<p>不写代码的架构师不是好架构师。好的设计都来自实际编程。编程可以带来深入的理解。</p>
<p><strong>40. 实行代码集体所有制</strong></p>
<p>让开发人员在系统不同区域中不同的模块和任务之间轮岗。</p>
<p><strong>41. 成为指导者</strong></p>
<p>教学相长。分享能提高团队的总体能力。</p>
<p><strong>42. 让大家自己想办法</strong></p>
<p>指引方向，而不是直接提供解决方案。让每个人都有机会在干中学习。</p>
<p><strong>43. 准备好后再共享代码</strong></p>
<p>不要提交无法编译或者没有通过单元测试的代码！</p>
<p><strong>44. 做代码复查</strong></p>
<p>复查对提高代码质量、减少错误极为重要。</p>
<p><strong>45. 及时通报进展与问题</strong></p>
<p>主动通报，不要让别人来问你。</p>