后端系统开发之紧急业务开发

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

 

这个项目的挑战在于业务十分紧急,留给产品、开发和测试的时间都非常紧张,有多个模块之间需要联调,因此经验丰富的大佬们很快定下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球员一样,选择了这份职业,就要努力去赢球,这样才对的起球迷的支持和自己的薪金。只是现在身心俱疲,只想好好睡个大觉(失眠睡不着,真是悲剧)。

posted @ 2019-02-19 23:03  张巩武  阅读(147)  评论(0编辑  收藏  举报