程序员应该如何自我驱动，迅速获得成长？

已经一个月没有写增删改查了，我就有机会开始搞一些事情了。那个时候，我请我的领导去说动技术部使用Dubbo，因为它能做服务自动发现，免配置扩容服务，是一个挺流行的RPC框架。但是由于当时我们没有技术权限，这个事情是很难推动的，一切以稳定为主。

我使用过Dubbo，但是我一直不理解的是，为什么Dubbo使用了ZooKeeper就能自动扩容？就能服务自动发现？这个肯定和ZooKeeper有关系。由于我是刨根问底型的开发，因此我开始在周末时间和晚上和上下班路上自己学习ZooKeeper,什么顺序节点，永久节点，临时节点，什么树形存储，动态监听和通知。

终于，我就在没有看Dubbo源码的情况下突然恍然大悟：Dubbo的服务提供者和服务消费者都配置了服务name,如果我在ZooKeeper的一个name节点下存储服务路径集合，那么每次新增服务或者下线服务都会通知到任何监听这个name的客户端？（后来知道这叫做namespace命名服务），Dubbo肯定是使用了Zookeeper的命名服务来实现服务的动态发现的！

大部分程序员使用HttpClient都是使用的一个叫HttpHelper的工具类，我的改造就开始从HttpHelper这个工具类开始吧，让程序员传递自己的服务的ip,port,se rviceName,destinctName,zookeeperUrl，然后我在工具类里封装了获取调用路径列表，并封装了两个负载均衡算法：ip_hash,随机数。（其实我只会写这两种）。

在公司的四次迭代里，他们在一边飞速业务开发，一边逐渐把自己的HttpHelper工具类替换给我写的这个，终于可以卸下slb，实现简单的HTTP服务动态发现了。

当时的反对声音其实还是挺大的，不过运维的需求呼声更高，配置URL太麻烦了！

那个时候，公司架构重组，得领导赏识，我被重新划分到了技术部，做了基础平台研发部门的Team Leader，管理几个程序员。

痛点二：缺乏配置中心

解决了第一个痛点以后，我一边写增删改查，一边又想解决第二个痛点：配置问题。

之前每次部署程序到线上时，每次都要一个服务器一个服务器的改配置，我就想，我把我的时间浪费在这种一个服务器一个服务器改配置的事情上，真的是不甘心。

而且这么改配置，还容易出错。虽然公司没有主动要求写什么。（公司的主要眼睛还是放在了实现功能和业务上）那个时候加班没有那么狠了，程序员写完增删改查就回家了，我还在想配置中心怎么实现。那个时候微服务的概念火热，我了解到了Spring-cloud-config。知道有叫做配置中心的这种东东，对，我们也需要配置中心，把配置集中抽出来管理。由于我已经掌握了ZooKeeper，自然知道了做配置中心的思路。

半个月时间我就写完了，时间主要浪费在了写页面上。（汗，作为一个后台程序员我承认我的页面能力比较差）当然，这期间也经过了一些改版。我竟然不知道ZooKeeper有Curator这么好用的客户端，之前一直使用的原生的org.apache.zookeeper这个原生客户端操作，监听消费以后还要重新监听。

配置中心写完以后，我也在一个周末发到了群里，并推广了出去。这次，由于公司的人员团结力已经大有改观，而且我也已经是组内Team Leader，先在组内普及了。

而且我这次组外的游说和推广也没有那么困难了，最终也都一个服务一个服务的落地了配置中心，并实现了一处改动，处处生效，也实现了传说中的配置热更新。这些，并没有什么高深的技术，仅仅就是依赖了一个ZooKeeper。

弄完这些，我已经感受到了做技术的乐趣，同时，我的领导也觉得好像让我写增删改查有点浪费，要求我把我手头的任务全部分给组员，自己则是去解决别人的问题......我赢得了更多的时间去自我驱动，改善公司的基础设置。

痛点三：缺乏缓存框架

接下来我本以为自己要没事做了，但是，得益于左耳听风的一个专栏，他说，描述一个业务（DSL），要比编写一个业务更具有维护性，公司很多的人都在使用Redis缓存，但是，用的库各不一样，还经常出各种奇怪的问题，调试起来及其繁琐。

当然，最终让我受不了开始决定写缓存框架的是因为我看到了我的组员写的代码与业务严重耦合，一会操作Redis，一会操作数据库。我发现了这个痛点，研究了一下Spring的AOP和他的@Transtional 注解如何实现以后，终于决定手写一个微型的缓存框架。基础思路就是通过可插拔的@CacheEnable（key=xxxx,timeout=xxx......）实现Redis缓存，完全不侵入业务代码。如果不用了，把注解在方法上移除了就好了。

手写这个Redis缓存框架使用了半个月，毕竟自己的技术能力还是有限，如何实现AOP和Spring集成，怎么抽象等等，都会让我每天都思考半天才下笔，甚至有时候一天写不了一行代码。

期间看了一本叫做《面向对象编程》的书籍，里面说，面向接口编程，依赖抽象，而不是依赖具体的实现......我突然就像打通了任督二脉。我在CacheHandler里面依赖了CacheStorage接口,而把RedisCacheStorage作为一个实现类注入了进去，因此，后来我这个框架可以同时支持redis,memcache,local。

写完这个框架以后，我总结了三个可抽象的点：

1. 序列化方式（jdk,protobuf,thift,json）

2. 脚本解析器方式（就是解析key的方式：比如，可以使用spel或者ognl："userId"+#user.id ）

3. 缓存实现方式（redis,memcache）。

后来我从刘大的码农翻身公众号的一篇将日志系统的设计里知道了正交一词，大概这就是正交吧。最尴尬的是，原来Spring早就实现了，叫做SpringCache。汗。

(码农翻身注：那篇文章叫做《一个著名的日志系统是怎么设计的》)

后来的事情，我也不详细的讲了，大概就是从私有框架，换成了公共成熟的库，我们也终于用上了Dubbo框架。

而对我自己本身，我只是更加理解了一些之前无法理解的事情：Dubbo为什么能改一个组件的配置那个组件就换了一种实现。（面向接口编程）看Mybatis的源码也没那么困难了，两年前完全下不去手。当然，我也变得更加热爱技术了。

我的心得体会

那就给大家分享一下我近两年来的心得体会。

1.  作为一个程序员，一定要懂得自我挖掘，而不是仅仅实现业务功能就好了，也不能干等着领导分配任务。

功能耦合了，写代码慢了，运维麻烦了，这些，都是潜在的需求，我们现在的加班，是为了以后不加班，是为了提高自己的效率，是为了不能原地踏步。

2. 一定要真正地学会一个技术，我在实际工作中，发现有的同学使用了一年的Git，竟然不知道如何把GitHub的项目拉取到本地，但是他会把GitLib的项目拉取到本地。

程序启动异常，有同学从网上找了一个jar包导入到了工程里，但是问他为什么把jar包导入到工程里代码就启动正常了，竟然不知道。

有的同学使用了一年的Maven，不知道mvn compile 是什么含义，只知道mvn package是打包。

这些，就是没有真正的学会了一个技术，仅仅是工作时机械式的使用了，仅仅是复制粘贴了，下一个项目再复制粘贴过来就行了，模仿着别人的代码写逻辑，这是学不到东西的。

我觉得，你一定会有时间去学习这些东西，网上大把大包的资料和教程。一定要知其然而知其所以然，一定不要一模一样的配置换了一种配置方式你就看不懂了。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!