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

Posted HLQ_Struggle

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记录 |探究一次嗅到坏代码后封装再封装相关的知识,希望对你有一定的参考价值。

文章目录

农药之坑,唯有陷入才知晓。每逢晋级赛,总要被打回原形。

前言

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

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

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

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

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

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

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

一起先来看一下,之前“封装”:

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

开搞

当初封装的原因就是后台突然返回了一种类型,嗯,是挺突然的,突然的都没关注这种类型,显然针对 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 - 思考 🤔

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

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

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

冗余的代码和精简的代码相比;
依靠注释才可磕巴通读代码和单纯通读代码便可知其意;
杂乱无章的代码和良好设计的代码;
。。。

扪心自问,还是想糊弄自己吗?

路漫漫其修远兮!

番外

问个小问题:

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

以上是关于记录 |探究一次嗅到坏代码后封装再封装的主要内容,如果未能解决你的问题,请参考以下文章

你了解 RunLoop 线程保活吗?已封装好,2 句代码直接使用

再记录一次delete出错的经历

Struts2表达式封装Action获取不到表单数据的一次记录

#yyds干货盘点 React工作记录二十一ant design封装一个弹框组件

用Java手动封装JDBC连接池

封装继承重载重写多态