这两天花了点时间把《程序员修炼之道》这本书读了，本来估计要一周时间才能读完，读了才发现作者绝对是人才啊，书写的生动有趣，一口气就读完了。随便摘录一下。
1.做一个靠谱的程序员，纯粹的程序员，脱离了低级趣味的程序员
本书一开篇就提出要做一个靠谱程序员，原文是pragmatic，我觉得翻译成靠谱很靠谱。靠谱的程序员应该有以下几个特点
I.对全局负责，而不是各种找借口推脱。在找借口之前想想别人听了这个借口之后会怎么鄙视你。。。作者认为就算是不可挽回的问题，也不要找借口，而是告诉别人替代的解决方案。
II.防微杜渐，不要放纵小问题。下面郑重的提出一个让我眼前一亮的“破窗理论”：
破窗理论：社会学研究人员发现，导致一栋楼变得废弃的原因不是什么很大的问题，而是始于一扇从未被修复的破窗子。这扇破窗子不断的提醒楼里的人员这栋楼已经废弃了，没搞头了，所以大家都可以随便乱搞了。所以这栋楼就废了。软件开发也是一样，不能容忍有瑕疵的乱写的代码，这会废掉这个工程的。
III.对变化敏感，不要做被煮熟的青蛙。
IV.做恰到好处的软件，知道什么时候停止。作者举了一个很生动的例子。程序员就像画家一样，开始的时候往一块白板上面涂颜料画，先画框架，再画细节，不断的涂涂抹抹之后画作可能已经完成了，但如果作者没有意识到，还在不断的添加颜料，那么结果只能是化蛇添足了，反而毁了这幅作品。
V.重视知识的积累和与人交流。
2、对待bug的态度
有些开发人员，遇到bug，总先要辩解一下，“不可能”“不会吧”“我怎么没发现”“你操作有问题吧”，就是不想承认。有的人则是出了问题先怀疑操作系统、怀疑库函数、怀疑编译器、怀疑硬盘、怀疑网络，就是不怀疑自己写的代码有问题。当然不排除系统可能会有问题，可是这比买彩票中500万的概率还要小，还是先从自己的代码找原因吧。
3、Don't Assume It —-- Prove It
经常遇到这种情况，开发人员遇到了一个bug，查了一下，觉得可能是这个原因，好，马上修改代码，提交，Done！其实有很多时候bug根本没有被修正，首先要做的是重现bug，重现的步骤越简单越好，修改完再用同样的步骤，看bug是否不再出现，否则你怎么知道bug已经被fix了呢。
4、Crash Early Crash, Don't Trash.
尽早暴露问题，而不是搞的一团糟。问题出现的越晚，你要修改的代码就越多，
5、Don't Program by Coincidence
代码为什么正常工作？不知道！反正写了那么多，看起来是工作正常的。很多时候如果我们说不清楚，那是说明自己还没有完全理解这个问题，代码也只是幸运的运行起来了，深层的bug隐藏在里面，只是还没有暴露出来，总有一天会以更具破坏性的方式去爆发，“出来混，总是要还的”。开发人员也常有侥幸心里，有时候自己测试也遇到了问题，可是不好重现，大多数情况下又是正常的，就会想“在客户哪儿应该不会出问题”
6、Ruthless Testing --- 无情测试
“Extreme Programming”也有类似的口号“continuous integration and relentless testing”。“多数开发人员憎恨测试。他们倾向于小心翼翼地测试，知道代码哪儿会出问题，就下意识避开” 很多问题，只要稍微用心去测，就会测出来，而不至于到用户那儿再暴露出来。这一点也是我们需要加强的，建立测试的环境和机制，让问题尽早暴露出来。
这里只是摘录了一小部分有意思的内容，这本书读起来很有意思，如果你感兴趣，那就弄本来读读吧~
by 林萌
扫一扫
6608
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
