靠谱的程序员都是相似的
<<The Pragmatic Programmer>>中文版的书名被译作《程序员修炼之道》，这倒和原书的副标题“From Journeyman to Master”有些贴切，按照书中的指点修炼，不说变为大师，成为一个“靠谱”的程序员应该问题不大。
<<The Pragmatic Programmer>>出版于1999年，距今已有接近10年，可惜自己最近才完整看了一遍。读之前觉得认为可能会比较虚，会和不少讲软件工程和管理的书类似，讲一些大而空的问题，一些看起来绝对正确而又没什么用的废话。没想到读了开头就再也放不下了，觉得作者真是“太有才了”，随便摘录几条（有些是自己的体会）：
1、DRY
Don't Repeat Yourself 同样的信息应该只在一处出现，不然会给以后的维护带来无穷无尽的烦恼。
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”。“多数开发人员憎恨测试。他们倾向于小心翼翼地测试，知道代码哪儿会出问题，就下意识避开” 很多问题，只要稍微用心去测，就会测出来，而不至于到用户那儿再暴露出来。这一点也是我们需要加强的，建立测试的环境和机制，让问题尽早暴露出来。
另外还有好多Tips，比如“每年学习一门编程语言，每月读一本技术书籍”“功能正交性”“破窗理论”“代码即文档”
学好一门计算机编程语言真的不值得过分骄傲，可悲的是，我们往往一门编程语言也没有学习好就在简历上写着精通XX编程。为什么有的程序员，工作十年了还不开窍，仍然写不出高质量的程序，以至于哀叹程序员是吃青春饭，过了三十岁就不知道何去何从。为什么有的程序员，勤勤恳恳，却事倍功半，写出来的程序仍然七疮八孔，bug众多？
想了解更多吗？ 那就去读这本书吧 :) ~~
<<The Pragmatic Programmer>>出版于1999年，距今已有接近10年，可惜自己最近才完整看了一遍。读之前觉得认为可能会比较虚，会和不少讲软件工程和管理的书类似，讲一些大而空的问题，一些看起来绝对正确而又没什么用的废话。没想到读了开头就再也放不下了，觉得作者真是“太有才了”，随便摘录几条（有些是自己的体会）：
1、DRY
Don't Repeat Yourself 同样的信息应该只在一处出现，不然会给以后的维护带来无穷无尽的烦恼。
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”。“多数开发人员憎恨测试。他们倾向于小心翼翼地测试，知道代码哪儿会出问题，就下意识避开” 很多问题，只要稍微用心去测，就会测出来，而不至于到用户那儿再暴露出来。这一点也是我们需要加强的，建立测试的环境和机制，让问题尽早暴露出来。
另外还有好多Tips，比如“每年学习一门编程语言，每月读一本技术书籍”“功能正交性”“破窗理论”“代码即文档”
学好一门计算机编程语言真的不值得过分骄傲，可悲的是，我们往往一门编程语言也没有学习好就在简历上写着精通XX编程。为什么有的程序员，工作十年了还不开窍，仍然写不出高质量的程序，以至于哀叹程序员是吃青春饭，过了三十岁就不知道何去何从。为什么有的程序员，勤勤恳恳，却事倍功半，写出来的程序仍然七疮八孔，bug众多？
想了解更多吗？ 那就去读这本书吧 :) ~~
有关键情节透露
