在 程序员修炼之道: 从小工到专家 一书中, 作者提出了靠巧合编程的概念. 在
C陷阱与缺陷中, 第8章开头, 有这样一段话值得我们警醒自己:
在面临时间压力的情况下, 对程序组合方式的理解尤为重要. 编程者几乎都有过这样的经历: 在调试程序很长时间之后, 疲惫不堪的程序员开始漫无目的地瞎碰, 这里试一下, 那么改一点, 如果凑巧程序似乎可以运行了, 便万事大吉. 这种工作方式往往最后导致一场灾难.
在工作中观察到的程序员行为, 的确有很多是这样的, 我的经验是这样的:
* 首先, 我学会了代码要check in的概念, 而不是在硬盘上到处复制. 现今, 即使是我在自己电脑上制作的小程序, 或但凡会随着时间推移需要维护的东西, 我都用本地CVS 来管理.
* 其次, 我从工作中的一个前辈(嗨! 老陈)身上学到了check in之前的自我review习惯. 不要匆匆忙忙地提交东西, 每一次提交都是你在为自己的职业名声打睹, 那些有兴趣通过CVS review你的代码的同事, 如果看到你犯下某个低级错误, 他们会暗地里给你打分的, 为什么一个充分准备的人可能会在面试中骗得经理的信任, 但在接下来的几个月里你的程序员同事一定会知道你的真正斤两, 奥秘就在这里.
* 再次, 我发现, 即使是review, 也需要有个时间差, 你刚刚做完的东西, 趁热去review, 往往看不出问题, 因为一个相对短的时间内你的头脑会有思维的定势, 所以只要是下班前临走时做好的东西, 我一定不check in, 也不去review, 第二天早上我再去review, 往往能发现有值得改进的地方, 什么? 当晚硬盘坏了! 嘿, 我运气没那么衰吧.
* 最后, review时的心态. 这个很微秒, 但我觉得一样很重要, Knuth曾对此有过精彩的描述, 大意是让你怀着最卑鄙的恶意在你的敌人的代码里挑刺.
* 题外话, 我自己工作的环境里, 让你人来review 往往都不现实. 这种事情, 开会的时候很个人都会毫无疑问地赞同, 提倡, 但真到需要review的时候就不那么回事了, review很花时间和精力! 没人愿意为你做这种吃力不讨好的事. 所以, 在我有幸成为真正做review的团队的一员时, 唯一能做的, 就是独善其身.
阅读(1100) | 评论(0) | 转发(0) |
