DRY(Don’t Repeat Yourself)是架构设计中经常用到的一句话，这一原则应用非常广泛，在程序设计中同样会用到，不少代码或许不知不觉中违反了这一定义，如《程序员修 炼之道》一书中就有如下一题，重构下面一段代码

 
  
  1. if (state == TEXAS) { 
  2.         rate = TX_RATE; 
  3.         amt = base * TX_RATE; 
  4.         calc = 2 * basis(amt) + extra(amt) * 1.05; 
  5. } else if ((state == OHIO || (state == MAINE)) { 
  6.         rate = ((state == OHIO) ? OH_RATE : ME_RATE); 
  7.         amt = base * rate; 
  8.         calc = 2 * basis(amt) + extra(amt) * 1.05; 
  9.         if (state == OHIO) 
  10.                 points = 2; 
  11. } else { 
  12.         rate = 1; 
  13.         amt = base; 
  14.         calc = 2 * basis(amt) + extra(amt) * 1.05; 
  15. } 
 
  
可能很多人读此代码都有似曾相识之感，不错，我们身边不少程序员就是如此编程的。这段代码就是由于太多Repeat造成罗嗦难懂，结构复杂，维护困 难。大家可能都会迅速想到两点重构方法
 1. amt, calc 可以移出来
 2. 第2个if可以拆分
 
  
但是这样就完美了吗？4个if/else是否让人闻到一股不对劲的气味？这段程序是否还是传统结构化编程思维？if条件中state再增多程序会怎 样？因此虽然是一段很短的代码，但是重构优化实际是无止境的。
 
  
 
  
再谈巧合编程(Don’t Programmer by Coincidence)，在很多项目中其实也很常见，巧合编程就是有问题的代码在开发过程中恰好能运行通过，但是运行在别的环境很容易就出问题，比如下 面的C++代码
 
  
 
 
  
 
  
  1. a = 2; 
  2. b = 3; 
  3. if (a + b != 5) exit(1); 
 
  
什么情况会exit(1)?
 
  
 
   
传统智慧认为，项目一旦进入编码阶段，工作主要就是机械的把设计转换成可执行语句。这种态度是许多程序低效、不可维护的最 大原因。
 ⋯
 我们大多数人都能够几乎自动地驾驶汽车，我们不用明确的命令我们的脚踩刹车，或是命令手动方向盘，我们只是想“减速并右转”。但是，可靠的司机会不断查看 周围的情况，检查潜在的问题，并且让自己在万一发生意外时处在有利的位置上。编码也是这样。
 
  
 
  
   因此开发过程质量问题非常重要, 有经验的程序员懂得如何避开前进过程中的各种雷区。Code review就是在你的驾驶过程中，由另外一名有经验的驾驶员坐在副驾的座位上，帮你纠正各种危险的驾驶习惯，避免在当时或以后踏入各种已知的雷区。
 
  
本文读后感已先前在新浪微博发出，收到过几十条转发及评论。微博的内容或许更有灵感并及时，欢迎关注http://t.sina.com.cn/timyang