本文纯粹个人意见，有些偏执，不喜勿喷~
owner意识
首先要在意识上理正，代码是你写的，你要为你写的代码负责，质量不好都是代码编写者的问题，没有借口。是QA同学没有测到位？是相关信息没有同步给你？是需求沟通不明确？是时间太紧张？拉倒吧……就是没有担当！
bug是无法杜绝的
这是典型的给自己开脱的借口，打印“Hello world”到控制台，为啥可以做到没有bug？因为这个逻辑简单？而你要实现的逻辑复杂？呵呵...
理清业务
要实现的这块功能逻辑到底是什么样子的，会影响哪些，会被哪些影响，依赖的系统可能出现什么异常，用户或上层代码可能会怎么使用，先把正常行为走通，很多情况都是因为业务都没有理清就去编码，不出问题才怪
异常处理
这个是有个度的，需要衡量折中，二八原则，搞定常见的异常情况就可以了，用户一辈子都不会走的异常路径，不搞问题也不大。当然，安全问题要足够重视，已知安全问题必须全部修复，安全无小事
自测落地
不要因为后面的流程中有QA帮忙测试就懈怠了自测。线上出bug，丢人的还是你。告诉你个消息，有些公司，其实是没有QA这个岗位的。
关于单测
有些人一提自测，就来单测覆盖率云云，不得不承认，TDD的方法编写代码，单测确实必不可少，但，这只是通往罗马的其中一条路，不是只有这一条路。
所以，衡量质量，单测覆盖率个人觉得不重要，重要的是QA给你测出多少bug，上线之后用户帮你测出多少bug，一个单测不写，QA和用户都没有测出问题，那你就是牛逼，单测覆盖率90%，用户还是用出各种问题，这个单测写的就是浪费时间，请用结果衡量。
实话讲，个人是不写单测的，因为写单测太慢，测试的范围太窄，直接测业务逻辑，只要业务逻辑OK，从前到后说明都没问题，效率高得多
网友评论