图书规格

【 书 名 】高效程序员的45个习惯：敏捷开发修炼之道

【 作 者 】[美] Venkat Subramaniam　Andy Hunt

【 ISBN 】978-7-115-21553-6

【 出版社 】人民邮电出版社

【出版时间】2010-01

笔记

  难以坚持下去的事情，基本都是因为没有迫切的欲望和激情。没有动机，没有欲望，哪里来的毅力呢？
  当我们决定做一件事情的时候，首先就要多问问自己：为什么要做这件事情？它所带来的好处是什么？如果不做它又会有哪些坏处？
  有了清晰的目的和思路后再去做事，遇到变化时就知道孰轻孰重，该怎么调整计划，同时也不至于被重复和乏味消磨了一时的意气。

  不管路走了多远，错了就要重新返回。——土耳其谚语

  选定了要走的路，就是选定了它通往的目的地。——Harry Emerson Fosdick

  软件项目时常伴有时间压力——压力会迫使你走捷径，只看眼前利益。但是，任何一个有经验的开发者都会告诉你，欲速则不达。

  世上最糟糕的工作就是和一群爱搬弄是非的人共事。他们对解决问题并没有兴趣，相反，他们爱在别人背后议论是非。

  “这不是我的错”，这句话不对。“这都是你的错”，这句话更不对。如果你没有犯过任何错误，就说明你可能没有努力去工作。

  千里之堤，溃于蚁穴，大灾难是逐步演化来的。
  一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。

  所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。
  你必须要理解一块代码是如何工作的，但是不一定需要成为一位专家。只要你能使用它进行有效的工作就足够了，不需要把它当作毕生事业。

  尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。

  只有更好，没有最好。尽管“最佳实践”这个术语到处在用，但实际上不存在“最佳”，只有在某个特定条件下更好的实践。
  在开始寻找最好的解决方案之前，大家对“最好”的含义要先达成共识。在开发者眼中的最好，不一定就是用户认为最好的，反之亦然。 

  你不可能精通每一项技术，没有必要去做这样的尝试。只要你在某些方面成为专家，就能使用同样的方法，很容易地成为新领域的专家。

  设计文档应该尽可能详细，这样，低级的代码工人只要敲入代码就可以了。在高层方面，详细描述对象的关联关系；在低层方面，详细描述对象之间的交互。其中一定要包括方法的实现信息和参数的注释。也不要忘记给出类里面的所有字段。编写代码的时候，无论你发现了什么，绝不能偏离了设计文档。

  度量剩下的工作量。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。

  没有愚蠢的用户。只有愚蠢、自大的开发人员。如果代码问题解决不了，也许可以考虑通过修改文档或者培训来弥补。

  在编译和测试运行中，停下来想一想，并暂时远离代码细节，这是保证不会偏离正确方向的好办法。

  代码几乎总是可以得到进一步精炼，但是到了某个点之后，再做改进就不会带来任何实质性的好处了。这时开发人员就该停下来，去做其他方面的工作了。
  要将目标牢记在心：简单、可读性高的代码。

  绝对不能允许一个看起来无辜的“查询”去修改对象的状态。

  记录问题的时间不能超过在解决问题上花费的时间。要保持轻量级和简单，不必达到对外发布式的质量。

每日立会的好处：

• 让大家尽快投入到一天的工作中来。

• 如果某个开发人员在某一点上有问题，他可以趁此机会将问题公开，并积极寻求帮助。

• 帮助团队带头人或管理层了解哪些领域需要更多的帮助，并重新分配人手。

• 让团队成员知道项目其他部分的进展情况。

• 帮助团队识别是否在某些东西上有重复劳动而耗费了精力，或者是不是某个问题有人已有现成的解决方案。

• 通过促进代码和思路的共享，来提升开发速度。

• 鼓励向前的动力：看到别人报告的进度都在前进，会对彼此形成激励。 
  
  
  

  经常抬头看看四周，而不是只埋头于自己的工作。