程序员子悠 · 好记性不如烂笔头

弱弱地问大家一下，你们遇到过的最烂的代码是什么样子的？

好奇的阿粉在知乎上面搜了一下，果不其然没有令人失望，这个问题被上千万的人浏览过，然后如你所见，二哥也关注了这个问题~

阿粉最近就接手了一个遗留项目，整个项目的代码结构混乱，动不动就是一个大几千行的类文件，一个方法五六百行而且其中还充斥着各种 if-else，让人看着简直头皮发麻。

很多相似的逻辑就是整段的代码复制粘贴，没有任何封装的存在，注释什么的就更不存在了，几个类似的方法在不同的类中还互相的调用来调用去，看上去像是方法的重载，结果啥也不是。更坑人的这个服务存在很严重的性能问题，消息队列堆积严重，系统 FullGC 频繁，导致需要隔三岔五就进行重启，简直不能忍！

看了下代码的 Git 提交历史记录，发现都是一些好几年前都不知道是哪批人写的历史代码，在业内像这种情况的代码往往被称为屎山。

如果说像这样的屎山代码能正常运行并且也不需要迭代的话，那阿粉只会当它不存在，但是理想很丰满，现实却很骨干，需求总是不断变化的，而且历史的代码逻辑渐渐的也不在符合当前的业务，并且性能也远远跟不上，所以没办法只能硬着头皮往屎山上爬。

经过一段时间的艰苦奋斗，在屎山上面摸爬滚打，虽然头破血流好在最后还是杀出了一条血路，将原本乱如一团麻的逻辑，梳理清楚了一点，并且通过引入一系列的设计原则和代码优化将原本的代码进行了重构一下。

这里阿粉在重构的时候主要是利用 OOP 的思想，将业务进行了一层抽象，提供了很多接口，实现接口隔离；并且对于同一个需求的不同实现方式采用策略模式来进行重构，这样可以保证在后续有新的实现方式的时候，可以无缝的接入，不影响旧的逻辑。

同时对于历史代码中有很多地方进行了多次的数据查询，导致内存和网络传输的浪费也进行了优化，避免在前后方法中多次进行数据库的操作，提升系统性能。

通过一系列的重构和优化操作，系统的性能有了大幅度的提升，原本经常出现的消息堆积和 FullGC 都被解决了。

其实我们每一个人基本上都是在不断的接手别人的代码或者写代码让别人接手，在我们每次骂前人写的代码就像垃圾一样的时候也要思考一下自己是不是也会写出这样的代码。很多时候在业务需求紧急或者自身基础不扎实的时候，难免也会写出很多自己都看不下去的代码逻辑。

就像知乎这个问题的首赞回答者说的一样，世界上最简洁易懂的代码，是自己刚写出来的代码。世界上最烂的代码，就是自己一年前写出来的代码。

所以这就要求我们在完成业务需求的同时也要提升我们自身的编码能力，通过学习和实践写出优秀的代码。这其中对于程序员来说最重要的就是要掌握面向对象的编程思想以及设计模式的灵活运用。

通过适当的引入设计模式把代码的框架设计清楚，很多时候当我们的框架搭建完成业务的实现基本上完成 90%了，剩下来的就是一些堆代码的过程。