与产品经理和经验丰富的测试人员多沟通
需求阶段
产品经理正式开需求会议之前，一般都会先把需求文档发出来，这个时候，开发人员一定要认真的看并仔细分析，每个细节都要多想想，有疑问的地方及时跟产品经理沟通。另外，看需求的时候，最好跟熟悉业务的测试人员多多沟通，测试人员是对以往需求最清楚的人，能看到其他人看不到的细节。像我自己就经常从测试人员那里，听到了一些要命的而我却忽略掉的需求细节。
代码设计阶段
我一般想好方案后，第一时间就会去找技术老大和熟悉业务的测试人员。能做到技术老大，他的思路一般都是比较广的，多听听他的意见是没错的。另外，也要去找测试人员，有些开发可能认为，技术方案怎么会去找测试人员商量呢？请不要忘记，部分测试人员是对整个公司的大部分应用和需求和业务都了如指掌的人，能清楚的知道系统与系统之间如何交互，整个链路是怎么走的，整个上下文又是怎么样的。当开发人员的设计方案出来后，表面上看起来，完美无瑕，其实可能存在影响上下游系统的隐患。而多与熟悉业务的测试人员沟通，则可以尽早把这些问题暴露出来，减少影响和损失。
代码开发阶段
必须写单元测试
单元测试的重要性，无论怎么强调都不为过。它是用于测试自己写的代码是否符合预期的极好的手段。尤其是在创业公司，需求都非常多，经常需要改代码，如果没有一套完整的单元测试来回归验证代码，分分钟由于新写了代码而破坏了原有的代码功能。单元测试可以让开发人员放心大胆的改代码，无需担心影响之前的功能。
但是单元测试一定要认真负责的写，尽量覆盖主流程业务。那种随便写写，随便验证的单元测试，不写也罢，没啥意义，还浪费时间。
另外有一个点就是，开发人员提测后，理论上就可以接另外一个开发任务了，如果开发阶段BUG太多的话，则会影响下一个开发任务的进度。这个是开发经理不愿意看到的。
不断的重复的看自己的代码
代码提测前，要多看几次，有时候能看出一些隐藏的代码BUG的，有时候也会觉得，昨天写的代码，真垃圾，还是有蛮多代码要优化的。
在看代码的时候，最好顺便做到下面几点：
代码收拢性要强，不要存在那种类似的代码满天飞，能封装起来的就封装；
业务代码一定要有必要的准确的注释，千万别信那套方法名命名好了就能解释清楚的鬼话；
变量名要起好；
代码抽象层次要一致，不要跳跃，例如，你的业务方法，操作其他模块业务表的时候，都是调用Service类的，就不要突然冒出个直接使用xxxxxMapper去操作数据库表了；
流程性比较强，最好用 //1、 //2、 //3、 标注一下，这样会更加清晰。
必须做开发联调
当你的业务接口开发完成后，一定要做开发者之间的联调。联调是端对端的，就算其中一方做的再好，没有联调，还是会出问题。
开发联调通过后，建议叫产品过来提前验收
一般来说，功能测试通过后，上线前，会让产品先验收一下。但是我则喜欢开发联调完后，就先拉上产品经理，先大概验收一下。不要小看这一步，经常能提早发现一些问题的。
测试人员测试阶段-看日志
不要以为提测后，就没自己啥事了，最好还是抽少许时间，去测试机器上看看日志，观察和分析一下入参和出参等，看看有没有什么异常或者不合理的数据。
原文链接：https://blog.csdn.net/linsongbin1/article/details/84813468