互联网行业的大头兵说白了就是干活的主力，主要负责执行，不承担系统架构业务，也不负责团队管理。对应到公司，大概对应阿里的P5-P6，字节1-2和2-1。

这篇文章主要总结一下作为大头兵，个人总结的一些心得体会。全文3000字，分为需求对接、技术方案、代码实现、测试和上线、闭环收尾，阅读需10min。希望看完这篇文章能够对你有所帮助。

coder

需求对接

日常工作中的第一步是对接需求，可以从不同需求来源来分析一下如何对接好需求。

来自产品的需求

正常来讲，大部分需求都来自产品。产品和开发是最容易产生矛盾的角色，产品和程序员总是相爱相杀的，也有一堆梗。这里列几个平时经常碰到的问题。

“明天上线” - 排期问题

产品永远希望今天提需求明天就上线，站在他的视角来讲肯定希望越快越好，而且他的背后往往是业务方、用户或者leader也在催，他也有压力。但是如果你觉得估时有问题，或者你有其他更重要的事情要做，应该把问题抛出来，交给leader和PM去判断排期问题。千万不要接到需求就闷头干活，到时候干不完锅就全在你身上了。

“一句话需求” - 需求不明确问题

理想情况下，程序员在接到需求后，开发前应该能看到产品文档、原型图一类的东西。

但现实可能是既没有需求评审，也没有需求方案，只有一句话。有时候是产品图省事，或者他不够专业，也有可能他太忙了。但是无论什么情况，这样的需求程序员都不要直接开发，首先应该问清楚需求背景，关键交付物是什么，当达成共识以后才开发，否则自己瞎猜到时候出了问题又要返工，来回扯皮，身心疲惫。

“这个很简单” - 技术可行性问题

有时候产品会提一些不切实际的想法，或者实现成本太高的想法。这时候也要把问题抛出来，不一定直接拒绝，但至少要让产品知道这不是一个好的方案，跟产品沟通能不能有别的方案来达成需求目的。

来自技术leader的需求

技术leader提的需求一般更有意思，因为基本上是技术问题，做起来会比较有意思，沟通起来也比较顺畅。

技术改进类

这类需求比较常见的是性能优化、技术难题、稳定性建设(日志监控告警)等。技术leader提这类需求是因为这些内容就是他的工作职责，但是需要人来执行。按部就班来做就好了。

调研类需求

这类需求一般是业界新技术调研，探索新的业务方向，或者帮助改进现有业务。需要注意以下的点：

  • 明确调研的目标。在调研过程中始终思考新技术与现有业务的结合点，不要为了调研而调研。
  • 及时记录和同步信息。因为调研最终不一定能产生结果的，因此让leader知道你在干什么就很重要。另外，调研过程中的信息本身就是调研结果的一部分。

来自用户的需求

有时候会直接接到来自业务方的需求，因为业务方跟你比较熟，可能会越过很多人，直接想要你来做这个需求。这当然代表了业务方对你的信任，你也不可能拒绝，但是这样也会给你的工作带来额外负担。你这个工作做了可能别人也不知道，甚至可能会影响做其他的单。

正确的做法应该是及时和产品、PM和leader同步这个信息，让他们来决定。即使最后这个活还是你来做，但是性质不一样了，不会出现默默地干了一堆活却没有体现在项目贡献中。

自己给自己找事干

最后，如果你很有owner精神，可能会发现项目有需要改进的地方，想要去改进一下。比如哪里有个隐藏BUG，哪里设计不合理存在技术债务，甚至觉得哪里代码不合理想要改一下。

个人建议还是不要随便改的好，即使发现存在问题，也不要盲目动手，因为改了以后说不定会产生新的问题。正确的做法还是往上抛，交给leader去判断或者排期解决。

技术方案

接到了需求，下一步就是实现了。不过别急，写个方案先。

有些同学可能不喜欢写方案，组内也没规定要写方案，拿到需求直接上手就开始写代码。当然有些小需求确实可以上手撸代码，但是对于稍微复杂一点的需求，直接上手很容易导致返工，最后反而是追求快导致结果慢。

写技术方案至少有以下的好处：

  • 技术方案是书面记录，有些口头的需求沟通、技术沟通很容易会被忘记，导致后面扯皮、返工，书面记录可以有效解决这一点。
  • 写技术方案能够帮助你清晰地定义问题，完善解决方案，最后落到具体地写代码上就可以纯粹是一个手速问题，因此方案的重要性是要远超过后面的代码实现的。
  • 在功能上线后可能要汇报，这份技术方案也能够帮助你在汇报时有材料、有数据可以参考，因为如果没有技术方案，过一段时间你汇报的时候可能记不清细节了，再回忆就很痛苦，而有技术方案你就可以把技术方案整理成汇报材料，你的工作成果也更加容易凸显。

希望到这里已经说服了你开始写方案。接下来讲讲如何写方案。

技术方案并一定要写得多漂亮，因为项目时间紧，写了也不一定会有人看(leader可能很忙)，可能只有自己看，所以力求简洁，只记录关键信息。以下是技术方案中比较重要的点：

  • 背景和目标：交代方案的背景、需求，说明为什么要做这件事情。要解决什么问题，要达到什么目标。这一部分最重要的是把问题和需求定义清楚
  • 实现方案：具体的实现方案，可以画架构图来说明，也可以写点伪代码
  • 测试方案：虽然测试是QA的工作，但是也可以提一嘴哪些是需要重点测试的，以及如何测试，给QA同学做个参考，减少QA同学的成本，因为开发才是最懂实现细节的人
  • 时间预估和任务分解：一般大的排期PM和技术leader已经定过，但是大点的单，比如3-5天的，依然可以自己拆分成1-2天的具体任务来做
  • 风险和TBD(To be discuss)：该方案存在的风险和不确定的问题可以提一嘴，交给leader来判断。

代码实现

有了前面的技术方案，代码实现就是手速问题了。但是也有一些值得注意的地方：

代码风格

现在的IDE一般都有lint和format工具，所以代码风格也不是问题。

有兴趣的同学可以看看Google的代码风格指南。

注释

一般比较推崇代码自注释，即良好的变量和函数命名就可以让人理解代码，不需要额外注释。

如果要加注释，应该描述“why”而不是”what”，因为做了什么代码本身就可以描述，需要说明的是为什么要这么实现。

日志

对于线上服务来说，排查问题基本靠日志。因此最好在关键位置增加日志输出，避免功能上线后出了问题只能抓瞎，然后加班找BUG。

单测和自测

最后是测试问题。有些同学可能觉得测试是QA的工作，研发不需要关注测试问题。但是质量真的不是测试出来的，测试是作为兜底手段的。

写单测是一个好习惯，尤其是一些关键逻辑，QA只能从外部测试功能完整性，有一些边界条件QA也不清楚的。当然现实是有时间、单测成本低的情况下才写单测，没必要刻意追求代码覆盖率，这也是一种取舍。

最后是提测前的自测，代码写完了并不能直接丢给QA同学去测试，必须先自己能跑通主逻辑。直接丢给QA测试完全是在浪费彼此的时间，到时候QA还是要来找你疯狂对线。

Code Review

如果组内有code review环节的话，一个建议是对自己的代码严格，对别人的代码放松一点，更倾向于通过。“严于律己，宽以待人”。因为代码好坏存在一定的主观判断，而实现细节只有写代码的本人才清楚，有时候你说这样不行，但现实是这样实现就是最好的。组内新人的代码可以多review一下,正常情况下应该是方案review比code review更重要。

测试阶段

程序员和QA又是相爱相杀的角色。这中间的矛盾还是视角不同。程序员当然不想自己被否定，“我写得代码怎么可能有BUG”；QA怕不符合预期到时候上线出了问题背锅，所以会很严格。

“我在开发环境没问题啊” - 环境问题

环境问题是老大难问题，有时候跟组内规范也有关系，组内节奏快环境混乱也是常有的事，这其实属于研发过程改进。

作为开发，至少要保持一点，交付给QA的环境要稳定且一致。稳定是指不要随意乱动QA的环境，到时候测出来问题发现是刚变更了环境那就是在浪费彼此时间了；一致是要交付给QA的环境跟你自测的环境尽量一致，或者在测试环境先自测一下在告知QA测试，而不仅仅是在自己的开发环境上自测。

“这样符合预期吗？” - 对齐期望

是feature还是bug要根据预期来决定。QA会考虑多种场景下的系统行为，有时候超出了需求范围，开发需要判断这种行为是不是符合预期，有时候甚至要拉上PD来对齐。符合预期的就是feature，不符合预期的才是bug。

上线阶段

通常组内都会有上线规范，按照组内的规范上线即可。如果因为节奏太快没有上线规范，那么应该尽快确定规范。记住一点原则：保持对线上环境的敬畏，不要随意变更。

绝大部分的故障都是变更引起的，比如最近的阿里云故障也是变更引起的。

即使是老司机也容易翻车，上线的时候还是不要艺高人胆大的好。最怕的是艺不高，但人胆大，一通操作就等着写故障报告吧。

闭环收尾

这里说的闭环，是指功能上线后及时汇报，汇报完了这个事情才算是结束了。通常来说，产品会去找需求方验收功能。作为研发，也需要及时向leader汇报工作进度，一方面也让leader知道项目现在的进度，另一方面也是让leader知道你干了什么。

这一步很多人都会忽略，但是汇报是工作中很重要的一个环节，如果没有汇报这一步，可能你做的工作就被leader忽略了。这里并不是说你要面向汇报工作，而想说的是汇报是一件很正常也很重要的事情，是工作内容的一部分，是对工作的收尾。

大家都很忙的，leader的一部分工作职责就是知晓项目进度和手下的人进度，主动汇报也是帮他节省这部分的时间，因此leader也会更喜欢主动汇报的下属，对你个人的升职加薪只会有好处。

结语

不知不觉居然写了这么多字，本文基本上覆盖了程序员日常工作的绝大部分环节。

如果看完后对你有启发有帮助的话，欢迎多多点赞加关注，有任何想法也欢迎交流~