前言
TreeInfotip这个插件对于屎山代码,和英文不太好的同学来说真的是福音。
下载地址
https://plugins.jetbrains.com/plugin/12994-treeinfotip
试用场景
给大家表演拉一坨
就比如见过这种代码吗?
我怀着无比难受的心情改的这个目录,大家伙多点个赞让我平复下心情哈
能看得懂吗?看不懂就对了,这种代码其实在政府项目,银行等专业词汇过多过长的项目,老项目,开发不规范的公司,非常常见
包括但不限于
- 中英文命名混用
- 英文不规范
- 中文缩写
- 资源文件无明显标识
- SQL 文件不清楚具体位置
- 日志文件位置和 JAR 包输出位置不明确
- 存在多个版本,使用 “bak” 和 “vX” 标识,但不清楚它们之间的区别和线上使用的版本
- …评论区可以补充一下大家开发中遇到的场景
为什么重构困难重重
尽管大家都知道重构是最佳的解决方案,但是有成本。
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),增强代码可读性是每个开发的责任。
文章评论