什么样的代码是不可维护的？
一是改不好的，代码和代码间打架关键还是缠在一块打，亲是亲到了，打成什么样，变成了其次。二个人打，还好分开，分不开的状况是几个代码一起打，想要分开不是很容易的事，因为他们打架之前是兄弟。不打不相识 进来的劝架者其实是最痛苦的，很简单，因为结拜也是他撮合的 突然有一天 那边需要人手了，结果，好端端的伙计又要浪迹天涯，我真的心太软 ~ 函数的拆解 是一个方式，拆到了精核小强的也屡见不鲜。但是有没有更好的方式呢
二是能改改，但是兄弟太多，组织机关发散形成，四海之内兄弟又是分层的，东大爷感冒了，西奶奶就不舒服了，实际上大爷不只一个，奶奶也繁花锦簇，变成府了，两家结着亲，爷爷奶奶数不过来的时候，不能再多一家了 他们的交往用了飞鸽传信，关键一对是很平常的，鸽子满天飞了，人间是有多不对称啊。鸽子还是要好好养一养的，民航是怎么管的？只不过它不叫eventbus
三 回调拆解，每次带一个亲信，你去和xxx 说，做完了马上来报我，目前是较合理的临场操作方式，有时一次还可以带多个，各走各的，早晚回报，到齐之后，亦开始一个新的征程，注意，这里的征程对应的行为是事务，是抽象的面向对象编程，完全可以 小的们回来一部分 就开始飞一个新的航班，可以用标志，也可以用标志池做持续管理。事务做不做完，是需要数据佐证和业务完整性 校验的。小业务带上自己的特征聚合成大业务，其实和我们看的层次分会和事务的飞鸽又是类似的，只不过在裹带体量上出现了不一样，悄悄的做了一个进化的递归
有缘千里来调用，无缘就写隔壁行