抄代码，是一个国际习俗。
学习 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吧。
毕竟能直接拿来用在生产的，何乐而不抄呢？难道你不想六点下班？
作为开发者，我们需要保持好奇心和学习热情，不断探索新的技术，只有这样，我们才能在这个快速发展的时代中立于不败之地。介绍一款程序员都应该知道的软件JNPF快速开发平台，很多人都尝试用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。
JNPF可以实现应用从创建、配置、开发、测试到发布、运维、升级等完整生命周期的管理。减少了传统应用程序的代码编写量，通过图形化、可视化的界面，以拖放组件的方式，即可快速生成应用程序的产品，大幅降低了开发企业管理类软件的难度。
当然，我更建议大家成为一个全栈，不要把自己的定位局限于前端。
感谢阅读本文
如果有什么建议，请在评论中让我知道。我很乐意改进。
