开发前沟通清楚所有细节，包括和产品对需求的沟通、和后端开发对接口和数据格式的沟通。
这里特别要说的是和后端的沟通，最近好几次提测之后，才发现犯了一些因为和后端没沟通好字段导致的低级错误。比如今天的字段的值的问题，本来为空时需求要求前端渲染显示‘／’，而后端给前端返回的是null。后端也没有事先给前端说这个null就代表要显示的‘／’，当我看到后端返回的null的时候，以为除了‘／’以外还会显示另外一种情况——什么都不显示（这里我脑子里疏忽了产品给的完善的原型图，原型图里面并没有体现页面上有空值的情况，只有显示数据值和‘／’的情况）。
开发前作为前端我没有事先去和后端沟通这个值的问题：后端会怎么处理这个‘／’值，是应该前端处理还是后端直接返回这个‘／’给前端渲染。然后就直接按照自己的思维惯性，以为后端会返回‘／’和null这两种情况去写了逻辑。
我总是以为这种数据就应该后端弄好需要的格式直接返回给前端就好，这是后端的责任。当我知道后端使用的go语言对类型要求很严格，不像js这种弱语言，定义一个变量支持多种不同类型的值赋值，我才知道我这种按照以往经验来定义当下做的事情的思维方式是多么可怕。
做事之前的沟通确认一定是必走的一个环节，每一个实现的细节在做之前应该都是想清楚了逻辑的。后端在接口文档中没有详细的文档说明，给的mock数据格式和渲染需要的数据格式不一致时，停下来想一想，我想要的数据后端mock数据中怎么没给。做为前端一定要主动去和后端确认好接口的使用。
总之，开发前前后端一定要先沟通清楚接口的使用，确保两个人对接口的使用的理解是一致的，开发前解决掉这个问题可以减少5%的提测之后的bug量。还需要说的一点是，当后端更改开发语言的时候，前端如果对这门语言不了解也是有必要去简单了解一下的。
目前公司用的go语言不同于之前的php语言，前者属于静态强类型语言，后者属于动态弱类型语言；前者在编译阶段类型就已经确定了，而且定义的变量类型不能再切换，而后者属于动态类型弱类型语言，变量的类型在运行时确定，定义之后的变量还可以切换类型。这也就是为什么后端使用php开发的时候可以在给同一变量赋值不同类型的数据，而在go里面只能统一赋值一种类型的数据的原因。
