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