把程序员修炼之道读薄

这是一篇技术书籍读后感

早在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-

发表评论

电子邮件地址不会被公开。 必填项已用*标注