为何我建议你学会“抄”代码？

抄代码，是一个国际习俗。

学习 Java 8年了，我一直坚定不移地“抄”代码：

• 
  
  
  “抄”同事
  


• 
  
  
  “抄”框架
  


• 
  
  
  “抄”GPT
  

有黑子会问，你天天自吹技术专家了，天天就知道抄？对此，我只想说，是的，咋滴？

初级程序员和高级程序员最大的区别在哪里？：

1 为啥就知道抄？

“抄”，听起来让人不舒服？技术人嘛，咋能叫抄呢，应该叫：造轮子。不过似乎也被诟病，大佬们肯定劝你：年轻人不要重复造轮子，你的一切发明不过是发现！

首先，造轮子是你面前已经有一个轮子了。即你有现成可模仿对象，而且这个轮子一般出奇地圆，圆到你觉得它很美。这有助于提高你的代码品味。

其次，造轮子并不简单，它往往会用到很多高级的知识点和技巧。以Java为例，如果你要造一个[Mini-MyBatis-Plus]，你起码要懂：

• 
  
  
  JDBC
  


• 
  
  
  反射
  


• 
  
  
  泛型
  


• 
  
  
  注解
  


• 
  
  
  动态代理
  


• 
  
  
  函数式编程
  


• 
  
  
  策略模式
  


• 
  
  
  模板方法模式
  


• 
  
  
  ....
  

为了造这样一个稍微像样点的轮子，你必须强迫自己搞懂这些高级知识点，并且结合自己的需求灵活运用。

最后，轮子造完跑起来以后，一定会遇到各种问题，解决问题的过程中你又得到成长。

抄袭是有点儿可耻，但其实是鼓励刻意练习，学习优秀的代码并模仿，找机会把它用到生产。提高编码能力，就是干到生产。

2 咋抄？

绝大部分程序员的绝大部分时候都在抄别人的代码，只不过潜意识觉得自己在原创。咋“抄”才有效呢？结合实际需求，做好“本地化”。来看案例。

3 造轮子标准流程

3.1 发现问题

某日发现项目有接口不稳定，时不时就调用失败。排查发现调用一个云厂商的SDK，但接口不稳定，偶尔网络错误。简单，直接for循环多调用几次：

正当我准备改代码，职业习惯促使我全局搜下项目，发现已有好几处类似重试代码段。

是时候重构做个工具方法抽取了。

3.2 整理需求

但把好几处类似代码摆在一起对比：

• 
  
  
  有些方法有返回值、有些方法没有返回值
  


• 
  
  
  有些方法抛异常时重试
  


• 
  
  
  有些方法内部捕获异常，通过判断Result.isSuccess()判断是否重试
  

唉算了，看有没有现成完善框架吧：

果然，依旧是救世主 Spring！

但一看，这么复杂，杀鸡焉用牛刀？还是再封装一个吧！

3.3 粗糙版

首先，确定要用函数式接口+[泛型]。使用泛型是看重其代码模板能力，如重试代码中都有for循环，就可抽取为模板。[函数式接口]可很方便地把代码中变化的部分和稳定的部分剥离开，如需要重试的方法都是不同的，可以通过函数式接口剥离出去：

兼容下没有返回值的处理：

再继续不断完善。

3.4 +重试次数、时间间隔

一旦失败立即重试，很大概率还是失败，给下游造成更大负担。看其它大佬咋处理的，如Guava：

不错，一看就懂，抄之：

3.5 +异常处理

最后一次重试仍旧失败时，还想捕获异常呢？由于目前工具直接写死[throw e]，只能在外捕获：

优化下，使其优雅一点点，风格统一一点点：

在里面顺便处理异常

3.6 +结果重试

最后一个问题，现在代码里很多重试的地方并不会[抛异常]，而我们上面的重试都是依赖于抛异常，只有抛异常才会重试！如不抛异常，咋指定[重试规则]？

学Guava：

继续“抄”（结果重试只针对有返回值的，上面演示的都是无返回值的方法）：

3.7 +Builder模式

简化使用。一个Util能做的，原则上不需要Builder额外创建对象浪费内存。但上面这方法参数太多！

改造成Builder：

4 总结

以上这些过程，你想清楚了，作为一个 SOP，以后就能指示 GPT 去写好一个轮子了，当然最快的还是用别人造好的现成轮子吧！虽然经历这么多，你个人的确对如何使用各种高级语法和造轮子有一些实际经验了。

再回首，一开始搜到的Spring Retry太复杂了，但Guava就蛮好用，生产还是直接用Guava吧。

毕竟能直接拿来用在生产的，何乐而不抄呢？难道你不想六点下班？