最近个人的开源项目retrofit-spring-boot-starter突破一百star了，我非常地开心。也许对于各位技术大佬来说，一百star完全微不足道，但对于还是“铁憨憨”的我来说，真的很不容易。乘着现在印象比较深刻，详细总结一下整个过程。
star数量在整个lianjiatech仓库排名第四，Java项目排第二。具体可以查看https://github.com/LianjiaTech。
我有代码强迫症
相信很多小伙伴跟我一样，对代码都有一定的“强迫症”。碰到实现上不够好或者使用上不够方便的代码，总想好好封装一下。这样不仅能锻炼自己的抽象设计能力，更能显著地提升研发效率，一举两得。时间回到2019年4月份，当时我们系统是一个spring-boot框架项目，项目中存在大量的http接口调用，但是调用的方式都是直接在业务方法里面使用类似HttpUtil发起的。这种实现方式，不仅丧失了框架层面灵活扩展的可能性，更是完全背离了面向对象的设计原则。作为一向有代码强迫症的我来说，忍不住就想对它下手了。
当然，光有想法是不够的，更重要的是如何实践。我当时做的第一件事情就是想清楚自己最终想达成的目标，正所谓“以终为始”，先想清楚目标，再去努力实现。这里，我联想到了mybatis框架可以直接通过接口执行sql。实际上，不管是执行sql还是发起http请求，本质上都是一种数据交互形式，因此我最终定的目标就是支持spring-boot项目通过接口发起http请求。接下来第二件事就是代码实现了，我没有上来直接撸代码，而是先去调研了一下相关的开源实现，毕竟站在巨人的肩膀上才能看得更远。经过一番调研之后，最终有2个项目在我的考虑范围之内，第一个是Feign，另一个是Retrofit，它们都支持通过接口发起http请求。考虑到Feign是spring cloud中消费端的调用框架，而我们的项目当时并不是spring cloud项目，由于不想引入spring cloud相关依赖，因此放弃了Feign。而Retrofit是基于okhttp封装的http客户端工具，使用同样非常广泛，因此最终选用了Retrofit。
理想很丰满，现实很骨感。retrofit官方并没有提供与spring-boot项目快速整合的starter，这使得我不得不自己将其与spring-boot项目进行整合。实际上，我做的最初版就是做了一个整合，并且也达到过基本可用的状态。如果故事止步于此，这件事我也就做到了勉强60分甚至是不及格的水准。对代码不将就，追求极致才是我们该有的态度，因此我萌生了一个更加大胆的想法，做一个开源项目，剥离业务代码，实现更加完整更加优雅的封装。
开源项目是一件很酷的事
在每一个程序猿心中，拥有一个开源项目是一件很酷的事，我当时想的就是把这件事做成。但是真正要动手去做的时候才发现，事情比想象中要复杂的多。因为开源项目最终是要给其他人用的，所以我对自己的代码设计和质量都有更加严格的要求。而当时不得不承认的一个事实是，我对相关框架源码的理解远远不够，换句话说就是我还不具备写一个开源项目的能力。这个时候，我要做的事情就是先死磕相关源码。经过3个多月的时间，我终于把retrofit、spring和mybatis框架的核心源码全部理解了一遍。看过源码的同学应该都知道，看源码的过程多少带有一些“煎熬”，但是认真啃完之后收获也会很大。
准备工作完成之后，就开始正式进入代码设计和实现了。此时，之前啃源码的效果就明显体现出来了，我在写代码的时候会自然而然地联想到开源框架的优秀实现，然后借鉴过来。这是一种很抽象的感觉，相信啃过源码的同学都有所体会。就这样，编码大概又花了2个月的时间，整个过程我都处在一个很兴奋的状态，记得那会睡觉的时候都在想怎么撸代码。由于这些工作都是业余时间进行的，因此这大半年时间里面，我的业余生活明显变得非常充实，现在回想起来，确实很累但很有收获。在此期间，我刚好也在做cms组件化框架的设计和实现，此时对spring框架的深入理解给了我非常大的帮助。到目前为止，cms已经是交易助手最复杂的业务，复杂度比交易助手其它所有业务加起来还要高，而cms组件化框架完美支持了相关业务的高效产出！
当一切准备就绪，接下来就是接受实际考验的时候了，我们当时替换了交易助手2个Java项目的http调用，并且通过自测就直接上线了，上线之后效果很好，没有出现任何异常。后来正式申请项目开源，整个过程比较漫长，大概花了4个月的时间，终于在2020年4月份审核通过。我记得当时刚好是清明节，我在github上正式发布了自己首个开源项目。不知不觉完成了目标，甚是欣慰。
突破百星
在接下来的2个月里面，我主要是做了一些功能上的迭代优化，github上的star数量依然少的可怜。在6月份的时候，我准备写2.0版本了。之所以要这么快写2.0版本，不是因为我们1.0写的有多烂，而是因为这段时间，我思想上出现了一些转变。之前写1.0的时候，我完全站在自己的视角去想项目应该支持哪些功能，兼容哪些框架，这诚然是我应该考虑的问题，但是好像偏离了方向，偏离了实际。我把实现做的复杂，仅仅是为了支持可能并不存在的需求。因此，在2.0的设计上，我做了大量简化，仅保留最重要最核心的功能，我觉得只有用户一下就能看懂你的设计，他们才会更有兴趣和更有安全感。最后，我还花了整整2天时间为2.0编写文档，这简直是一件不可思议的事情。
由于我这个时候已经开始写技术文章了，因此就在掘金上发了一篇介绍开源项目使用的文章。为了吸引眼球，我还特意取了一个很唬人的标题《spring-boot项目下最优雅的http客户端工具，用它就够了！》。没想到一下子就火了，马上就上了当天的热门推荐，还给我带来了30多个star。这对于平时都是“小透明”的我来说，真的是出乎意料。本来以为这件事两天就过去了，但是github上的star一直都在缓慢上涨，因此我特意使用搜索引擎查了一下，发现很多平台都有转载的文章出现，这一切也算合理了。直到8月11号，github上的star一早上就涨了11个，这对于我来说太反常了，后来才发现技术公众号大V@程序员DD(永辉云创架构师，《Spring Cloud微服务实战》作者，SpringCloud中文社区创始人，Spring4All社区联合发起人)和@Java知音转载了文章。不少网友在评论里面表示了支持和认可，当然也有一些质疑的声音，这里很感谢@程序员DD对我说的话，“没有最好，只有最合适，用心了！”，这也坚定了我持续进行迭代优化的信心。三天之后，开源项目顺利突破百星，为了庆祝，直属leader培麻麻还请全组的研发吃了顿饭。
 |
 |
|---|
总结
我其实只是做了一件很小的事情，唯一的区别是追求极致地去做好这件事情。在整个过程中，很感谢培麻麻的支持与鼓励，同时也为贝壳这种对技术包容和支持的技术氛围点赞。有时候我会想，如果当时做到60分就停止了，也许我不需要付出这么大的心力，但也不可能有这么大的成长。如果我们做的每件事，都只追求60分就行，那么即使做再多的事情，我们依然只有60分的水平。相反，如果我们做每件事的时候都追求做精做细，虽然会更累更难，但自身的能力也会得到锤炼和快速提升。正如Stanley所言，坚持长期主义，做难而正确的事情，写开源项目这件事，正是如此！
欢迎关注我的开源项目：一款适用于SpringBoot的轻量级HTTP调用框架