把程序员修炼之道读薄

早在2014年的时候我就已经购入 《程序员的修炼之道》 .还是由于慵懒一直没有翻开，最近才把它从书柜里翻出来看完。

老实说这本书相比CodeComplete2来说，还是差那么点味道，但是它依旧是一本好书。本书通篇都在向读者灌输一种 做一个注重实效的程序员 的概念，这句话出现了不下几百次，200页的书这句话都够填10页了Orz。为了阐明作者观点，书中从以下几个方面进行了自我论证：

作者举了 温水煮青蛙 ， 曳光弹 等 去论证注重实效在软件开发中的作用之大。在这过程中 还把如果做好一个程序员等问题 进行了自我解答。更有趣的是，读完这部分我发现全世界的程序员都应该有一个共性 — 沟通能力普遍不足，因为作者甚至在如何沟通这个问题上 进行了大篇幅的 教学 ，如何和程序员沟通，如何和用户沟通，如何和产品经理沟通，如何减少沟通 等等。

如果觉得自己工作过程中 无法流畅的和其他人沟通 不妨多读一读这本书。

DRY

这部分的章节，我认为是本书最精华的部分，作者在很多地方都提了 DRY原则-Don`t Respeat Yourself （不要重复自己），翻译过来 应该就是不要重复造轮子了。关于 DRY原则 推荐一篇反DRY原则的经典文章 – DRY原则的误区 ,作者是一位有着神奇精力的程序员，做程序员做到他这样 估计就算到头了吧？

DRY原则在细微的事情上 并不一定值得推崇，例如我的很多博客分享的小知识点 其实都是重复造轮子，但是我是发现别人造的轮子不够完美的情况下 才会去重复造。虽然可能我的轮子在你那里也转动不起来！

DRY原则在比较普通的事情上 是应该遵守的，举个离大家很近的例子，你在A项目实现了整套更新打包流程工具，难道去到了B项目 你就要重新再实现一套么？但是要遵守DRY原则 对你造轮子的过程中有一定的要求，你不能造一个不可移植 全程硬编码的轮子。一个依附A项目太深的工具，在你移植到B项目的时候 更多的感受是心力交瘁。

自动化

如何注重实效，本书很大篇幅都在给我们灌输如何让项目中的工作更自动化的方法，如何测试自动化，如何review Code自动化，如何文档自动化，如何代码自动化。

关于在项目中尽可能自动化 这点我非常认同。就拿一个移动游戏项目来说，目前我做过的自动化工具就有：

1. 打包自动化
2. 编译自动化
3. 分包自动化
4. 更新自动化
5. 代码自动化

自动化真的可以让工作更少的出错，让各位程序都能更注重代码逻辑上的问题。

诚实

关于程序员的自我诚实，在书中并没有明确的表述（或者是翻译不直接的问题），但是我隐约能感受到作者给我灌输的一个重要概念 那就是程序员自身的诚实，诚实对待每一个BUG 而不是回避，在编码过程中 诚实对待自己感到不愉快的地方，诚实的去重构 而不欺骗自己，诚实的对待偶然性BUG 而不怀抱侥幸心理。这点很重要 回顾我三年的编码生涯，有过很多次 我都在发现代码有问题的时候 祈祷不修改也不会出现问题。罪过罪过。

看完这本书之后，以上就是我能想起作者给我的东西，兴许不同的人看了会有不同的感悟。我一直都不够注重实效（承认自己不够好并不难），一直都存在侥幸心理（虽然不至于看到BUG都不修）。往后 应该引以为戒。

-EOF-