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