记录｜探究一次嗅到坏代码后封装再封装

第

77

次推文

LZ-Says

大疫当前，安稳在家。

农药之坑，唯有陷入才知晓。

每逢晋级赛，总要被打回原形。

前言

项目经历了一个又一个，代码撸了一遍又一遍，来来回回拷贝旧东西，似乎丝毫提不起兴趣。

想要手持大刀随意砍杀，却发现根基便有问题，扎心不扎心。

与其盲目调整根基，不如从点击积累，江河入海流，终将汇成汪洋大海！

首先简单说明下目前项目中遇到的问题吧：

• 重复性功能较多；
• 需求不明确造成多次返工，大量时间消耗无脑撸码微调中；
• 。。。

可能是项目的特殊性吧。也可能是我整体构思有问题，很直接的为了赶所谓的进度，让项目代码中充斥了不少重复性的东西。

事情的起因源于某次懒得说明缘由，便直接截了部分截图并发到群里，事后才发现这个各种不舒服。

一起先来看一下，之前“封装”：

下面围绕着此事例进行逐步分析，衍化。

开搞

当初封装的原因就是后台突然返回了一种类型，嗯，是挺突然的，突然的都没关注这种类型，显然针对 App 出现了问题。最原始的方案则是在每个地方无脑式 Copy，所谓简单高（搞）效（笑）的代价，则是白白新增了冗余代码，且直接导致后续维护起来很是麻烦。

说实在的，自己看着咋也好说，实际发群里，突然感觉这段代码写的真 low。果断咨询我鸡老大有什么好的优化方案。

鸡老大说的俩句话很有意义，在此分享下：

• 你可以做抽象，而不是抽方法；
• 抽象的东西不是业务，但是是根据业务形态做的。

Long long ago，曾以为自己对于面向对象理解已经达到游刃有余，鸡老大的一番话，让我不得不再次审视自己，直面自己的漏洞。可惜，目前现有的能力只是停留在抽方法 ?，这里就不过多说明了，某天可能幡然醒悟吧。

鸡老大超级喜欢反问，听取了我的思路后直接提示你这个写法还有很大的改进空间，重复代码太多了，怎么改。

在 “仔细” 观察封装后的方法，在每种类型中都要实例化一个 Intent 并且传递对应的 id，方便后续根据 id 查看详情。

知道了下刀子的地方，现在对此方法进行一下小手术：

• 简单粗暴的使用一个 Intent，通过不同的 Type 实例化对应的 Intent 跳转实例。

分分钟改造完成：

美滋滋找鸡老大得瑟去～

鸡老大不紧不慢的来了句：还有很大的改进空间，你再想想。

经过上面一步，成功将 Intent 实例化精简到 Only One。仔细观察，每个 Type 下都对应类似相同的操作：

• 实例化即将跳转的 Intent；
• 传递对应的 id 值

那我为什么不直接定一个私有化的专门处理 Intent 方法呢？不同的 Type 只需要给我对应的参数值即可。说干就干，改造后如下：

可以吧，嗯，我觉得还不错。找鸡老大得瑟去～

鸡老大又说了，你这不行啊，还有很大改进空间，class 发给我，我来。

这咋能让鸡老大亲自动手呢。??? 我来，我来。

鸡老大又说了几点：

• 去掉注释，不明白你写的是啥，难以理解；
• 如果我想单独调用 when case 中某个方法呢？怎么办？
• 不要私自处理 error，对于可能会造成问题的需要 throws 出去；
• 一个方法只做一件事，同样只用到了 id，为什么要传递 bean？后续有新需求可以拓展重写方法呀；
• 首先你要保障别人来读你代码，一眼就知道你这个代码是什么意思。其次，做需求更多的是面向业务去代码，可读性是首要保障，其次才是优雅性。而且你并不是为了性能而去考虑去设计的。

最后，鸡老大给出一条原则 （不喜勿喷，我老大话我奉为经典，谢谢！） ：

安全性 > 可用性 > 可维护性 > 代码简洁 > 性能

针对鸡老大提出继续优化：

• case 中单独提供对应处理方法，可单独使用，方法名鉴名其意；
• 检查代码现有业务逻辑只需要一个 id 便可使用，将参数 Bean 替换为具体参数；
• 提供方法不再处理 error 情况，而是直接 throws，由实际调用方处理；

针对以上调整后代码如下：

End - 思考 ?

从开始以为的最优，到三番五次自认为最优找鸡老大点评，老脸呐。

不得不跪服鸡老大，短短一个代码片段，便能直击痛楚，甚至我这写代码的人都忽略的跳转多场景调用，多次频繁拷贝，甚至后续沾沾自喜封装了一个小方法。

写代码，不仅仅是写代码，如果单纯的为了写代码而写代码，为了完成任务而写代码，写出的代码，真的难以自看，此处是对自己说。

冗余的代码和精简的代码相比；

依靠注释才可磕巴通读代码和单纯通读代码便可知其意；

杂乱无章的代码和良好设计的代码；

。。。

扪心自问，还是想糊弄自己吗？

路漫漫其修远兮！

番外

问个小问题：

• 你有嫌弃过自己的代码吗？
• 怎么处理的？

欢迎各位关注