问题前置描述
为了便于表述，函数名字用日常生活举例子。问题都是真实的问题
class 每日生活 { public Object 吃早饭 { 检查有没有起床(); if (爸妈在家() && 早饭已经做好()) { 真正的吃早饭(); // 封装了一堆选叉子还是筷子，端碗还是拿杯子的细节 } else { 做饭结果 结果 = 自己做早饭(); if (结果.能吃()) { 真正的吃早饭(); } } } } 今儿个轮到我做上帝，去操纵某个小人，于是实例化了上面这个 class ，上帝我准备发功指挥小人吃早饭。
然而一开始就炸了，昨晚上小人喝多，睡了沙发。虽然爸妈在家饭也做好了，因为检查起床的逻辑是依赖于床的，没有考虑沙发，吃饭失败。程序在入口就报错了。
折腾一通踩完坑，也修复了一些逻辑以后。这次我学乖了，想先看看代码的逻辑和依赖关系，尝试去理解那些本不应该需要我去理解的问题。
光看“爸妈在家()” 并不知道是需要爸妈同时在家，还是只要有一个人在家即可，作为上帝，我也不大明白“爸妈在家”和“早饭做好”的必然联系（为什么？可能因为我家都是爷爷帮忙叫外卖的...）
之后，花了一大堆时间去理清中间的逻辑，又加入了爷爷奶奶，外公外婆在家，做饭或者叫外卖的各种检查以及实现。
--
总结一下
函数名字并不能如实的反应内在逻辑，即便增加注释也没啥用，而且注释和代码的同步也是个老大难问题，代码审查的人也不是什么时候都认真看代码。
每个家庭的人口构成，生活习惯的不一样，会导致简单吃早饭这一件事儿的流程和实现也不一样。
过两天这小人结婚了，还得把老婆 /老公一大家子接进来，又是麻烦事儿。
--
解决办法
理论上书里都有，但是收到人力，财力，时间的限制，我自己不打算完全的去解决问题，我只想做到能够
- 当问题发生的时候，快速识别问题在哪里
- 不用完整看完代码，能够知道依赖是什么
在考虑做一套 annotation ，并且抽象出来一套标签，比如
@家庭情况(只支持当事人性别为男，父母同住，父亲不会做饭，母亲会做饭，家里从来不允许叫外卖) 当然标签可以不止一个，标签也不用考虑到所有情况。我可以增加一些标签间的依赖关系，再加一个小 plugin 去编译这些 annotation 生成文档。甚至于到我这里的特殊情况，我可以安排人肉去检查标签和实际业务逻辑之间是否一致，是否反映了当下最新的业务需求。
估计会有人问为啥不用 DDD ，那我就还得再引用上面的“但是收到人力，财力，时间的限制”一遍
--
我的问题
其实想看看有没有什么现成好用的轮子。。。
2
Select Language