阅读离职程序员遗留下来的垃圾源代码是怎样一种体验

阅读离职程序员遗留下来的垃圾源代码是怎样一种体验？

一个service类两万行代码、一个方法六七百行、if else嵌套如十八层地狱般深厚、方法传参全是JSON，返回都HashMap，单是依赖注入的其他服务类代码就达400行，小200个注入！

接下来让我们一起来体验这个神奇的“垃圾源代码”！

返回参数是HashMap，传参数是JSON，然后反序列化为HashMap对象：

这就是牛逼的“面向过程编程”，你说你维护的时候，你怎么知道他传的啥？根据各种参数条件然后再返回啥？

硬着头皮看代码吧，这时候你发现这个方法3341-2657=684行代码，再来看看他的if else嵌套：

按照sonarLint的方法复杂度计算，这段代码的复杂度是116，这还只是这个方法中的“一小段”代码。要知道sonarLint默认规则是只要这个方法的复杂度超过15就提示需要优化了！

看这个类的Annotate，竟然前前后后有几十人维护过，恨不得一个类搞定所有业务，idea提示器从头到尾都是黄色警告，更不用说集成阿里规约扫描插件甚至solarLint插件来扫描代码了。。。

崩溃么？程序员的崩溃就在这一瞬间～

你说这样的代码让你来维护是怎样的一种体验？

有时候不得不感慨，一个产品的成功与否，与代码质量无关～

那么问题来了，程序员写出一手漂亮可维护的代码真的就这么难？

我觉得写代码本身不难，大多数都是在写业务代码，难得是自己心中没有好代码的标准，有的程序员知道自己写的代码不好，但是不知道怎么写出好的代码，这是问题存在的本因，你同意吗？

这里我给出我个人觉得写出可维护代码的一些方法论：

1、不要用设计模式去实现业务代码，越复杂越不可维护；

2、多看书，读书破万卷，下笔如有神。比如Java的可以看《阿里巴巴Java开发手册》、《重构-改善既有代码的设计》等；

3、去sonarqube官网学习一下sonarqube，他的代码检查rule等；

4、从今天起，在你的idea上装上阿里巴巴Java规约扫描插件，让你写的每一个Java类没有一个警告（还有更严格的sonarLint插件哦～）；

短期依赖工具迅速提高自己的代码质量，长期持续学习阅读相关技术书籍！

长此以往，你的代码一定是可阅读和可维护的，还有一个更大的好处就是：“你的代码写完了，基本上可以一次性自测通过！”