buguge - Keep it simple,stupid

知识就是力量,但更重要的,是运用知识的能力why buguge?

导航

< 2025年2月 >
26 27 28 29 30 31 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 1
2 3 4 5 6 7 8

统计

【研发笔记20251114】技术自信 & 不因纠结于细节而放弃本该做的事情

 

回到顶部

技术自信

我们要拥有技术自信!

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

我们习惯了代码有改动,就提测给测试团队来进行测试验证。

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

例如:重命名一个底层工具类的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,再去尝试异步将交易变更为“付款成功”。

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

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

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

posted on   buguge  阅读(18)  评论(0编辑  收藏  举报

相关博文:
阅读排行:
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 推荐几款开源且免费的 .NET MAUI 组件库
· 实操Deepseek接入个人知识库
· 易语言 —— 开山篇
· 【全网最全教程】使用最强DeepSeekR1+联网的火山引擎,没有生成长度限制,DeepSeek本体
历史上的今天:
2016-01-14 http流请求时,被请求站点HttpContext.Current为null?
点击右上角即可分享
微信分享提示