第213章 技术与管理（1 / 2）
请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。
三月中旬的一个周五晚上，林晨坐在书房里，面前是两块屏幕。
左边屏幕是投资系统的监控面板，绿红交替的数字显示着各子策略的运行状态。右边屏幕是代码编辑器，光标停在一行注释上。
他已经盯着这行注释看了十分钟。
问题是这样的：金融科技小组的李婷在做风控模型的时候，遇到了一个性能瓶颈。原始数据需要做特征工程，但特征计算的延迟太高，导致实时性不够。李婷试了几种优化方案，效果都不理想，最后找到了林晨。
林总，这个特征计算的延迟有200毫秒，但我们的要求是50毫秒以内。我试了缓存、预计算、异步加载，都不行。
林晨看了一眼代码，立刻意识到问题所在：特征计算用了一个嵌套的SQL查询，每次请求都要查两次数据库。这在离线场景下无所谓，但在实时场景下就是性能杀手。
他本能地想自己写一个优化方案——毕竟这是他最擅长的事情。投资系统的特征计算延迟只有15毫秒，他用的是自己设计的内存数据库加增量更新的架构，这个方案完全可以用在金融模型上。
但他刚要把方案写下来，又停住了。
如果把方案直接给李婷，她的问题解决了，但她不会学到东西。下次遇到类似的性能问题，她还是会来找他。
他想起苏婉那天的提醒：你是Leader，不是救火队员。
于是他换了一种方式。他在代码旁边加了一行注释：问题在SQL嵌套查询，每请求两次数据库访问。想想怎么把数据库访问减少到零次。
然后他把代码推回给李婷，附了一条消息：别急着优化SQL。先想想怎么让特征计算不需要访问数据库。提示：投资系统是怎么做的？
半小时后，李婷回了一条消息：内存缓存？把特征预加载到Redis里，每次请求直接从缓存读？
对了一半。林晨回道，缓存只是存储，你还需要增量更新。不然数据变了，缓存就是脏的。
又过了一小时，李婷发来了一段代码：林总你看这样行不行？特征预加载到内存，数据变更时通过消息队列增量更新。我估算了一下延迟，大概20毫秒。
林晨看了代码，点了点头。方案没有他投资系统的方案优雅，但核心思路是对的——零数据库访问，增量更新。性能从200毫秒降到20毫秒，远超目标。
可以。再考虑一下：如果某次增量更新失败怎么办？缓存和数据库不一致怎么办？
加一个校验机制？每隔一定时间对一次全量？
对。这个校验间隔你自己定，但要考虑最坏情况。
李婷回了一个的表情，然后又补了一句：谢谢林总，不直接给答案而是教方法，比那些直接改代码的Leader好多了。
林晨看着这条消息，微微一笑。
他没有告诉李婷的是，他差点就直接给答案了。差一点。如果是一个月前的他，一定会第一时间写出最优方案，然后让李婷照着做。那样更快、更高效、更不容易出错——但那样他就永远是一个人在战斗，而不是一个团队在成长。
他回到自己的代码上，继续写大模型微调的脚本。
但现在他发现另一个问题：写代码的时间变少了。
以前他每天能写四到五个小时的代码，现在能写两小时就不错了。剩下的时间全被管理事务占满了——周会、一对一谈话、资源协调、OKR跟进、跨部门沟通。他开始理解为什么很多技术Leader最终都变成了纯管理者——不是他们不想写代码，而是时间真的不够。
他在笔记本上写下：
时间分配问题：
管理：60%（会议、沟通、协调）
技术：30%（代码review、方案设计）
个人：10%（学习、思考）
理想状态应该是管理40%、技术40%、个人20%。怎么调整？
↑返回顶部↑