项目代码质量的总结

在公司开发系统的过程中，总结了一些关于项目维护性的问题及应对的方法，首先要说的是遇到的的问题，主要表现在四个方面：
(1) 复用率低，整个项目中存在大量这样的代码，当发现一段代码、方法所做的事情在新模块中可以使用的时候，发现现有的代码依赖于一大堆其他的东西，以至于很难将它分开，然后最好的办法就是不去碰这些已有的东西，而是重新写自己的代码，就ctrl+c，然后ctrl+v一下。然后再稍作修改。
(2) 黏度过高。经常发现这样的代码，当需要做一个改动时，既可以保存原始设计意图和原始设计框架进行，也可以采取特例处理的权宜之计。如果第二种的方法比第一种方法容易很多的话，就会采用短视的方法去处理，但是这样处理问题会导致，容易的事情越做越难，因为总是在绕开问题。相反则难的事情越做越容易。
(3) 应变能力差。当需求人员提出新要求时，在原来的框架结构上难以完成，因为往往意味着不仅仅是加入一个新模块，而且会发生加入的新模块会波及其他模块，最后变成几个模块的联动，使得原来很少工作量完成的工作，演变成一两个月才能完成的工作。
(4) 脆弱。对一个地方的修改，往往导致另外一个完全没关系的模块发生错误，而且好多地方的隐秘性超强。
 
要想提高一个系统的可维护性，我想可以从下几个方面着手：
(1) 提高维护开闭原则的意识，说到底为什么维护性差，因为开发人员在编代码的时候就没有对扩展开发，对修改关闭的意识。
        设计模式本质上就在于解决一个开闭原则的问题，二十几种的模式只是花架子，只是为解决本质问题演化而来而已。在设计模式中为达到维护开闭原则的目的，又具体通过其他几个原则进行，维护开闭原则的手段就是依赖倒置原则即依赖于抽象，不依赖于具体实现。开闭原则的规范就是合成复用原则和里氏代换原则。通往开闭原则的道路是迪米特原则和接口隔离原则。个人感觉学习任何知识包括设计模式都是重道多于重技。（题外话：其实我觉得学习一项知识，有三个问题你必须要带入到看书的过程中，即本质，第一原则，知识结构，这样才能够纲举目张抓住不变量，而不必纠结于细节问题）
        在项目代码中有大量的继承，而不是用组合去解决问题。用继承还是用组合除了区分is-a。还是has-a的关系之外，就是看看符不符合里氏代换原则，如果符合那就是is-a的关系，如果不是还是需要慎重考虑一下两个类从语义上来说有没有别的解释。毕竟过度继承导致后面开发的代码会越来越难以维护。另外不能忽略的一点就是不能为了使用设计模式而用，设计模式带来的缺点也是很明显的，会产生大量的细粒度类，代码逻辑看起来不是那么一目了然，所以具体应用的时候，需要权衡考虑。
 
(2) 面向变化设计代码的结构。设计代码的时候，需要尽可能的熟悉业务，才能更好的预测需求的变化。
        就通信知识而言，本质上来说，2、3、4G的差别不是很大，了解随机接入，系统广播，寻呼，移动性管理，小区间同步，无线资源管理的过程步骤作为网优工具的开发人员就足够了，当然如果了解物理层的协议，帧结构，编码解码调制方式等就更好了。个人体会，业务了解的越深，设计考虑的细节就越全面，就越能把握变化。当然，凡事都有两面性，应该注意过度设计的问题，有些变化可能性很小，如果在可能性小的问题上过于纠结就得不偿失了。
 
(3) 重构代码，改进保存原有代码框架。
        因为在设计代码结构的时候不能够也不可能考虑到所有的细节，这时候开发人员就可能采取特例的处理方式来编代码，开发完成后，就应该做重构代码的工作了，项目代码3、4G中出现很多重复代码，很大一部分原因就是重构的节奏落后了。没有把三个版本的代码进行归纳，推理，抽象，提出变化的代码。
        重构除了能让上述的融合原有框架的功能之外，还应该使代码中的“坏味道”尽可能的减少，代码看起来逻辑清晰，不要有现在经常出现的“上帝类”，就是好像这个类是全能的，啥事都能干，导致类的职责不清，代码之间的耦合性过强，牵一发而动全身。
        重构的时候也要时刻保持开闭原则的意识，某种程度上来说，设计模式的原则指明了重构的方向。
        代码开发本来就应该是一个闭环的过程：理解需求，设计，编码，测试，重构。其实大多数事情只有形成闭环，形成一个正反馈系统，才能不断的进行自我否定和前进，而不是只寻求单点单次或者说一锤子买卖式的突破。
 
(4) 单元测试，保证单个方法的正确性。
        单元测试这个工作始终没有很好的开展起来，本质上还是在于大家根本没有单元测试的意识，其实需求理解完之后要做的就是单元测试类的设计了。因为理解完需求，就应该知道参数的输入情况，从而可以设计打桩测试的测试用例。