代码架构设计的复杂性就像一个左右摇摆的天平。
过于简单,则越有可能产生不好的代码,增大代码修改的难度(需要理解原有不良代码),降低代码维护性。
过于复杂,则产生无用的抽象层,增大代码修改的复杂度(需要理解原有抽象设计并保持),同样会降低代码维护性。
过度设计,其实就是把维护烂代码吃的屎,转成了维护烂设计吃的屎。

有个关键的问题:对于一个设计,想让它被使用起来越爽,相应要去维护它也越累。
我们有时常常无视了设计带来的维护复杂度,只看到了它的使用便利性。我们为软件工程的各种设计而兴奋,梦想着在良好设计的代码库中高效工作而兴奋。

实际上,天下没有白吃的午餐。必须认识到维护设计也有成本,势必会有人为此承担债务,但不代表软件设计就毫无用处,适当的设计可以使使用便利性的好处高于维护复杂性的坏处。

业务代码在设计上要更多地权衡利弊,因为使用者和维护者是同一主体,两者此消彼长,但却也不是等额增减。争取设计带来的使用便利性大于维护复杂性。如果两者相等,设计便是无用的。如果使用便利性小于维护复杂度,那这个起反作用的过度设计应当尽快被移除。
特别地,对于基础通用类库,与业务代码不同,抽象设计的使用者和维护者不是同一批人,值得在设计的天平上,比业务代码更多地倾向良好设计。基础类库的维护者可以通过好设计,将广大使用者的债务负担,转移至维护者一次性解决或削减。