一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第13天，点击查看活动详情。
在新公司工作半年多了，很多事情开始变得熟悉（ji xie）起来，我也从一开始的小白，慢慢成长（xun hua）为一个经验丰富的工程师。
分享一些在互联网公司做一名开发工程师的一些日常。上篇请见《我的开发日常（上）》
开发
在互联网公司的开发工作比我在其他地方累很多，一方面，业务迭代比较多，另外，我负责的主要是C端业务，直接触达用户，稍不留神就容易有很多隐患，所以开发时要求要高很多。
另外，由于公司里部门众多，跟不同部门对接也已经是家常便饭。如何协调各方力量，去把事情做成，也是需要去学习的。
我的开发习惯是，在开发之前，先通过技术评审，窥探出开发内容的全貌，并确定好排期，对于比较有经验的开发工程师来说，基本是能准确估算出每个接口的工作量的，并能给出非常准确的排期。
开发过程中，我会边开发边写单元测试用例，保证每一个子模块都是可以跑通的，单元测试也是很好地告诉别的开发，这块代码是怎么运行的。
另外，我会在开发时加上大量注释，不光是帮自己梳理思路，也是让别的开发明白，我的每一块设计的用意。
最后，开发完会进行自测，虽然后面还有测试的工作，但我必须首先保证我开发的内容没有异常，毕竟上线后，我是要对项目负责的。
提测
自测完成后，就可以进入提测阶段。
这时候不代表开发工作的结束，而是进入新的阶段。根据测试大佬们的意见反馈，我们会看到之前可能忽视的点，并做一些优化改进。
同时，我们也可以进一步提升代码质量，在保证核心逻辑没问题的情况下，给代码加一些兜底逻辑啊，日志优化啊，告警统计啊之类的。
我的经验是，一个项目在写完后，其实在完成了一半，只有真正带着重新审视的目光，打量一下每处细节，并做一下重构优化，才算真正写完。
另外，尽可能保证，在交付测试前，你的代码已经基本不会有大的改动了。测试一般会帮助测试所有的case，如果你中途改了代码，有可能又要重新回归一遍，会浪费很多人力。
上线
关于上线的内容，可以参考我的这一篇《如何做好上线发布》。主要包括上线checklist，预发回归，黑白名单、日志监控等等常见的上线需要关注的点。
复盘
对于一个系统来说，没有bug是不可能的，只要它在线上跑，迟早会出问题。
出了问题不可怕，关键是我们要有快速恢复的能力，并能在恢复后进行复盘总结，让类似情况不再发生。
关于复盘的内容，后续再出文章具体谈下。
我们可以关注：
- 设计、编码层面，有哪些问题
- 测试为什么没有发现
- 监控是否第一时间发现，为什么没有
- 为什么系统不能容错
- 解决速度能否更快、损失能否更小，如何做到
- 怎样避免类似情况发生
我入职半年多来，也接手了几十个项目了，其中也不乏踩坑的，有一件大错，3件小错。有的错误测试也很难发现，踩过的坑也算是我成长路上的宝贵财富了吧。
