程序员的十个习惯（读书笔记）
要专业而不是自我，凡事对事不对人。一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题，而不是勾心斗角，误入歧途。我们每个人都能有一些极好的创新想法，同样也会萌生一些很愚蠢的想法。在团队中，一个人只是智商高是没有用的，如果他还很顽固并且拒绝合作，那就更糟糕。在这样的团队中，生产率和创新都会频临灭亡的边缘。可能我们的建议不被采纳，或者被全盘否定，因为害怕这些而不去勇于表达自己的想法就不会有人知道你是怎么想的，当你总是保持沉默，最后连你也没有思路了。你就成了一个专门走别人的路的只会复制别人想法的人，最后也就失去你自己了。用Les Brown的一句话说就是：“你不需要很出色才能起步，但是你必须起步才能变得很出色。”
“软件技术的变化如此之快，势不可挡，这是它的本性。继续用你熟悉的语言做你的老本行吧，你不可能跟上技术变化的脚步。”赫拉克利特说过：“唯有变化是永恒的。”历史已经证明了这句真理，在当今快速发展的IT时代尤其如此。就以Java为例，你掌握了Java语言及其一系列的最新特性。接着，你要掌握Swing、Servlet、JSP 、Struts、Tapestry、JSF、JDBC、JDO、Hibernate、JMS、EJB、Lucene、Spring……还可以列举很多。如果你使用的是微软的技术，要掌握VB、Visual C++、MFC、COM、ATL、.NET、C#、VB.NET、ASP.NET、ADO.NET、WinForm、Enterprise Service、Biztalk……并且，不要忘记还有UML、Ruby、XML、DOM、SAX、JAXP、JDOM、XSL、Schema、SOAP、Web Service、SOA，同样还可以继续列举下去（我们将会用光所有的缩写字母）。不幸的是，如果只是掌握了工作中需要的技术并不够。那样的工作也许几年之后就不再有了——它会被外包或者会过时，那么你也将会出局。所以迭代和增量式的学习是个不错的选择，每天进步一点点。对于十年甚至二十年后的自己是一笔巨大的财富。也可以参加一些用户组的活动，甚至讲座，技术论坛，阅读等等，这些的最终目的就是让你追踪变化。（注意：你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯）
让设计指导而不是操纵开发。设计是系统开发必不可少的步骤，他能帮助你快速了解到系统的细节问题，并指导子系统和部件的关系，指导你的实现。但是一定要注意的一点：设计满足实现即可，不必过于详细(Design should be only as detailed as needed to)。好设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。你不要被设计（或者设计师）操纵。
提早实现自动化部署。质量保证人员要像测试应用一样测试部署。
度量真实的工作进度。这样你会对整个进度有个很清晰的认识。很清楚的知道做了哪些，还有哪些没有做。
如果代码太杂乱以至于无法阅读，就应该使用注释来说明。不用管为什么要这样编码，只要告诉我们到底是怎么做的就好了。但是并不是说要用注释来包裹代码，注释不能代替优秀的代码。源代码可以被读懂，不是因为其中的注释，而应该是由于它本身优雅而清晰——变量名运用正确、空格使用得当、逻辑分离清晰，以及表达式非常简洁。在《地海巫师》（The Wizard of Earthsea）系列书籍中，知道一件事物的真实名称可以让一个人对它实施完全的控制。通过名称来进行魔法控制，是文学和神话中一种常用的主题，在软件开发中也是如此。
要编写内聚的代码。内聚性用来评估一个组件（包、模块或配件）中成员的功能相关性。内聚程度高，表明各个成员共同完成了一个功能特性或是一组功能特性。内聚程度低的话，表明各个成员提供的功能是互不相干的。假定把所有的衣服都扔到一个抽屉里面。当需要找一双袜子的时候，要翻遍里面所有的衣服——裤子、内衣、T恤等——才能找到。这很麻烦，特别是在赶时间的时候。现在，假定把所有的袜子都放在一个抽屉里面（而且是成双放置的），全部的T恤放在另外一个抽屉中，其他衣服也分门别类。要找到一双袜子，只要打开正确的抽屉就可以了。（这个例子很好的说明了这个问题）。与此类似，如何组织一个组件中的代码，会对开发人员的生产力和全部代码的可维护性产生重要影响。在决定创建一个类的时候，问问自己，这个类的功能是不是与组件中其他某个类的功能类似，而且功能紧密相关。这就是组件级的内聚性。类也要遵循内聚性。如果一个类的方法和属性共同完成了一个功能（或是一系列紧密相关的功能），这个类就是内聚的。
根据契约进行替换。Liskov替换原则[Lis88]告诉我们：任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而且使用者不必知道任何差异。换句话说，某段代码如果使用了基类中的方法，就必须能够使用派生类的对象，并且自己不必进行任何修改。这句话是什么意思呢？就是说：如果你需要其他类的函数，直接继承它们就好了！不要担心你创建的新类会造成破坏，你的调用者可以改变他们的代码。这是他们的问题，而不是你的问题。通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。
处理或是向上传播所有的异常。不要将它们压制不管，就算是临时这样做也不行。在写代码时要估计到会发生的问题。
要寻找深藏不露的程序bug，正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知方法。——Capers Jones的《估算软件成本》[Jon98]
管理层担心进行代码复查所耗费的时间。他们不希望团队停止编码，而去参加长时间的代码复查会议。开发人员对代码复查感到担心，允许别人看他们的代码，会让他们有受威胁的感觉。这影响了他们的自尊心。他们担心在情感上受到打击。
总结：编程应该是艺术的，代码也应该是严谨的。相信真正理会了这些，一定会编出让自己满意也会让别人满意的代码来。一下午的时间来阅读这本来自infoQ的书，很值。