提问对于低质量高复杂度业务代码逻辑的一根筋治理

问题前置描述

为了便于表述，函数名字用日常生活举例子。问题都是真实的问题

class 每日生活 {
  public Object 吃早饭 {
  	检查有没有起床();
    if (爸妈在家() && 早饭已经做好()) {
      真正的吃早饭(); // 封装了一堆选叉子还是筷子，端碗还是拿杯子的细节
    } else {
      做饭结果 结果 = 自己做早饭();
      if (结果.能吃()) {
        真正的吃早饭();
      }
    }
  }
}

今儿个轮到我做上帝，去操纵某个小人，于是实例化了上面这个 class ，上帝我准备发功指挥小人吃早饭。

然而一开始就炸了，昨晚上小人喝多，睡了沙发。虽然爸妈在家饭也做好了，因为检查起床的逻辑是依赖于床的，没有考虑沙发，吃饭失败。程序在入口就报错了。

折腾一通踩完坑，也修复了一些逻辑以后。这次我学乖了，想先看看代码的逻辑和依赖关系，尝试去理解那些本不应该需要我去理解的问题。

光看“爸妈在家()” 并不知道是需要爸妈同时在家，还是只要有一个人在家即可，作为上帝，我也不大明白“爸妈在家”和“早饭做好”的必然联系（为什么？可能因为我家都是爷爷帮忙叫外卖的...）

之后，花了一大堆时间去理清中间的逻辑，又加入了爷爷奶奶，外公外婆在家，做饭或者叫外卖的各种检查以及实现。

总结一下

函数名字并不能如实的反应内在逻辑，即便增加注释也没啥用，而且注释和代码的同步也是个老大难问题，代码审查的人也不是什么时候都认真看代码。

每个家庭的人口构成，生活习惯的不一样，会导致简单吃早饭这一件事儿的流程和实现也不一样。

过两天这小人结婚了，还得把老婆 /老公一大家子接进来，又是麻烦事儿。

解决办法

理论上书里都有，但是收到人力，财力，时间的限制，我自己不打算完全的去解决问题，我只想做到能够

当问题发生的时候，快速识别问题在哪里
不用完整看完代码，能够知道依赖是什么

在考虑做一套 annotation ，并且抽象出来一套标签，比如

@家庭情况(只支持当事人性别为男，父母同住，父亲不会做饭，母亲会做饭，家里从来不允许叫外卖)

当然标签可以不止一个，标签也不用考虑到所有情况。我可以增加一些标签间的依赖关系，再加一个小 plugin 去编译这些 annotation 生成文档。甚至于到我这里的特殊情况，我可以安排人肉去检查标签和实际业务逻辑之间是否一致，是否反映了当下最新的业务需求。

估计会有人问为啥不用 DDD ，那我就还得再引用上面的“但是收到人力，财力，时间的限制”一遍

我的问题

其实想看看有没有什么现成好用的轮子。。。

zddwj

2022-09-19 19:16:22 +08:00

看了下楼主的需求就是想优雅的在屎山上跳舞，这种事我有经验。（从长远看不推荐这么干，还是得多看系统设计相关的书多思考）
首先就是要熟悉调试工具，断点调试，单步调试是必须的，这些可以帮你快速定位关键代码。
其次定位问题的思路：首先看能不能通过各种 log 分析直接定位出来，不行的话就用 diff 加二分查找的方式一步一步缩小问题范围。

对于你上面的问题需要增加或者修改功能，如果你不想重构，直接定义一个 class 每日生活 2 ，把代码复制过来，再在里面加 if 写业务逻辑，完事出 bug 再用我上面的方法定位关键代码修复。这种具体业务实现代码是没有复用性可言的，强行复用只会增加不必要的耦合，导致原本无关的复杂度叠加

AntiGameZ

2022-09-20 01:29:06 +08:00

@alexsunxl
@Actrace
书看的多了 + 学费交的多了才会无奈
尤其在代码历史复杂，同时贡献代码的人水平参差不齐的情况下
企业，包括咱自己都是逐利的，2 个月内搞不定的事儿就不如不搞。所以在屎山，最佳实践，KPI 面前，我时不时得提醒自己克制

@jones2000
是这个道理，但是这么做代码侵入性较高。大概评估了下不是我一个人在 2-3 个月里能搞定的。所以我就想跳出修改现有代码逻辑的范畴，起码先把实际情况梳理梳理，也是为什么想去打 annontation

@zhazi
是这么个道理，这也是为什么在考虑引入这套玩意儿的时候我还举棋不定。这条路走到底可能就是搞一个领域语言，但是这也是个大坑我在可见的未来 1 年内填不了