技术体系转型就应该这样干！
王福强
2021-03-19
非标题党标题：“说说技术体系转型”
因为偶然知道之前客户CEO想要推动CTO做公司的技术体系转型，感觉决策的阶段、因素等多少有些不合适，所以顺便说说我对这个事情的看法（注意，是看法）。
关于技术体系转型这个事情，我觉得还是主动权交给CTO比较好， CEO直接指挥，虽然有些时候考虑的也是对的（比如对市场上人才池大小的把握度更有sense）， 但直接指挥会多少打击CTO的积极性，公司技术体系用什么技术， 从老板和人力资源的角度，看人才池大小， 从技术人员角度，则只管自己的喜好。但好的CTO还是会根据团队情况做“熵减”，在技术人员的喜好、能力与业务支撑之间做好平衡。
要做技术体系转型，我觉得一般会有几个因素或者说契机可以考虑：
- 现有技术体系的固有限制无法满足业务快速增长导致的瓶颈， 比如解析性语言性能跟不上（虽然这个例子现在基本上是伪命题，因为很多瓶颈出现在数据库，服务层之前在这个时代基本不太会有性能瓶颈）；
- 团队对现有技术体系的把控度不足以支撑业务发展导致的瓶颈，比如出了问题搞不定， 就好比我当年服务过的某企业，我刚去就要急吼吼地开始救火，其中一个很关键的问题就是原来的团队技术层面偏重Python，但系统交付之后出了问题搞不定（从骨干到基层），我当时就不得不做出决策，推动整体的技术体系转向新团队成员有能力把控的Java技术体系；
- 市场上目标人才池太小，整体分配给自己企业/团队的份额不够，也就不足以支撑业务的发展，比如平常简历都收不上来一两份儿；
当然， 上面这些情况的统一前提条件是： 业务发展从而导致了瓶颈，如果业务没有发展的预期或者裹足不前甚至还处在频繁试错的阶段，那么，盲目转技术体系显然是不合适的，不是关键矛盾。
转技术体系还有个情况 ， 不过很少见，不是所有企业都有机会成长到那个粒度，那就是，盘子足够大之后， “拧毛巾”。
把核心的系统从解释型语言技术体系转变为编译型语言技术体系，往往会有很大的性能提升， 在体量大的情况下，硬件费用可以缩减很多，当年阿里巴巴中文站就因为做了个性能优化，服务器削减了一两百台 （虽然我觉得多少有些邀功之嫌，因为肯定有很多服务器的load没那么高，没有被充分利用）。
嗯， 我的观点就这么多，如果有什么遗漏或者不合适的地方，也欢迎大家留言拍砖。
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
