阅读离职程序员遗留下来的垃圾源代码是怎样一种体验？
一个service类两万行代码、一个方法六七百行、if else嵌套如十八层地狱般深厚、方法传参全是JSON，返回都HashMap<String, Object>，单是依赖注入的其他服务类代码就达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插件哦～）；
短期依赖工具迅速提高自己的代码质量，长期持续学习阅读相关技术书籍！
长此以往，你的代码一定是可阅读和可维护的，还有一个更大的好处就是：“你的代码写完了，基本上可以一次性自测通过！”
呃，我最难受的一次是阅读一个苏州离职程序员的代码，他的变量名都是用的拼音+苏州话，太难受了。
写小游戏中小鱼游动，他写的是变量名是“En”，写螃蟹的变量名是“Ha”，写小虾的变量名是“Hu”。因为要有确认流程，流程中一个变量名表示是的，这个变量名他写的叫“sige”。
两万多行代码，基本上所有变量名都是用的拼音版的苏州话，我一个北方人，天天要翻译拼音版的苏州话，真的是太痛苦了。
没办法我就找我的大学女同学问苏州话都是什么意思，这一来二去的问的多了，她就不耐烦，她不耐烦我就得请她吃饭，随着她不耐烦与我请吃饭的频率增加，在我翻译完这些拼音版苏州话的变量名之后，她就成为了我老婆。
有时候程序员也很无奈，比如刚新开发上线的功能可能过两天后就要改版，然后发现要动很多地方，时间也很紧迫，需求就三个字：“明天要”，这种情况下你还考虑什么整洁度、设计模式、代码抽离之类的，能在有限的时间内把业务代码堆完就不错了，这种情况很无奈。等你回头想优化代码时，发现根本没时间而且代码越滚越大，已经无力修改了。
就发两行让大家开开眼吧
boolean flag=！(！(list==null) &&！(list.size()==0 ))
if(！flag){
}
每个人的编码风格和习惯各异。
有的人可以说没有风格，没有习惯。
导致编写出来的代码，可读性很差，可以说毫无可读性。
关键是，他写出来的代码，在多处有使用，还不能动。
动一发而牵全身。
我们是留下来改？还是辞职走人？
无论选择哪种都想骂他。
——————
我的视频全是以通俗易懂的语言+丰富形象的动画，详细地介绍了各种技术，方便读者快速理解和运用。如果你有需要的话，欢迎来观看。
不要存在鄙视
对于看到之前同事留下的代码，请不要抱有鄙视或者抱怨
不要鄙视，是因为以后你的代码也极大可能被后面的同事鄙视，本是同根生相煎何太急。
不要抱怨，接手维护困难的代码本身就是新工作的一部分。
不一样的体验
代码写得不好，可能有这些原因：
- 这个离职程序员在赶工，忙于上线需求，或者快离职了。
- 他本身编码水平较差，这个没办法，硬伤。
- 故意不将代码写好，如果一次性将代码完善得很好，一方面他在领导面前会看上去很没效率，经常一个需求做很久，另外一方面他在领导面前会显得很没事情做，因为代码可维护性高，很少出bug。如果他把代码写垃圾，可以经常修bug,救火，这样看上去就每天很忙。不用怀疑这一点在现实中是否存在，现实中是存在这种工作方式的人的。
不论遗留的代码如何，对于我的体验都是平和的 ，能不改动就不改动，他的代码能运行就行，如果要加功能，也是保持尽量不动，绝不轻易重构，重构的风险和成本是比较难评估的。
源代码垃圾的时候，你肯定会想这个项目怎么变成这样子了！
当你去读的时候，你肯定会有一万个草泥马从头上飘过！有的时候会直接读得你怀疑人生！
接手一个应用程序，是管理研发课题的。一个课题下面可以有若干项任务，每个任务有一个状态status，状态可以是待批，批准，进行中，完成，验收合格等等。一个数据库存储过程非常慢，经常10分钟以上才能得到结果，还经常半道死了。你结果对也行，还经常返回一些任务状态不一致的课题，有bug。里面用了十几个query，没有注释，读了两小时愣是没看懂它要干什么。结果课题经理说，如果一个课题下的所有任务的状态相同，比如都是完成，那么该课题就应该被返回，就是找出所有其全部任务都处于相同状态的课题。我靠，这么简单的事？给他全改了，一个query，group by课题编号，having max(status) = min (status)，运行速度快得飞起，就没有超过一秒钟的时候。老板嘴都笑歪了。我心想，你雇的都是什么程序员呐，这代码写的，好比解皮带，蹲坑，起来，再把皮带系上，如此反复多次，最后没拉便便，放了一个pi，还是蔫儿臭的那种，没法看。糟心大了。