假如那一天，我真的撂挑子不干了……

从高中开始接触编程，大学通过校招实习生进入腾讯，做过一线技术小兵，带过团队，做过产品——十年长路，从技术新人到资深大牛，作者大飞将在本文中分享他的程序员进阶之路。

作者 | 大飞

本文经授权转自大飞码字

2012 年的时候，我参与了一个项目，我觉得那个项目是我职业生涯的一个转折点。经过那个时间节点后，我在能力、视野、心理上都获得了巨大的成长，也为自己后面的发展奠定了基础。

当时产品刚刚站稳了脚，市场总算攻下来了，后台技术上，面临的问题是稳定性和成本。

当时的技术总监找到我和我的 leader，说目前的业务发展越来越快，用户增长迅速，业务需求也多，而目前的存储存在三个问题：

1. 机器的性能没有充分发挥出来；

2. 运维不够自动化；

3. 灾备能力不够好。

希望我们能自己研发一个。性能上要有三倍的提升，而且运维便利性和灾备能力要有质的提升。

当时听完，既兴奋又觉得压力山大。

兴奋的是可以大干一场，做个分布式存储，还是很牛的。但对于老大提出的目标，自己心里没底，不知能不能达标。

之后团队就开始讨论，开始设计了。我们很快有了方案，来回跟技术总监过了几次，大家觉得方案没问题后，就开始搞了。这里，因为没有充足的时间做业务摸索和方案调研，也给后面留下了巨大的坑！

我用了一个月的时间，完成了编码的工作，再用了两个星期进行了各种线下测试。当时以为自己很牛，上面给的是三个月，自己一个多月就完成了。

接下来，才是噩梦的开始。

第一天，线上验证的结果就狠狠地打了一把脸。bug 数量超出想象，而且有各种奇葩的 bug。后面又花了两个星期，加固各种测试，修复 bug，总用时两个月后，再次上线。

我小心翼翼地采用灰度的方式来进行再次验证。找了台机器，慢慢放量，经过一个星期的时间，终于在可见范围内没有 bug 了。

后面又灰度了几台机器，在灰度到一台访问量高的机器时，又出问题了。机器的磁盘性能顶不住了，晚上高峰期的时候，又发现网卡流量也撑不住了。

当然慌得不行，感觉完蛋了，时间期限也快到了，性能不但没有达标，还比原来的系统差了。

我 leader 知晓这个事情后，也一起加进来，想解决方案。我们又折腾了一周，终于搞清楚了性能问题，也想出了应对的方案。

后面我 leader 也加入进来，一起编码，一起 review 代码和测试。历经一个月后，再次上线。

那一个月，是我最难熬的时间。因为已经上线了几台机器，要回退回去，又要折腾好长时间，而且机器还要留着做性能试验。

所以我当时白天要写代码、测试，晚上高峰期又要盯着那一触即崩的系统，周六日也要看着。简直就是精神和体力的双重煎熬。

我记得有一个周六，我同学从深圳过来，吃完饭后，准备去唱 K。结果手机突然收到个报警，我只能杀回公司处理 。那时候感觉这简直就是一份非人的工作，有好几次想辞职不干了。

不过当时又想起毕业时，导师说的，离职都不怕了，工作还有什么好怕的。于是就继续干下去了。当然心里就一个念头，要搞定它，都没想什么 996 了，几乎是 7 *24 小时待命。

最后，总用时四个多月，终于发布了第一个稳定、性能达标的版本。

后面这个存储系统随着业务的扩大，不断升级改进，最终整个部门几乎百分之九十五的业务，都使用了这套存储系统。

虽然我最后离开了存储团队，但那段经历让我记忆犹新。现在回过头来看，有几点感悟：

没有规范的流程，只有先扛住再优化

规范的软件开发流程，在高速发展的互联网产品部门似乎并不存在。

回想起当时的团队，整体开发团队好像不超过 40 人，而且有大量的业务需求。

在当时要找个专家评审团，评审一番，再做个业务调研，做个详细架构的设计，再来排期，一步一步地实施，按正常流程下来，估计要耗费一年以上的时间，等到那个时候，业务都已经凉凉了。

事实证明，在当时的业务快速发展，人力资源受限的情况下，先搞上去顶住，再慢慢地做优化是对的，虽然不符合传统的软件开发流程。

业务访问模式和存储模型的匹配

这个感悟跟技术强相关。当时接到这个存储系统的任务时，对存储模型的理解，只停留在 MySQL B+ 树的层面。

直到后面，才深刻地理解到，存储模型的设计是跟业务访问模式强相关的。而业务访问模式的理解，来自对业务的深刻理解和对众多子业务的归总和抽象，还有一个是对未来业务发展的预判。

第一点是需要对已有的业务系统做深入的调研和探讨；第二点是对未来的预判，需要敏锐的业务洞察力和技术预判能力。

所以，业务跟技术不分家，是相辅相成的。

互联网技术有很多都是倒逼出来的

当时的第一个版本，你可以认为是摆不上台面的东西，只是经过各种折腾，它终于慢慢跑了起来。

一开始的时候，它只用在了一个业务系统上面。但因为当时的性能在我们特定的业务场景下已经超过了 MySQL 的性能，而且灾备能力也优于 MySQL，系统的口碑在团队内部就慢慢传开了。

一方面，我们不断在内部兜售我们的系统，希望业务接入，另一方面，业务团队也不断给我们提出新的需求和挑战。

虽然整个团队的人员一直都不多，最高峰时好像也不到20人，经过几年的发展，经过各种业务不断的锤炼、优化，系统却慢慢强大了起来。

去年基于这个系统写了一个 paper，还被顶级的存储会议 VLDB 收录。

虽然我那时已经离开了存储团队，去了业务部门。不过我仍感慨，当年那一坨仅仅可以跑起来的代码，如今竟成长为一个如此优异的系统，我内心也是倍感欣慰。

仔细想想，也因为有了这个伟大的产品，才倒逼出了这个优异的系统和优秀的技术。

能力、视野、心理素质

完成那一次艰难的任务后，我并没有马上被升职、被加薪。我还是一如往常地做着个小兵，写着我的代码。

但我明显地感觉到，我的技术深度、技术视野和心理素质有了一个质的变化。

在技术深度上。我在跟其他业务同事探讨技术方案的时候，有时会惊讶，“这个不是很简单吗？”，“这个不是常识吗？”，有一段时候，我有点困惑，怎么他们连这个也不懂。

后面我才意识到不是这些东西简单，而是因为自己一直在思考这些问题，权衡各种方案。在自己的脑海里，很多东西已经变成了一种“常识”，一种自然的逻辑。而有些同事，他没有做过基础架构的事情，所以他并不清楚。

在技术广度上，我看很多其他的系统设计，似乎可以一眼看透了。跟负责人聊聊他的业务痛点，自己脑子里就自然出现了最合适的方案。

因为发现无论业务怎么变化，在后台架构领域，业务会遇到的问题基本都是差不多的，虽然表现形态不同，但本质其实一样。你深入理解了本质，很多设计工作，其实就是在权衡成本和收益，剩下的就是体力活了。我相信这点在其他的技术领域也是相同的。

在心里层面，我觉得那次的成长非常巨大，好像经历那次之后，自己心理上再也没有遇到更加难熬时期。后面的工作任务中，其实也有很难的内容，但自己好像有了一种发自内心的自信，会有压力和紧张，但心里有底气——一定可以搞出来，只是时间问题。我觉得这种技术自信，也源自于那一次的历练。

结语

那是一次职业技能和心理素质双重考验并带来成长的一个经历。那个时期过后，我对技术工作突然有了很大的信心，感觉困难都是可以解决的，而且心理素质、抗压能力都获得了巨大的提升。

到现在，我也依然很感激那次经历给我带来的成长。突然想起了一个兔子拔萝卜的图片，当你觉得最艰难的时候，也可能是收获最大的时候。为处于困难，处于压力中的同学们共勉！

（图源网络）

声明：本文经作者授权转载，如需转载请联系原作者。

作为码一代，想教码二代却无从下手：

听说少儿编程很火，可它有哪些好处呢？

孩子多大开始学习比较好呢？又该如何学习呢？

最新的编程教育政策又有哪些呢？

下面给大家介绍CSDN新成员：极客宝宝（ID：geek_baby）

戳他了解更多↓↓↓

 热 文 推 荐 

System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！\n");
cout << "点个在看吧！" << endl;
Console.WriteLine("点个在看吧！");
Response.Write("点个在看吧！");
alert("点个在看吧！")
echo "点个在看吧！"

你点的每个“在看”，我都认真当成了喜欢