聊一聊过度设计

212 阅读6分钟

先看一些常见的现象

  • 越复杂的设计,维护迭代成本一定会更高,尤其是需要支持与其设计之初大相径庭的能力,可能会把原来的设计改得面目全非
  • 通用模块设计,对研发个人能力要求很高(一般需要架构师参与),尤其是抽象能力
  • 复杂设计且迭代频率很高的服务,一般会腐化得更快(尤其是服务维护研发频繁变更且研发能力参差不齐的情况下)
  • 业务价值与技术价值的权衡,只追求技术价值而不考虑业务价值以及投产比,可能是一种资源浪费

聊一个故事

19年公司大力推行中台化的时候,两个部门合作(一个作为业务方,一个作为中台方)落地了一个中台服务,为了满足灵活多变的业务诉求以及后续可以接入更多的业务方,中台服务底层采用的复杂的数据结构设计,主要包括以下几个方面:

  • 一套数据结构定义为一套模板,为了灵活的字段扩展,采用了eav模型将列转行进行存储,mysql列转行后,几乎无法支持db搜索,因此引入es作为搜索引擎能力使用
  • 字段的灵活扩展会导致字段增删改之后历史数据的一致性问题,因此引入了快照机制,字段每一次变更,都会生产一份新的快照,历史数据使用当时的快照版本以保障历史数据准确性
  • 字段支持非常多的数据类型,比如枚举。为了支持枚举字段间的级联选择,需要存储关联关系
  • 设计之初,考虑提供一套通用的数据管理后台,同时为了支持客户个性化诉求,管理后台几乎全配置化(例如数据列表可展示字段、可搜索字段)
  • 不同的业务领域数据模型之间可能存在关联关系,比如业务A定义了3套数据模型(模型A、模型B、模型C,其中C依赖B,B依赖A),为了支持关联搜索(使用模型A的字段,搜索所有其关联的模型B),ES中进行了大量的字段冗余
  • 随着业务的发展,列转行表数据膨胀过快,需要进行分库分表

从技术的角度来看,当时这些设计本身是合理的。中台服务为了通用性、扩展性,原本简单的设计需要复杂化才能满足诉求,但这个中台真的是合理的么?

下面我们通过19年~24年整个中台、业务的现状来进行分析。先看遇到的问题:

  • 从使用角度来说,目前服务的使用方仍然只有最初的业务方,一来是公司没有类似的业务诉求需要用到,二来是随着业务的发展(尤其是业务发展迅速且强势),原有的所谓中台已经被业务定制过,变成了业务的存储层(强业务、弱中台的必然结局),其他业务接入成本很高,且底层改动可能会对现有业务造成影响 (画外音:业务服务的都是大客户,稳定性要求非常高)
  • 复杂底层设计的迭代成本很高,尤其是这一套全配置化且支持快照的底层数据结构设计,只适用于设计之初以及当时预想的场景。当业务发生大的变化时,这套设计的调整代价非常高
  • 业务边界不透明,资源投入不匹配、目标不一致、责任不对等等,导致团队之间相互扯皮。这个其实是更为致命的,对于中台方来说,只有一个业务方且越来越定制化,本身已经失去了中台价值。作为中台方就是以维稳为主,不会投入更多资源。而对于业务方来说,业务快速发展,需要中台投入更多的资源来支撑。业务关注的是业务目标,中台关注的是中台目标,如果中台的目标定为:更好的服务好这个业务,几乎是不太被认可的。另一点就是责任划分不明确,人都是趋利避害,当两个团队边界不清晰时,有问题就想甩给对方,有好处就想捞给自己,因为不清晰滋生了扯皮的土壤,这也是为什么很多时候会强调业务->团队聚焦。聚焦之后就没得扯皮,因为价值、责任都是你,你为此负责,你从中受益 (画外音:业务团队因为业务发展好,绩效普遍更好,但为此投入很多的中台团队并未从中受益)

目前的解决方案是将服务交接给业务团队进行维护,但整个过程也是较为曲折。复杂的设计让业务团队的同学也是望而却步,心里盘算着:不要接这个雷哈哈哈哈 画外音:CTO一锤定音 --- 没错上升到CTO进行决策了,由业务团队统一维护,但需要中台侧先改造 --- 把原来的冗余复杂设计逆向改回来..... 完成后交接给业务团队

如何避免过度设计?

相比如一开始就为太多不确定的事做过度的设计,我们更倾向于边迭代,边重构。这是一个不断的自我纠错的过程,而且代价很小,更符合现在的敏捷开发流程。关于重构,可以参考另一篇文章:从现在开始尝试重构 那是否代表我们写业务代码时就不需要进行任何设计?当然不是,我们只是没有将整个服务架构做过度设计,但微观细节上还是需要谨慎,比如代码可扩展性、并发场景处理、慢查询规避、数据一致性保障、防御性编程等,这些其实可以算是基础的编程能力,应该刻到骨子里并落实到你写的每一行代码上另一点我觉得很重要的事,任何设计一定是为了解决实际问题(注意是实际问题而不是yy出来的),而不是为了空中楼阁、锦上添花,甚至为了炫技。当然,为了稳定性我们可能需要做一定的冗余设计,但需要考虑ROI不鼓励经验不足的同学独立做大的模块或者系统设计,如果真的需要他们设计,也需要对涉及内容充分的进行评审和讨论。否则可能在未来要付出更大的成本去填这个坑个人更需要去通过不断的学习优秀实践、前沿技术去拓宽自身的视野,并在实践中不断总结找到更好的解决问题的办法