关于项目中的代码质量和代码重构

年底了，对于这一年来一次自己的年终总结，记录下这一年的编码情况。

“这一年除了编写自己的业务开发代码外，也参与了部分其他既有代码的业务变动，感触良多，主要还是在编码的质量方面有待提高，下面就遇到的这些事情做了一个编码方面的总结：

一、什么样的代码是坏代码？

       我们在讨论设计模式、数据结构和算法、架构设计的时候往往忽略了软件编码的重要性。在现在部分年轻人面前这部分功能变得没那么重要，认为只要熟悉得了几个java的软件框架，懂得spring，聊得上虚拟机，工作嘛编码没那么重要，跑得起来运行不报错通过了测试就行。重在效率快速开发。

      其实不然，如果代码只是一次性编码，后期不需要维护和需求变更，上面这样做确实没关系也不会有什么问题，但我们做的是软件工程，它是具有系统性的，编码是其中的一环和后期的需求变更等都是紧密相扣的，可能你今天写下的代码只花了一下午的时间，但后期的变更由其他的同事改动时光看你的代码和理解业务都要花上一天的时间，这部分时间的损耗也要算在整个系统之中。

所以前期的代码不能一味的只图快速，更加要注重设计和编码的质量。

下面我再来说说这年项目中遇到的坏代码有哪些特征：

1、神秘命名

2、需要写上注释才能明白的方法名

3、主线（主要业务代码）意图混乱

4、废弃代码不删除

二、坏代码样例

神秘命名：这样的名字往往有一个特征就是用的拼音的首字母简写，这样的命名只有他看得明白，如果过一段时间他自己都会不明白表达的是什么意思。

如：ZONGBIAN、BUMENBIAN、ZHIBUBIAN

这让后期的维护人员费尽了心思，最终结合上下文一个个的了解了他的意思，这样的代码可阅读性几乎没有，维护成本也贼高。

需要写上注释才能明白的方法名：这样的方法往往过长而且里头包含了多种功能如删除后发送邮件记录日志方法，这种方法的重用性很差，颗粒度很高，阅读性相对差，如果是这样的代码我们尽可能的分解为细颗粒度的方法，拆分为3个。

主线混乱：这点也是非常重要的，我们的开发人员往往在编写一个重要的业务片段的时候不分重点，一概的写到了一个方法里面，这样对于计算机来说是没所谓的，但对于开发人员来讲会让你代码的阅读性变低，看了一大段代码之后自己还得去总结你这段代码的"中心思想"，这就太浪费时间了。

我们写代码的时候要尽量注重自己的业务主线，最好是能一目了然这个片段在做什么。

举一个例子：

当你向其他人介绍一道菜酸菜鱼做法的时候你会去把鱼是怎么来的详细介绍一下吗？

答案是：不会。 因为这不重要重要的是这个过程这个做法，鱼是怎么来的，哪个菜市场买来的，还是钓来的，根本不是主线里面的内容。

这点放在代码里面也是String  fish = getFish();  你把鱼的得到过程封装起来就行了。不需要把fish的赋值过程写在主线里面，这样就不会让每个人都要去读这么一次fish是怎么来的了。至于有兴趣的可以去看getFish()这个方法就行了，而我们开发有时候往往长篇大论写一大堆就是说几个事情，

看了他的代码脑子里面早已成了浆糊。

废弃代码：

当你尝试阅读代码、理解软件的运作原理时，无用代码确实会带来很多额外的思维负担。

一旦代码不再被使用，我们就该立马删除它。有可能以后又会需要这段代码，但我从不担心这种情况；就算真的发生，我也可以从版本控制系统里再次将它翻找出来。如果我真的觉得日后它极有可能再度启用，那还是要删掉它，只不过可以在代码里留一段注释，提一下这段代码的存在，以及它被移除的那个提交版本号 —— 但老实讲，我已经记不得我上次撰写这样的注释是什么时候了，当然也未曾因为不写而感到过遗憾。在以前，业界对于死代码的处理态度多是注释掉它。在版本控制系统还未普及、用起来又不太方便的年代，这样做有其道理；但现在版本控制系统已经相当普及。如今哪怕是一个极小的代码库我都会把它放进版本控制，这些无用代码理应可以放心清理了。

总结：这一年来重构了这样的代码大大小小几十次，如果这部分功能比较重要那我们就需要适当的重构和设计，基本的编码规范和做事负责的态度是我们软件开发工程师的基础，也是软件行业万丈高楼的地基，其重要性不言而喻，良好的编码也是一个应用或者系统最为重要的，忽视他后面的代价是高昂的，这里我想再重申下我们的软件它是一个系统工程，由需求过程，开发维护过程，测试过程组成，而编码不是一锤子买卖，它尤为的重要。

行了今天下午就写到这里，后面有时间再整理一篇关于软件设计的文章，设计比编码更重要了。

软件工程和建筑工程很像，编码的质量可能是个别人员的事情，有时候一个工程里面就它这块的代码写的很烂，就如同一栋楼里面他家乱七八糟一样，但就算他家乱七八糟，其他家庭也不会有影响，但如果整个楼的设计有问题那就不是这么一回事了！