前言
项目经历了一个又一个，代码撸了一遍又一遍，来来回回拷贝旧东西，似乎丝毫提不起兴趣。
想要手持大刀随意砍杀，却发现根基便有问题，扎心不扎心。
与其盲目调整根基，不如从点击积累，江河入海流，终将汇成汪洋大海！
首先简单说明下目前项目中遇到的问题吧：
- 重复性功能较多；
- 需求不明确造成多次返工，大量时间消耗无脑撸码微调中；
- 。。。
可能是项目的特殊性吧。也可能是我整体构思有问题，很直接的为了赶所谓的进度，让项目代码中充斥了不少重复性的东西。
事情的起因源于某次懒得说明缘由，便直接截了部分截图并发到群里，事后才发现这个各种不舒服。
一起先来看一下，之前“封装”：
下面围绕着此事例进行逐步分析，衍化。
开搞
当初封装的原因就是后台突然返回了一种类型，嗯，是挺突然的，突然的都没关注这种类型，显然针对 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 - 思考 🤔
不得不跪服鸡老大，短短一个代码片段，便能直击痛楚，甚至我这写代码的人都忽略的跳转多场景调用，多次频繁拷贝，甚至后续沾沾自喜封装了一个小方法。
写代码，不仅仅是写代码，如果单纯的为了写代码而写代码，为了完成任务而写代码，写出的代码，真的难以自看，此处是对自己说。
冗余的代码和精简的代码相比；
依靠注释才可磕巴通读代码和单纯通读代码便可知其意；
杂乱无章的代码和良好设计的代码；
。。。
扪心自问，还是想糊弄自己吗？
路漫漫其修远兮！
番外
问个小问题：
- 你有嫌弃过自己的代码吗？
- 怎么处理的？
