工作中如何Coding

当我接到一个开发任务的时候，我不是第一时间就去着手开发，我首先要干的是以下几件事情：

• 第一，看产品的文档，根据当前系统的功能，评估下产品的设计是否合理。不合适的地方，还要跟产品讨论，如果问题在刚开始的时候没有被发现，而是干着干着才发现这个问题，这就非常糟糕，这就需要平时经验的积累。一般是问题越早发现，解决的成本越低。

• 第二，分析这次开发的影响范围。如果都是新功能，新建数据库表等，这就无所谓了；但如果此次开发是基于原有代码的变更，就要注意影响范围了。比方说，这次版本变更会影响到的点有 3 点，但是如果你只修改了 2 点，剩下的一点就是 Bug。这是非常可怕的事情，在实际开发的时候一定要注意这个问题。那如果你是个新人，你并不知道系统有多少个地方需要修改的时候，那么你可以问下团队中对系统了解非常透彻的人，让他帮你确定系统变更范围。但是，这种事情还是少做，自己要在没有事情的时候多去熟悉系统，熟悉业务。

• 第三，确定影响范围后，要整理出一个文档。文档中要写明，系统变更版本，相关人员。此次变更的功能点。对于变更的功能点还要写明：

  • 变更背景（为什么这个变更？）
  • 变更的 log，原来是什么样的，现在变更成什么样子的

• 第四，前后端合作沟通，确定完成这些需求需要多少个接口。前后端沟通的时候，最好也要注意接口定义的几个问题：

  • 返回数据格式，都返回哪些字段
  • 请求方法，Get, Post 等
  • 出错处理

• 第五，测试开发的功能。写测试 case, 按 case 来做相关的测试。测试的一般顺序是，自己开发的功能自己测一遍，然后团队成员测，如果没问题，发生产环境。否则，修改代码，本地测试，测试环境测试功能，如果还有问题，重复以上步骤，直至功能发线上环境。

• 第六，提交代码时要注意的问题。两个后端或者两个前端或几个全站一起工作的时候，在本地编译没问题后才能提交代码，你不能提完代码，大家本地都运行不了了，这不行。

• 第七，提交信息如何填写。这里推荐一篇阮一峰老师的文章《Commit message 和 Change log 编写指南》。

本次分享就到这里啦~