如何提高屎山代码的可读性

前言

TreeInfotip这个插件对于屎山代码，和英文不太好的同学来说真的是福音。

下载地址

https://plugins.jetbrains.com/plugin/12994-treeinfotip

试用场景

给大家表演拉一坨

就比如见过这种代码吗？
我怀着无比难受的心情改的这个目录，大家伙多点个赞让我平复下心情哈

能看得懂吗？看不懂就对了，这种代码其实在政府项目，银行等专业词汇过多过长的项目，老项目，开发不规范的公司，非常常见
包括但不限于

1. 中英文命名混用
2. 英文不规范
3. 中文缩写
4. 资源文件无明显标识
5. SQL 文件不清楚具体位置
6. 日志文件位置和 JAR 包输出位置不明确
7. 存在多个版本，使用 “bak” 和 “vX” 标识，但不清楚它们之间的区别和线上使用的版本
8. …评论区可以补充一下大家开发中遇到的场景

为什么重构困难重重

尽管大家都知道重构是最佳的解决方案，但是有成本。

1.开发成本

本来任务就够重了，瞎改这个组长会觉得你不饱和给你更多活

2理解成本

你想说，我改了规范的英文命名，可读性大大提高了，但是组里的老开发会不高兴，命名baoxianorder这么易读，Insurance policy是个什么玩意。

3.人情成本

组内人微言轻，动老项目命名，别人会认为，搞得你自己技术有多牛逼似得(技术规范上升到人身问题)

4.一些具有特色性质的缩写本来就不好翻译

three supports and one assistance三支一扶，szyf不能说差不多吧，反正理解成本不相伯仲。而且翻译过去，包名跟php包名一样层次补齐，项目有可能显得更乱。

5.潜在成本(风险)

一般能屎山的项目，都有它固有的问题，正所谓存在即有他的原因，看着不合理的事情有它的内生逻辑，

个人风险

如果你改出问题了，那么锅算谁的，上面又没要求可甩不出去。还容易引火烧身。

领导风险：

不求有功但求无过，万事稳字当头
系统升级停机维护，互联网公司发生这种行为是不可能的，灰度发布，报错回滚，数据同步。
政府系统这种事情太常见，一个bug好几年不修复，或者好几个月没改好都很正常。没新的报错就行，有问题人工运维盯上，训化用户就行。
时间紧迫紧急修复
那么没法忽略的bug修复完，又不重构完善，不断地贴if上去，只要系统能跑，不懂技术的领导就没有动力去改动他，

6.工作变动导致的短视

对于潜在的风险，暴雷的时候我跳槽或者升上去了，就是继任者的麻烦，
对于这种事情，想办法甩锅出去就行，不然我岂不是前人栽树后人乘凉。

7.惯性成本

破窗效应和从众效应，大家都这么写了我也这么写得了，费心设计自己负责的模块偏安一隅也做不到，别人一动就把依赖关系全破坏了，跟他讲规范，他说客户催得急又不是不能用。

总结

不论现状多么困难，不要降低对于你代码产出的要求。
上面阻力让增加项目可读性从代码角度困难重重，那换条思路，那我从注释和标注解决，这个插件不说是化腐朽为神奇，至少也能解燃眉之急。

解决方案

TreeInfotip插件+Notebook插件

• 没有困难的工作，只有勇敢的打工人

梳理目录结构

TreeInfotip插件可以改图标和添加水印描述，

无字天书 变 有字天书了

见名知意 O(1)时间复杂度
读一遍再加水印O(n)的时间复杂度
不堪入目到勉强可用的巨大胜利，还可以结合另一个插件Notebook使用

梳理代码逻辑

Notebook插件可以为内部的代码做笔记标注

搜索这个插件并安装
右键添加笔记就能使用

最多三级目录

idea右下角竖直排列的Notebook图标点击就能打开全部视图。
点击打开资源文件就能找到笔记标注的位置，对应接口功能等，对于一些代码存放不规范的接口非常有用。

题外话

这样积累，哪怕屎山代码也能够被理出眉目，还能增加自己的不可替代性，同事也会钦佩你担下如此重任，哪怕最后要别离了，可以视情况把天书秘籍(Notebook笔记支持导出)留给继任者。

安全声明

不提倡学习示例的各种不当命名方法，继续往屎山打补丁是不负责任的行为；不提倡有了Notebook就写祖传代码(注释只写本地不传git)，增强代码可读性是每个开发的责任。