高效程序员的45个习惯笔记

设计充满了妥协(生活本身也是如此)，成功属于意识到这一点的团队。工作中不感情用事是需要克制力的，而你若能展现出成熟大度来，大家一定不会视而不见。这需要有人带头，身体力行，去感染另一部分人。
XML文档就像人类一样——它们在小时候很可爱，并且与它们在一起也很有意思，但是长大之后，就会变得特别让人厌烦。
没有适宜所有状况的最佳解决方案。你必须对手上的问题进行评估，并选出最合适的解决方案。每个设计都是针对特定问题的——只有明确地进行评估和权衡，才能得出更好的解决方案。
过去用过的解决方案对当前的问题可能适用，也可能不适用。不要事先预设结论，先看看现在是什么状况。
应该采用增量式的编程方式。增量式编程可以精炼并结构化你的代码。代码被复杂化、变成一团乱麻的几率减少了。所开发的代码基于即时的反馈，这些反馈来自以小步幅方式编写代码和测试的过程。

编写代码是一个获得反馈的过程，通过代码获得一些内容，然后在通过反馈来调整自己的代码，最后达到平衡——也就是代码满足了需求。
其实应当恰恰相反，开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲。

相比一个过分复杂、拙劣的解决方案，简单的方案通常更难以获得。

评价设计质量的最佳方式之一，就是听从直觉。直觉不是魔术，它是经验和技能的厚积薄发之产物。在查看一个设计时，听从头脑中的声音。如果觉得什么地方不对，那就好好想想，是哪里出了问题。一个好的设计会让人觉得很舒服。

一个人认为简单的东西，可能对另一个人就意味着复杂。
这就是说，从外部看来，“查询”不应该有任何副作用(如果需要的话，开发人员可能想在后台做一些事先的计算或是缓存处理，但是取得对象中X的值，不应该改变Y的值)。
从事任何编程工作，都要考虑事物正常状况下是如何运作的。不过更应该想一想，当出现问题——也就是事情没有按计划进行时，会发生什么。

以前的时候不太注意，没想过这样一句话——未言胜，先言败，在任何时候都需要有一个兜底的措施和展示，否则页面白屏就离你不远了。
- 决定由谁来负责处理异常是设计工作的一部分。
- 不是所有的问题都应该抛出异常。
- 报告的异常应该在代码的上下文中有实际意义。在前述的例子中，抛出一个NullPointerException看起来也许不错，不过这就像抛出一个null对象一样，起不到任何帮助作用。
- 如果代码中会记录运行时调试日志，当捕获或是抛出异常时，都要记录日志信息;这样做对以后的跟踪工作很有帮助。
- 检查异常处理起来很麻烦。没人愿意调用抛出31种不同检查异常的方法。这是设计上的问题:要把它解决掉，而不是随便打个补丁就算了。
- 要传播不能处理的异常。
主力程序员应该试着担任架构师的角色，而且可以从事多种不同的角色。他会负责解决设计上的问题，同时也不会放弃编码的工作。如果开发人员不愿意承担设计的责任，要给他们配备一个有良好设计能力的人。程序员在拒绝设计的同时，也就放弃了思考。
为团队成员在寻求帮助之前陷入某个问题的时间设定一个时限，一个小时应该是不错的选择。

指给他们正确的方向，而不是直接提供解决方案。每个人都能从中学到不少东西。

最后说点题外话吧，这篇文章是我用Markdown写的，或者说现在我大部分的笔记、文档能用Markdown的时候我都会用Markdown来写，但是在我刚开始做前端的时候我完全不知道Markdown是什么东西，也并不想学，因为感觉学习js就已经让我筋疲力尽了。所幸，我坚持了下来，并且现在并不会为学习新的东西而感到害怕，而是对很多新的东西充满好奇，一些新的技术、文档我都会去看，去尝试，可能尽管最后用不到，但是学习各种思维的过程本来也是很好的一件事情。

所以，我可以认为是程序员这个职业改变了我的思维方式，变得比较严谨而充满好奇、渴望求证（因为代码不会撒谎，对就是对，错就是错）。当然上述是优点，缺点就是思维很指，说话也很直，习惯了和同类还有机器打交道会导致沟通的时候直来直去。所谓的“直男”。