今天分享一个在前团队的时候，在软件架构方面的一次失败案例。
目标：
1、提升业务开发的速度，加快产品价值的交付。
2、降低业务开发的技术门槛，使能力低的同学也可以进行开发。
针对这个目标，当时的架构设计原则是：
1、业务功能配置化，通过xml、json等配置文件就可以把用户需要的功能配置出来，例如表格数据的展示、下拉列表的交互、筛选数据等功能。
2、框架层提供各种底层支持，屏蔽数据层，统一各种组件。
后来看来，感觉像是这两年火起来的低代码平台。历经艰辛，框架层开发完成上线之后，取得的成效和不足有：
取得的成效是：
1、功能开发同学知道框架层的配置规则后，开发新功能的确比之前快了很多。
但也有一些意料之外的副作用：
1、框架层难以覆盖全所有的场景。开发过程中，一旦出现问题就需要调试框架层核心代码，并且调试起来难度极大，这个难度主要体现在两个方面，一方面是框架层代码并没有直接体现业务，理解起来比较困难，另一方面由于需要兼容的场景比较多，代码变得无比复杂，改动起来也是动一发牵全身。
2、更没有想到的问题是，研发人员更难培养和留任。一线同学，天天写配置，研发能力得不到提升，一旦遇到框架层的BUG，又极难搞定。
基于以上问题，后续我们在做架构调整的时候，就放弃了这套方案。
从这件事上得到的经验教训有：
1、软件抽象要适度，不要多度，根据实际情况来。
2、软件可维护性比优雅性更重要一些，可以容忍部分的冗余代码、垃圾代码存在。
3、要满足各种水平的开发人员，在实际工作中的成长性。
