周报工作总结及感悟 最近这周，项目边缘的稳定性确实踩了一次大脚。 本来想着把那个后台报表的接口做稳了，结局测试一跑，直接卡死。
不是代码逻辑的难题，是数据库响应忒长，中间件没处理好。
那一晚我守到凌晨，看着监控面板上跳动的红色数字，心里那根弦像是被扯得忒紧。 实际上前前后后，这块模块的整体效率确实提升了 20%。
那会儿做分页查询要查好几次表，目前改成了基于索引的预加载方案。数据量从 5000 条压缩到了 100 条，拿这个例子说，就是那些那会儿专门用来搞测试的“小 bug"，目前根本都找不到地方藏了，系统跑得更顺当了。 不过，刚上线那会儿还是有点喘不过气。
那会儿测试那些边缘情况的单子，目前一天能跑完，剩下那 80% 的概率都绑定了。
有时候想吐槽，如何把自己那点“小智慧”变成了“大费事”。 就比如上周那个大活动，全链路压测跑了一整夜，核心瓶颈在消息队列和数据库同步这块。
原来当作是网络延迟，后来发现是数据库事务锁了。我特意拿一组数据对比了一下，之前每个用户平均响应工夫 120 毫秒，目前优化后变成了 45 毫秒，也就是把那个锁给释放了。
这数据摆在那儿，根本没人能装作没看到。 真正的挑战还在后面。 之前当作做了那么多功能，用户体验就解决了大半。但今天复盘下来，感觉像在沙滩上建城堡。昨天刚把前端交出去，目前又发现有个交互逻辑没法做。
那会儿认定这点小事能搞定，目前认定，要是这次卡在接口延迟上，后面这周就要停手了。 这就有点尴尬了。
那会儿写代码认定只要逻辑对就行，目前发现用户体验才是硬道理。
有时候为了追求新功能的速度，差点忘了回头看这条用户到底有没有真正用起来。
比如那个新支付的流程，别看审批速度快了，但用户填表的那个入口，按钮忒小了，手指头伸不进去，这明明是个小细节，目前却让我意识到半天。 我也想过，是不是该改策略了。
那会儿总认定“加功能”是理所自然的事，目前认定，功能再多，要是体验差，也是白搭。 还得感谢团队里的老伙计。上次那个死代码，要不是大家熬夜查了一下午，我估摸早就被埋了。大家那种“我们一起把这事儿通融一下”的态度，让我认定心里舒服多了。
那种劲儿，比任何时候都要让人认定踏实。 想想那会儿，总认定周报就是自己干了多少活，花了多少工夫。目前认定，周报实际上是把这段工夫里那些坑、那些弯路、还有那些没想到的烂尾楼，都实实在在摆在桌面上。 这周四要上更大的版本。 说实话，我心里还是有点忐忑。之前当作这次只是小修小补，没想到这次如此重。 但仔细想想，这次的重，实际上也没那么夸张。就是那些平时总被漠视的细节，加上这次对整体流程更深的思索。
要是能把这次压测的难题彻底解决，把那些小坑填平，那实际上就是一件再正常不过的事。
毕竟，技术这东西，没有“小修小补”，只有“大起大落”。 希望这次经历的教训，能真正变成赶明儿写代码时的护身符。别总想着如何把功能做得更快，也别总想着如何把界面做得更花哨。多想想用户到底在用啥，多想想那些可能会出错的地方。 要是能把这些想法落地，哪怕只是一点点，那也值得自己给自己点个赞。 下周如何样，先别急着定啥大目标。先把这周剩下的那些报错、那些日志、那些没解决的纳闷，一个一个啃下来。
毕竟，路还挺长，并且自己一个人走忒累了，还是先去跟团队把.Backend 的保险加固，先把那个核心链路理顺了，再谈装机子。 别想着完美主义，能上线的才叫上线。能跑通的代码，才是真正能用的功能。


相关标签：