ML - 首页 - 微博


说一个最近五年内我做的最错误的技术决策。

当初我们有一套庞大而复杂的系统经常出问题并且难以维护,在忍无可忍的情况下我决定投入团队里最核心的一群工程师做一次彻底的优化。当时负责优化工作的同学给出的方案是四个模块保留一个,剩下三个全部重写。

我认为全部重写工作量太大,并且做出来的东西在行业里有很多类似的轮子,不如四个系统一个基于开源项目二次开发,一个基于微博内部的另一套框架扩展,一个基于原有服务优化,第四个模块行业内还没有像样的竟品,应该集中力量研发这个模块并且开源出去,争取成为行业标准。

但负责优化的同学对这个方案十分抵触,认为一定会踩坑,就算是自己在重复造轮子,也是自己的轮子更可控。

我之前的风格一直比较强势,但是当时不知道抽了什么风,觉得应该给下面直接负责项目的同学一些自主权,不能过于打击同学的积极性,就没再坚持自己的意见。

这个项目做了一年多,跟着又优化了一年多,经历了大坑小坑,终于替换了原有系统。

可随之而来的是居高不下的维护成本:

新系统里的很多设计是自下而上的,由于场景有限,很多功能只是把重构前的系统功能换个方式复述了一遍,而行业内很多先进的理念并没有得到应用,系统的核心效率没有得到提升。

同时这是个专属系统,意味着除了几个核心开发,没什么人理解这个系统,而核心开发也会逐渐厌倦一直维护这个孤岛式的系统。

而所谓的自己的轮子更可控,也仅限于原有开发人员没有离职的情况,每当人员流动,就意味着新人不可避免的把坑重踩一遍。

于是,在当初几个核心开发离职之后,我又不得不永无止境的投人和投精力把当年做的功能嫁接到开源或者内部项目里,把那些轮子代码删掉。

直到今天都没有删完。

每当遇到没删干净的轮子代码出问题的时候,我都会成宿成宿的睡不着觉,后悔自己没有早点悟出架构师可以对技术方案妥协而不应该对人妥协这个道理。

https://weibo.com/mygroups?gid=4021463604530306