能不能把“行不通”的种种障碍逐一分析以下，给每种类型的障碍提供一个切实可行的解决方案呢? 也就是我们能不能给一个设计模式的列表，所谓设计模式就是“问题清单”。
如何才能像大师一样，上来就知道抽象的接口应该如何定义? 我为什么总是想不出来该怎么抽象?
为了代码复用，拆了很多个模块，导致代码不好阅读了怎么办? 之前代码虽然写的挫，但是 ctrl+f 在一个文件里就可以找到对应的代码，现在找段代码可费劲了。
开槽，开插件，都是为了把代码写得更灵活。但是每一开一个扩展点，就需要写一堆样板代码。如何才能降低“插件税”呢?
经常看见一个表里面有 extra_fields 之类的字段，里面放一个大 JSON。每个需求都要加新字段怎么弄?
为了支持新的业务，往往需要给 OrderType 这个字段上添加新的订单类型。为了不影响已有的业务，还经常要加 isNewBiz 这样的“Flag”来标识新的业务场景。除了一直加新的Flag，就没别的办法了吗?
松耦合模块边界的最佳范例就是基于 UI 的组合。但是为什么在过去的历史经验里，这样的模块切分的方式很难落地? 有没有什么具体的技术方案可以借鉴?
事件驱动是大家谈论解耦的时候寄予众望的技术。但是具体到实际的项目中，经常发现事件驱动没有发挥出什么作用。为什么会这样?