关于软件工程过度设计的一点感想

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

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

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

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