你有良好的编码习惯嘛？

一、背景

经常性重复一些流程，时间久了就容易越过一些步骤。eg:

• 简单的功能代码直接上开发环境，本地localhost都不自测；
• 紧急的功能，直接上测试环境；
• 修复bug后未在测试环境验证就直接告诉运维部署，结果编译失败；
• 合并过程发现代码未合过去；
• 部署发现部署的代码和本地不一致…

这些问题看起来都很“幼稚”，其实暴露的问题就是开发流程不规范；没有良好的编程习惯。虽然不至于每次都按照list罗列的步骤去执行，但是很有必要把一些基本的操作内化成一种习惯，一种优秀的习惯。

二、编码前

• 透彻理解需求文档
• 写好设计文档
• 评估开发时间

2.1 透彻理解需求文档

谁最了解这个需求？我觉得未开发前是产品；开发完成后就应该是开发人员，而不是测试。

开发人员要理解需求文档，最好的方式就是多看几遍，从技术角度思考能否实现？如何实现？

不局限于只了解自己开发的部分，而是要了解自己做的功能的上下文；

理解的越透彻，提出的疑问就越多，越能尽快、尽早的暴露问题。我就经历过几次需求理解不透彻，立马开干，做到一半发现做不下去了的情况，然后改方案、返工…

2.2 写好设计文档

是否能够顺利编码的最重要、最核心的环节。
不要觉得写文档是浪费时间，兵马未动，粮草先行。想清楚了再做，想清楚了，写代码时间其实是很短的，前提是一定要多想。

我们开发前，一般都有对应的技术文档，维护再wiki中。这么做好处多多：
1）梳理技术设计思路；
2）组织的知识资产；
3）把ISO、CMMI等认证所需资料融入到日常开发中。

需要做到：
1、考虑每个技术细节和技术实现难易点、写清楚实现流程；
2、别人根据文档即可顺利开发；
3、这个过程尽可能多的提出所有疑问：针对产品的？开发的？测试的？UI的？
4、快速、高效的出设计文档。
原则上一个设计文档再过完需求的2-3h之内出来。

2.3 评估开发时间

Leader分配任务的时候都要考虑开发时间。自己写完设计文档之后，对开发时间应该做到心里有数。如果leader评估的开发时间和自己心里评估的开发时间有出入，要及时提出来。

• 讲清楚为啥需要更多的时间？
• 讲清楚如果时间不够，存在的风险是什么？

三、编码中

3.1 确定开发的分支

基于哪个分支来拉分支，不要基于“脏分支”拉代码。

3.2 多人协作，及时git pull; git push

多人一起合作完成功能时候，为了减少代码冲突，及时commit，及时提醒队友git pull，会减少不必要的merge。

3.3 小步快跑，一个功能点一个commit

当手头要做的东西很多，要记住：拆！

拆成一个一个功能点，每做完一个功能点，及时commit。每个commit都是一个完整的、小的点。不要在一个commit中包含多个功能，好处是：一步一步扎实的向前走，确保每个开发完成的就没有大问题，这样避免开发节奏混乱。

eg:

git commit -m "feat:首页配置-区域化LOGO";

git commit -m "feat:首页配置-区域化标题";

而不要一次性把这2个功能都开发完了一并提交。
~~git commit -m "feat:首页配置-区域化LOGO、区域化标题"（不推荐！）~~ 

3.4及时反馈遇到的技术问题、产品问题

很多问题再编写设计文档时候未必能够发现，经验表明，很多问题是在开发过程中发现的。

这个时候及时反馈，尤其涉及到影响开发进度、开发思路的问题，及时组织相关人员讨论。

3.5 及时准备SQL脚本

个人习惯是，开发对应的功能时候就顺手维护SQL脚本，而不是开发完毕一次性维护。

好处是：避免遗漏。

四、编码完成及自测

1）如果有精力，写单元测试最好。因为可重复执行；

2）没有时间的话，一定要自测，确保主流程Happy Pass

自测的质量直接决定提测的质量。这是对自己代码的负责，也是节省测试人员的时间。节省别人时间就是对别人工作的尊重。

五、提测

5.1 跑脚本

确保本次开发涉及到的相关脚本都已跑；

5.2 Jenkins部署服务

确保代码都入测试分支，jenkin部署不遗漏。

5.3 自我验证

部署完毕，不要觉得万事大吉，要去看看对应的功能是否如期出现，然后通知相关人员对接。

六、复盘

6.1 开发流程复盘

开发流程是否顺畅？

下次开发同样的功能？开发速度能否提升？实现方法能有哪些改进与优化？

6.2 技术难点复盘

技术难点在哪里？

6.3 沟通及管理复盘

跟产品、前端、测试、开发人员沟通是否顺畅？