> 这是一篇技术书籍读后感 早在2014年的时候我就已经购入[《程序员的修炼之道》](http://www.amazon.cn/%E7%A8%8B%E5%BA%8F%E5%91%98%E4%BF%AE%E7%82%BC%E4%B9%8B%E9%81%93-%E4%BB%8E%E5%B0%8F%E5%B7%A5%E5%88%B0%E4%B8%93%E5%AE%B6-%E4%BA%A8%E7%89%B9/dp/B004GV08CY/ref=sr_1_1?s=books&ie=UTF8&qid=1433867279&sr=1-1&keywords=%E7%A8%8B%E5%BA%8F%E5%91%98%E4%BF%AE%E7%82%BC%E4%B9%8B%E9%81%93).还是由于慵懒一直没有翻开，最近才把它从书柜里翻出来看完。 老实说这本书相比[CodeComplete2](http://shadowkong.com/archives/1921)来说，还是差那么点味道，但是它依旧是一本好书。本书通篇都在向读者灌输一种**做一个注重实效的程序员**的概念，这句话出现了不下几百次，200页的书这句话都够填10页了Orz。为了阐明作者观点，书中从以下几个方面进行了自我论证： > 为何要注重实效 作者举了`温水煮青蛙`，`曳光弹`等 去论证注重实效在软件开发中的作用之大。在这过程中 还把如果做好一个程序员等问题 进行了自我解答。更有趣的是，读完这部分我发现全世界的程序员都应该有一个共性 — 沟通能力普遍不足，因为作者甚至在如何沟通这个问题上 进行了大篇幅的**教学**，如何和程序员沟通，如何和用户沟通，如何和产品经理沟通，如何减少沟通 等等。 如果觉得自己工作过程中 无法流畅的和其他人沟通 不妨多读一读这本书。 > 如何注重实效 **DRY** 这部分的章节，我认为是本书最精华的部分，作者在很多地方都提了**DRY原则-Don`t Respeat Yourself**（不要重复自己），翻译过来 应该就是不要重复造轮子了。关于**DRY原则** 推荐一篇反DRY原则的经典文章 – [DRY原则的误区](http://www.yinwang.org/blog-cn/2015/06/14/dry-principle/),作者是一位有着神奇精力的程序员，做程序员做到他这样 估计就算到头了吧？ DRY原则在细微的事情上 并不一定值得推崇，例如我的很多博客分享的小知识点 其实都是重复造轮子，但是我是发现别人造的轮子不够完美的情况下 才会去重复造。虽然可能我的轮子在你那里也转动不起来！ DRY原则在比较普通的事情上 是应该遵守的，举个离大家很近的例子，你在A项目实现了整套更新打包流程工具，难道去到了B项目 你就要重新再实现一套么？但是要遵守DRY原则 对你造轮子的过程中有一定的要求，你不能造一个不可移植 全程硬编码的轮子。一个依附A项目太深的工具，在你移植到B项目的时候 更多的感受是心力交瘁。 **自动化** 如何注重实效，本书很大篇幅都在给我们灌输如何让项目中的工作更自动化的方法，如何测试自动化，如何review Code自动化，如何文档自动化，如何代码自动化。 关于在项目中尽可能自动化 这点我非常认同。就拿一个移动游戏项目来说，目前我做过的自动化工具就有： 1. 打包自动化 2. 编译自动化 3. 分包自动化 4. 更新自动化 5. 代码自动化 自动化真的可以让工作更少的出错，让各位程序都能更注重代码逻辑上的问题。 **诚实** 关于程序员的自我诚实，在书中并没有明确的表述（或者是翻译不直接的问题），但是我隐约能感受到作者给我灌输的一个重要概念 那就是程序员自身的诚实，诚实对待每一个BUG 而不是回避，在编码过程中 诚实对待自己感到不愉快的地方，诚实的去重构 而不欺骗自己，诚实的对待偶然性BUG 而不怀抱侥幸心理。这点很重要 回顾我三年的编码生涯，有过很多次 我都在发现代码有问题的时候 祈祷不修改也不会出现问题。罪过罪过。 > 编程之道 看完这本书之后，以上就是我能想起作者给我的东西，兴许不同的人看了会有不同的感悟。我一直都不够注重实效（承认自己不够好并不难），一直都存在侥幸心理（虽然不至于看到BUG都不修）。往后 应该引以为戒。 -EOF-