不过度设计，简单最美。我们设计的时候，经常会忧虑，万一以后增加什么需求该怎么办，那我就先加了某种设计。如果这个增加并不会带来太大影响，没有问题。如果这个增加，大大提高了整个设计的复杂度，甚至可读性和可维护性都大幅度下降，则要再三思而行。

不存在完美的设计，因为世界是动态的，业务在变，软件技术在革新，开发者的能力和视野也提高。所以，我们需要对现实做一些妥协，避免出现为了追求极致完美，而大大提供项目交付风险。甚至在代码已经稳定时，因为对设计不满意推翻重建更要慎重。

微小重构，在风险可控的情况下，及时调整。因为系统处于熵增的状态，看到代码维护性开始下降，我们又拼命堆需求，而不打算做点小重构来优化的话，系统寿命会大大下降。做重构不仅仅是前人栽树，后人乘凉的事情，只要还在这个项目，自己总会有可能再次维护到这块代码，这也是给自己栽树。

业务决定了架构。比如最新流行的模块化，如果不是因为业务量和业务复杂度达到了一定程度，分模块独立开发其实并不需要。

----菏泽软件开发----