从零开始搞基建（2）——团队协做规范

      前端会与公司的全部部门有协做，若在某一环出现问题，就会发生没必要要的时间开销，下降开发效率。因此有必要制订一套完善的协做流程。

      有个核心要素，那就是积极主动性。

1、与业务方的协做

1）BUG上报

      业务方包括运营、客服、财务等部门，在使用软件时不免会遇到这样那样的问题。

      若要上报这些BUG，则须要提供页面地址、问题描述、截图和机型，若是能够提供录像的话，那最好了。

      还能够提供一些其余线索，诸如谁谁谁以前处理过该类问题，线索越多，定位问题的速度越快。

      注意，页面地址是必填项，有了地址前端这边才能准确的定位到问题和相关责任人。

2）业务需求

      在提出业务需求后，须要提供一些基础保障，帮助研发或测试，例如开通海外PayPal支付，须要提供测试用的海外帐号。

      实时更改需求池任务的状态，没必要特意去通知业务方需求已上线。

3）维护

　　当有重要活动或业务上线时，需携带公司笔记本回去，及时修复线上问题。

　　通常状况下，若出现线上问题，先定位问题出现的位置，而后重启相关服务便可。

2、与设计的协做

1）定稿

      设计至少应在开发开始时敲定终稿，后面修改最多只作微调。

2）交互

      设计想要的交互动画，能够制做成一段 mp4 视频给到前端。

      而且前端会提出可能存在的问题（技术实现问题、性能问题等），协商解决方案（如优雅退化）并达成共识。

3）核对

      前端拿到设计稿后，与产品文档比对，当与产品原型不符时，要主动找产品和设计核对。

      当前端收到新的设计稿与原先提供的有差别时，需主动与产品沟通。

4）验收

      在完成页面的开发后，让设计确认验收，可在工做群中@相关人员，让他们确认回复。

3、与产品的协做

1）产品文档

      产品应在文档中补全设计搞（上传设计稿图像或加个蓝湖地址），如有修改，则最好标明修改的位置，好让前端和测试作验收。

      产品在设计产品文档时，得保证相关流程的完整性，例如新增一个支付渠道，那么就得把后台管理界面也写到文档中。防止在开发过程当中临时加需求，打乱总体节奏。

      前端必须仔细阅读产品文档，力求理解业务需求，杜绝因为需求模糊而发生的反复修改。

2）肯定开发人员

      在正式开发前，产品须要确认相关功能由哪一端完成，这部分主要涉及的是前端和客户端，以避免在开发时临时修改技术方案。

3）核对

      当文案发现有差别时，需主动与利益相关方核对，例如测试、产品、设计等。

4）权限

      新功能提测与上线后，前端主动给相关人员开权限，不要再次提醒。

5）预估时间

      根据项目时间要求及工做量，预估时间，精确到小时，在完成预估后主动提供给产品。

      当须要预估提测时间时，最好将平时救火的时间也考虑进去，时间不要估的太紧。

4、与服务端的协做

1）接口文档

      在开发伊始，就得先定好接口说明，既能够是规范的文档，也能够是JSON文件，只要能说明字段便可。

      不要出现谁等谁的状况，这样既费时又耗感情。

2）技术细节

      在须要互相协做时，须要先明确各个技术点，尽可能作到在正式开发前就对好技术细节，避免返工。

　　在与其余组沟通细节以前，须要本身了解清楚当前的产品需求，以及当前的系统状况。

　　他们推荐的方案能够做为资料参考，但切记不要被他们影响本身的思路，咱们要按本身的实际状况给出最适合的方案。

　　务必要将技术细节确认好，即便是一个数据库表的字段也要核对好，不要有歧义。

3）建表

　　在建表以前，须要先和服务端沟通清楚，从新建表合适，仍是在原表上新增字段合适。

　　在初步沟通完成后，最好再看看当前数据库中是否有类似功能的表，由于服务端的人颇有可能刚接手，并不了解当前的数据库。

5、与测试的协做

1）测试用例

      在需求确认后的两天，测试整理出测试用例，开发在完成页面后，主动执行部分测试用例，减小没必要要的纠缠时间。

      若某个用例的执行成本较高，则略过，例如须要造不少复杂的数据。

      一般测试用例会包含许多功能点，但至少要将核心流程的功能点跑一下。

2）结对编程

      将代码的大体逻辑讲解给测试听一下，作次简单的结对编程，这么作可发现一些开发忽略的潜在问题。