项目旧代码常见问题

公司一直在强调编程规范，但编程规范只能规避一些程序编写浅层次的问题，至于一些深层次的问题，只能靠人的自觉和开发能力的提升了。
以下都是我以为的在程序设计开发中普遍存在的深层次的问题，这些问题光靠编程规范等文档的指导是无法避免的。
   
    程序中充斥了大量相同或相近的代码。这样做在开发的时候会省时，省力，因为只要copy一下既有代码，就很容易的添加了新的功能项，而且即不用费太多的脑筋，又可以有很多的代码量，用的时间也很短。但是，这样的程序放到维护阶段就可以说是噩梦了，因为同一个功能要修改好几个地方。而且很容易漏改，或者引入新的问题。
    我们现在评估工作量是按照代码量，而不是按照代码的质量。如果盲目的看重代码量，就很容易造成COPY/PASTE泛滥的现象。
  重构理论强调“事不过三，三必重构”，同样的代码如果出现了三次，那么出现四次，五次的几率就很大了。为了长远的方便，现在多做一些优化整理的工作也是值得的。软件出现bug的概率并不是随着软件规模呈线性增长的，而是呈指数级的增长。如果有2处重复，出错概率是2的话，那么3处重复，概率就为4；4处就为8...  重复次数少的话，出现的错误还可以处于可控范围内，如果重复次数到了一定程度，那么软件即使能维护，其成本也是极其高的。
  在出现第二次重复，或者第三次重复的时候进行相应的重构工作是最容易的，而且可以将出错的概率一下从2或4降为1。如果重复次数多了，再重构的话，那所要付出的工作量就不是一般的大了，因为要协调适配各种相近的情况。
  编写程序，一开始不要涉及太多的设计模式，要本着简单快速的原则。在发现有重复情况出现，开始重构的时候再引入合适的设计模式。因为设计模式的本质就是将重复或易变的地方提取出来，便于以后的维护，扩展。出现第二次重复的时候，你才能发现这些地方，所以这时才是应用设计模式的最好时机。
  
   IF/ELSE，SWITCH/CASE 泛滥。使用了面向对象的程序语言，编写出来的并不一定就是面向对象的程序。这一点可以从我们程序中的if/else, switch/case 使用的情况看出来。它们使用的越多（因为没有使用多态），那么程序面向对象的特性就越差。经常可以在程序中看到4，5个if/else组合，switch下十多个case的情况，这些开发时的图一时之轻松，都为以后版本的难以维护埋下了伏笔。（维护人员埋怨以前的开发质量差也不是没有道理的）
  
   程序没有分层规划，不管前台，后台，程序按照功能来划分，就是3个层次，数据持久层，数据控制层，业务逻辑层。前台程序还要在最后添加上显示层。前台的代码经常可以看到在界面程序中直接调用前后台交互命令，数据转换，显示处理，一气呵成。后台据说也是业务逻辑和数据持久化都写在一起。
这样的坏处显而易见的，写不了或者不好写测试代码；加大调试难度；bug在整个程序范围内泛滥。
  大而化小，分而治之。越大越复杂的东西越不好管理，越小越简单的则相反。软件设计要讲究颗粒度，粒度太大太小都不好，最重要的就是掌握好合适的度。在方便性和数量上取一个合适的平衡。一般来说分3层就很合适了，数据持久层，数据控制层，业务逻辑层，每一层各司其职，每一层的功能实现对其他层都是透明的。
  如果采用了分层可以取得以下几点好处：更方便的写出测试代码；调试更方便；BUG禁锢在某一层上，不会向整个系统蔓延；每个界面可以脱离主框架单独运行；可以使用界面纪录工具进行通用功能的自动化系统测试。
   
   类之间的交互，多使用接口，尽量少用继承和具体类。使用接口，进可攻，退可守，完全是随需应变，不会将自身绑定在某种条件下，利于程序的变化，扩展。