求索阁

最近经历了冰火两重天，上周还可以不紧不慢的开发功能和学习技术，本周突然就被卷入到一个紧急业务的开发之中，要求在这周五开发完成一个全新的后端业务，具体包括制定上下游服务接口、设计后端系统业务流程、开发代码和测试通过，以便在周末和测试同学一起进行紧急测试，这是背景。

这个项目的挑战在于业务十分紧急，留给产品、开发和测试的时间都非常紧张，有多个模块之间需要联调，因此经验丰富的大佬们很快定下3个原则：

1.先定接口。前后端，上下游之间有了接口就能并行开发，于是前端接口、后端接口很快定就落定。

2.删减不必要的功能。时间不充分，需求的细节不够明确，更加不可能面面俱到，优先保证完成核心功能。

3.明确目标和计划。安排好开发、测试日期，确定的事情马上去做，在做的过程中不断完善方案。

经过快乐的加班加点，在红牛功能饮料提神，以及辉哥的鼎力帮助下，终于在周五晚上10点之前写完代码并调试通过，实现预期目标，具备了周末测试的条件。打车回家的路上，我一不小心就总结了关于紧急开发的心得体会（都是血泪）:

1.使用工具。blade、protobuf、gtest、git、vi、vscode，好的工具对于提升效率非常有帮助，腾讯开源的blade十分惊艳，编译静态库、proto、单元测试用例都非常简洁，极大的提高了开发效率。

2.番茄钟。给每个任务定一个番茄钟，专注做事25分钟，休息5分钟，比如预估下开发完成某个类需要用几个番茄钟，然后努力去完成。番茄钟真的是简单又实用的提升办公效率手段。

3.遵循成熟做法。比如proto文件最理想的情况是保持一份；接口文档实时更新；使用gdb设置断点跟踪程序而不是打log，写日志的做法可以作为补充。

4.重视代码检查。写完代码后先做代码自查，而不是着急编译，这样可以解决显而易见的错误，节约编译时间。

5.分清代码质量和程序风格。追求简洁的设计和实现，通过编写UT、测试、Code Review来确保程序正确。对代码规范有敬畏之心，但又不能太在意编程细节，例如旧代码风格是混乱的，这时候不要在代码风格不一致上感到沮丧，而要专注自己要做的事情。

6.避免开会。开会时候沟通不是平的，每个人关心的问题都不一样，人越多，开会效果越不好，要尽量避免开会。

7.寻求帮助。面对没有遇到过的问题，如何保证自己是正确的呢？在接口设计、开发方案、代码实现上遇到困惑的时候，要找专业的、值得信赖的人帮自己检查和把关，《原则》里有这样一段话，大意是你向任何人请教问题，几乎都能听到答案，因此应该只向对这个问题理解更深更加专业的人请教。

8.All in心态。如果不all in，很难完成时间紧急的任务，因为人的精力是有限的，遇到紧急又重要的事情还分心，注定很难把事情做好。

9.痛苦+反思=进步。踩过的坑，要分析原因，犯下的错误，要分析根源。踩坑是粗心造成的还是知识面太窄的原因？造成粗心的原因又是什么？知识面窄如何去解决？沟通方式出现的问题，原因又是什么？如何避免以后还出现？这些问题要去想、去解决。

痛苦的事:

1，对于未来的恐惧和担忧，事情没有做成之前，不知道接下来会发生什么。担心会卡在某个环节、遇到未知困难浪费时间。而实际情况是当你开始担心时，反而没有什么可担心的，当你觉得什么都不用担心时，麻烦可能会悄悄找上门。

2，出现冲突，例如我最关心开发时间，而经验丰富的同事关心的是避免踩坑，在追求效率和谨慎行事上就会产生一些冲突；又比如对于上下游之间异常数据的处理，大家都会潜意识里想让对方多做一些工作，自己少做一些，自然会产生冲突。

3，对家人的愧疚，工作和生活还是要努力去平衡。职场很像NBA，努力打球是没有任何问题的，但是篮球永远都不是职业运动员的全部生活。

快乐的事:

1，软件测试运行成功的那一刻真的是非常开心，开发计划也进行的很顺利，这些得益于all in心态带来的时间和精力保证，以及工具使用和做事方法上没有跑偏，最后还有领导和同事们的理解与帮助。

2，没有延期，代码完成度很高，基本实现预期的核心功能。虽然后续还有很多重要的工作，比如监控、统计，检查业务实现是否有坑，但是这些可以慢慢去完善了。

最后抛出一个问题，以后还想不想做这样的任务？答案肯定是想，就像NBA球员一样，选择了这份职业，就要努力去赢球，这样才对的起球迷的支持和自己的薪金。只是现在身心俱疲，只想好好睡个大觉（失眠睡不着，真是悲剧）。

作者：张巩武