看书真的是件很有收获的事，特别是看好书。在看一些有思想的作者的书的时候，你能得到的不仅仅是一些语法api之类的，你能理解到事情的前因后果。除此之外，还会有很多作者自身的一些观点，针对我们实际工作中经常会遇到的问题，大师们的观点是盏明灯，吸收这些观点，往往是比语法更大的收获。也许你见不到大牛，也许你一辈子没法跟他们面对面交谈，也许你的周围全是些不喜欢技术或者在你看来技术过于落后的人，没关系，读书吧，挑本好书，读书的过程本身就是同他们交谈。
想从今天起，以后多收录一些大师们的语录。
“ 要是看到你在模板中写这种代码，很多人会怒不可遏。别理他们——他们都是教条主义的受害者。在模板里写代码没有任何不对，只要别写太多（尤其是别把业务逻辑放进模板）。”
—— David Heinemeier Hansson 评论mvc模式中，v中带有少量逻辑判断
摘自《应用rails进行敏捷Web开发》中文版 第343页
【感想】：看到这句话的时候，我相当有感触，不仅仅是对mvc模式，而是更进一步的“教条主义”。我发觉“教条主义”是件非常普遍的事，哪个领域都存在这种现象，很多很多的工程师死守着教条在做事，好的坏的用一刀切的形式去判断，往往这种人不在少数，还非常地固执。这似乎是个顽疾，起初在遇到这种工程师我还试图想去跟他们解释，但发现这种解释要花相当大的精力才有可能成功。
教条主义其实是观点片面造成的结果，一方面可能是实战经验不够，另一方面可能是对“教条”的起因不明，或者干脆是人云亦云缺乏自己思考造成的结果。比如说在早期的重构中，很多人就坚持不用table，非要使用div来模拟table，这就是非常典型的教条主义。虽然table的问题现在已经广泛解决了，绝大多数工程师都有了可以合理使用table的意识了，但教条主义仍然没有就此结束。很典型的就是“页面是否一定要通过w3c验证”，我一直觉得w3c的验证不过是促进web标准化推进的手段，它本身不是目的。web标准的目的是1）让标签语义化; 2）结构、样式和行为分离。这是表象，更进一步，为什么要让标签语义化啊？因为标签语义化有助于seo，有助于特殊终端在无css支持的情况下仍然让网页有很好的可读性。为什么要让结构、样式和行为分离啊？因为分离结构样式和行为有助于提高代码的可维护性。制定web标准的验证，不过是对我们的重构代码进行一次评估，提供一个标准的模板供你去匹配，它是种一刀切式的判断。一定要完全通过w3c验证才算是好的页面吗？这个叫本末倒置。我们的目的是seo、去样式可读还有代码的高可维护性。只要实现这个目标，是否通过验证其实并不重要。死守“通过w3c验证”其实就非常的“教条主义”了。
另外，还有mvc，css sprite，oo编程等等等等，很多方面都需要根据具体情况来决定怎么做，比如说我个人就觉得小型网站使用css sprite非常不值得，可维护性下降了许多，开发成本提高了很多，换来的好处却非常有限，你本身流量就不大，减少http请求数有什么价值？不是说流行的就一定是好东西，一定要知道这东西为什么流行，它能解决什么问题，然后权衡一下得失再做决定是否使用。
“要是看到你在模板中写这种代码，很多人会怒不可遏”，这的确是教条主义者们的典型写照，教条主义者们通过靠“坚持死守某个教条”来证明自己“很专业”，这其实是非常苍白的自我保护，很没劲，自己开发会很辛苦，和你一起配合的其它工程师也会非常辛苦。
“别理他们——他们都是教条主义的受害者”。是的，别理他们，他们是受害者，我们没必要跟他们大费周章地解释为什么我要这么做，为什么我没有完全遵照教条，只要认为你自己的处理非常合理，你完全可以不受他们的思想所左右，死守教条的他们才是受害者，他们会为死守教条而付出“额外的开发成本”，“可维护性下降”或者别的代价。这些代价是真的，教条救不了他们。当然，如果你非常不幸地和教条主义者共事，那么你不得不向它们解释你的视角，我知道这个过程是非常艰难的，但没办法，和人打交道的确比和代码打交道困难得多。