技术自信

我们要拥有技术自信！

我们许多同学，是缺乏技术自信的。

我们习惯了代码有改动，就提测给测试组的同学来进行测试验证。

虽说有测试组，但有些开发改动，我们开发者，凭借我们的专业能力（技术能力），可以自己确信没有问题，可以不用一律提测。

例如：重命名一个底层工具类的public static方法，这会涉及到上层的项目跟着发生变更。对于这种重构来说，只要IDE可以compile通过，就没有必要走测试流程。IDE没理由compile不通过的，除非你不熟悉IDE的rename这个refactor操作。

再例如：某个Service类中的一个私有的读取数据的方法，我们变更查数据库由selectList然后返回第一条，改为等效的selectOne加limit 1的方式。这种情况，我们只需要保证junit单元测试可以正常验证通过，就不需要让测试同学去测试所有受影响的业务功能了。

类似此类的小改动，所依据的都是我们的编程技术，并未涉及业务逻辑方面的改动，我们应该是而且必须是可以hold住的。提测只会增加测试同学的工作量，于团队效能来讲，也是一种浪费。

拥有技术自信有什么好处？

技术自信会推动自己更深入、全面地了解技术，编写高质量的代码。编写高质量的代码，bug就会少，会进一步提升自己的技术自信。所以，这是一个良性循环的过程。长期处在这样的cycle里，自己会快速成长。

该做的事情，不因纠结细节而不做

外放接口要对请求参数中的用户手机号做一下兼容，将“08618812345678”中开头的086去掉，即改为“18812345678”。开发同学很快改完。

//将手机号以086开头的国际区号去掉
if(StringUtils.isNotBlank(vo.getMobile())){
    vo.setMobile(vo.getMobile().replaceFirst("^0861", "1"));

代码评审人给出了一条建议：可以一并兼容一下“86”、“0086”、”+86“开头的情况。

开发同学不太认同，言说请求方后续会修改他们的调用代码，不会再出现类似的情况了。如果兼容这些，代码会显得臃肿，并借口“程序执行会慢，影响最终RT”。

外放的这个接口，不止一个请求方在调用。因此，谁又能保证未来不会有类似的请求数据呢。

所以，兼容一下，是有道理的。至于说影响RT，就有些扯远了。

其实，代码评审人明白，开发者是认同一并兼容的，只不过他不愿意写下面这种臃肿的代码，这是他反对修改的真正理由。

if(StringUtils.isNotBlank(vo.getMobile())){
    vo.setMobile(vo.getMobile().replaceFirst("^0861", "1"));
    vo.setMobile(vo.getMobile().replaceFirst("^861", "1"));
    vo.setMobile(vo.getMobile().replaceFirst("^00861", "1"));
    vo.setMobile(vo.getMobile().replaceFirst("^\\+861", "1"));

代码评审人提供的代码是：

if(StringUtils.isNotBlank(vo.getMobile())){
    vo.setMobile(vo.getMobile().replaceFirst("^861|^\\+861|^0861|^00861", "1"));

至此，开发者不再认为臃肿，也欣然接受了。

再举一例。

我们对接的支付宝付款接口，偶尔会出现的一种情况是，异步回调 先于 同步响应。这种情况出现时，我们的回调处理逻辑，会因为违反状态机幂等而没能将交易变更为“付款成功”。

为了最大程序满足付款时效，针对这种情况，我提出了优化方案：当这种情况发生时，则延迟3s~5s，再去尝试异步将交易变更为“付款成功”。

我们的开发者在做这个优化时，改动了几版，总觉得代码不优雅。后来产生了放弃优化的念头，并认为这提高了代码复杂性且收益太小。

我们进一步沟通后，开发者最终完成了这项优化。

【结论】搞清楚要解决的问题。不要因为某个细节的纠结，而错误地认为要解决的问题没有意义。唐僧西游取经，假若唐僧留在了女儿国，可就是唐僧的问题了。