码农必备技能：烂代码的处理之道

“曾经有一份烂代码摆在我的面前， 我没有珍惜， 我没有把她变的更好， 相反我把她变的更烂！”

现在你的领导又交代给你个新功能，要求三天完成。

你一看代码就发现， 这活真不是人干的， 它经过n多人n多年的维护， 现在已经腐化的臭不可闻了。

这其中有很多人的贡献 ，包括"ijk码农", 也有"汉语拼音码农" , 还有一些”Copy&Paste 码农“，

代码已经看不懂了， 注释基本就是摆设。 

是否似曾相识？



(当然这个代码是为了搞笑， 实际上它是第21届国际C语言混乱代码大赛获奖作品 )

现在你有两种选择：

一、迫于进度压力， 随便改改， 烂就让它烂吧

“反正功能实现就行，烂代码也不是我的责任， 我得早点回去，　女朋友等我吃饭呢” :-)

二、我是个有“洁癖”的程序员，实在受不了这烂代码， 挽起袖子把它清理了，加班加点也在所不惜。

我相信绝大多数程序员都会选一， 人性是懒惰的。

但有那么“一撮”有追求的码农选了二， 于是几年之后， 这一撮码农升级了，优秀了， 与众不同了。

只有勇气和态度是不行的， 本文就讲一讲选择二的的码农用什么样的武器来清理这些烂代码。

1. 先做基本清理

前面提到的"ijk码农"， 就是变量的命名不考虑含义， 都是用一些英文字母 i, j, k ， 在一些for 循环中用用也就罢了, 如果到处使用是要让人崩溃的， 别说别人看不懂， 自己过段时间估计也不知道什么意思了。

还有"汉语拼音码农"， 就是用汉语拼音及首字母来组成变量， 如果没有注释， 简直如同天书一样。 你能想到KFC是开封菜吗， fujian 是福建还是附件？ hn 是河南还是湖南？ hanzi 汉字还是汉子？

更多的是”Copy&Paste码农”就不用说了， 你懂的。

作为最基本的素养，给你的变量，函数， 类起个好名字实在是太重要了，不知道你有没有听说过“代码就是文档“的说法，良好的代码结构， 良好的命名让你的代码自解释， 根本不用写大量的注释就能让别人看懂， 我们每个码农都要努力向这个方向迈进。

古人作诗要推敲， 变量的命名也是这样， 我在写程序的时候对命名极为慎重，反复推敲， 时刻考虑着要让别人一看就懂， 还要让几个月以后，甚至几年以后的自己也能看懂。

这个能力是需要锤炼的， 你不妨从工作中开始， 在写代码中严格要求， 对每个变量、方法都尽自己最大可能让他们变的可读。

其实好的命名对英语水平是有一定要求， 这可能是很多程序员不愿意浪费脑细胞去好好起名的原因， 但是考虑到未来的好处， 还是多花点精力去思考吧。

先把ijk清掉， 这比较简单， 汉语拼音？ 实在想不到对应的英语就查查字典吧， 顺便说下， 有道词典不错啊。

Copy&Paste 更简单，函数封装即可。

测试！ 注意测试！ 用函数封装重复代码其实已经伤及了逻辑， 有良好素养的码农肯定会用测试，甚至是自动化测试来保证正确性的， 这个话题我们以后展开来讲。

把命名弄好了， 你还要把变量放到合适的位置去， 很多人习惯于在函数的开始声明一大堆变量， 后续的代码中使用， 其实这样做会影响到可读性， 因为一般人都不会读开头的一大堆变量， 当变量第一次真正被后面的代码中使用的时候， 还得回过头去看看在哪儿声明的， 怎么初始化的， 这样上下的反复看， 其实很烦人。

所以如果不是语言的限制 ， 最好把变量声明放在在第一次用到的地方， 一目了然。

2. 封装成函数

搞好了这些你可能发现代码还是乱糟糟的， 读起来很吃力， 这和我们码农的脑子容量有关， 就像内存一样 ， 码农不可能一下子记住太多东西， 如果你写的函数中逻辑太多， 脑子没办法一下子记住的话，其实就是在提醒你要进行逻辑拆分了， 得把巨型函数拆成一个个小函数（再次提醒，函数的命名！)， 现在很多IDE 都支持抽取函数的功能， 并且这种重构非常安全， 不要浪费这么好的东西。



点一根烟，休息一下，审视一下现在的代码， 是不是好多了？

你能做到这一步， 编程素养终于入门了！

3. 封装成类

但是我们不会就此停步， 你再看看代码，发现这么多小函数的调用其实是很凌乱的， 尤其是一些参数在函数之间传来传去， 看起来很扎眼。

这是另外一种暗示： 你应该抽取出类了 ！

作为码农的你肯定知道什么是封装，是时候派上用场了， 把你的小函数及其相关的状态封装成类 ， 这将是一步巨大的跨越。

别忘了测试啊！



4. 屠龙刀：发现变化，并且封装变化

好，现在你看到曾经凌乱的领地， 秩序已经慢慢出现了， 各个类之间尽可能的隐藏自己的状态， 只通过方法来进行交互。

如果你的编程素养更高的话， 也许你能嗅到另外一种代码的坏味道： 类的职责划分不清--一个类搅进去了太多的职责， 读代码时脑子需要对很多职责进行不停转换，浪费脑细胞。

我一直认为
把不同的责任放到不同的类中去是非常重要的一件事情，更是程序员经常要修炼的基本素养， 但我观察发现， 很多程序员只会停留在把代码封装成类这一步， 而不会划分职责。

可能有人要问了，职责到底是啥？ Robert Martin （就是《敏捷软件开发，原则，模式，实践》的作者）有个精辟的描述： 职责就是引起变化的原因。

如果有多于一个的原因都可能引起类的变化，就违反了单一职责原则， 最好把职责划分开。

例如一个上传图片的类，调用httpclient来上传图片， 但是上传过程和上传成功都会更新界面， 此时就有两个变化的原因了， 一个是通过网络上传图片， 另一个是界面， 任何一个的变化都会引起这个类的变化， 好的设计需要拆分开。

这时候你的脑子里时刻要牢记一个原则： 发现变化并且封装变化， 拿着这柄屠龙刀对你的类进行毫不留情的重构吧。

5. 倚天剑：对接口编程而不要对实现编程

如果说屠龙刀让你大砍大杀，酣畅淋漓的话， 倚天剑的使用更加考验你的编程智慧， 因为它的使用更加精细微妙， 它考验的就是你的抽象能力。

你怎么样才能把一些相似的职责再抽象一下，形成更高层次的接口让别人调用， 进而隐藏自己的具体实现呢？

例如有两个类，一个类是把内容输出到打印机， 另外一个类把同样的内容输出到屏幕， 是不是可以抽象出一个print() 接口？

答案是: “不一定”， 得看你具体的业务，具体的代码。

我相信做接口抽象没有通用的方案，但是前辈们的总结已经给我们指明了方向和目标， 那就是“设计模式”。

只要你对职责的抽象向着设计模式的方向挺进， 基本上是不会跑偏的。

这里不会再展开讲设计模式，我记得我的IBM经理说过：”10年前我们面试的时候，还会问懂不懂设计模式， 现在不会问了， 因为懂得设计模式已经是必备的技能“ 请各位程序员再仔细的品味一下《设计模式》这本书，我承认它举的例子比较古老，读起来也非常费劲， 但它里边散发出的思想是永恒的。

从具体到抽象是你能力的更大跨越， 很多程序员迈不过这一步，或者说他自以为迈过去了，实际上却没有， 因为不恰当的抽象、或者过度的抽象反而是一种危害。 我现在也不敢说掌握了这个技能， 只能说继续学习，继续进步。



6. 无招胜有招

好了，上面的都是废话，你现在可以统统忘了，:-) 但是要记住下面讲的终极武器：无招胜有招。

仔细想一下为什么我们编程序这么费劲呢？

说白了就是复杂的需求和“愚蠢”的编程语言之间有极大的隔阂，所以需要我们程序员的大脑来填补。

别看现在有各种各样的编程语言出现， 每个语言都吹得天花乱坠，但其实还都是”很低级的“ ，到目前为止，我们依然没有办法以自然语言的方式来编程序， 程序员为了把现实的业务映射到计算机实现， 需要累死无数脑细胞。

由于人脑同一时刻不能处理太多东西， 当我们面对太多的变量因素时，只能处理其中有限的几个， 这就逼着我们使用”发现变化，并且封装变化“， ”对接口编程而不是对实现编程“ 这样的武器， 把细节隐藏，把变化隔离。

其实这两样武器的终极目的就是为了达到程序的”正交性“。

“正交”在数学上讲的是线性无关， 是说一个维度的变化不影响另外一个维度， 你想象一下我们常用的二维坐标系(x, y) , x轴的变化不会影响到y轴的值， 反之亦然， 这就是正交性的体现。

但正交性的威力远远不止于此， 对于(x,y) 能表达二维空间中的所有的点， 如果我们再增加一个新的和x,y正交的维度z 轴， 那一下子就能表示三维空间中的所有的点了！

软件编程也是如此，无论你使用何种方法， 就是让程序形成互不影响、可以独立变化的多个维度， 这样的程序不仅优雅漂亮，更是容易理解，容易维护。

我想“正交性”应该是我们编程时追求的终极目标， 你可以忘掉其他招式，无往而不胜。

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

加入QQ群：135769418　 工作15年的的IBM架构师和你分享职场经验和教训，带着你做项目实战， 可是真的项目需求哦，涉及大量Android,iOS,
Web开发的技术， 同学们做完后参加工作，技术上就不用愁了。

扫描二维码，
关注"coderising"，
更多精彩文章