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

我发了一篇《工作没有挑战性，怎么办？》， echo_陈同学的留言讲述了自己的故事，我觉得他的经历比我那“说教”有意义得多，邀请他拓展了一下，写了一篇文章出来。

大家可以看一下，他是怎么发现痛点问题，解决痛点问题的。  在一年多的时间内，他做了多少事情！取得了多么大的成长！人和人的差距就是这么产生的。

长文预警，碎片化时代，专注和深度思考是稀缺品质，建议耐心阅读，不要错过！

初入公司，从CRUD到运维支持

一年之前，我还是一个只会CRUD的普通程序员，常年与业务打交道，一套花式SSM框架三板斧从头玩到底。

我入职了一个初创型的互联网项目团队，在迅速融入工作环境以后，我就开始上手写起了CRUD代码。虽然不知道底层原理， 但是SSM模版代码已经烂熟于心，再加上有一些在以前工作时学习到的基础和避坑的经验，比如空值验证，防止重复提交等， 让我能够比较快地完成业务代码。

领导看到了这一点，把我安排到了运维支持部，开始让我干一些运维的活（公司在初创期用人是有这个特点）。 那个时候，开始逐个上线一个一个的服务。这是我从零开始了解公司技术现状的开端，也是一个加班到死的开端。其实加班的原因我是非常理解的，这个和公司的技术现状是离不开的，且听我慢慢道来。

艰难的系统部署：了解技术全貌

在一个晚上，领导拿了一份文档，列了一系列要上线的服务和服务要部署在的服务器，然后我们就逐渐开干了。

新服务器都是极为纯净的，连一些基础命令都没有，只好慢慢学，慢慢装。yum install xxxx，run xxx , ps aux|grep,telnet ....，一天过去了，什么jdk，tomcat，全都装好了。

（ps. 做运维这段时间最大的收获就是linux命令玩得很熟练。）

把服务部署后，启动时就遇上了难题：以前的服务是打war包放到tomcat的，但是现在的服务，需要java -jar 来启动。 尝试了可以后台启动的nohup java -jar ， 直接翻车。 无奈去询问之前的开发，人家说得用screen 命令后台启动程序。我是一个刨根问底的人，后来发现，开发在为了保持进程不退出，错误的使用了监听控制台事件的方式，导致了nohup启动异常。

那个时候，正在搞核心业务开发的人因为一直忙于开发和调试，和我们的沟通少之又少；而负责部署的我们，又不了解业务，有些问题当时的开发也懒得详细解释，于是我们只能靠猜，来部署程序。

混乱的程度可见一斑， 但这不是几个程序员所能左右的。

我在那个时候学习到的第一件事就是：在信息不足和沟通受限的时候，你要尝试学会必要的自行推理，根据已有信息的上下文来补全缺少的信息。

上线要紧，暂时就screen启动程序吧。但是程序启动以后，又遇到了更加尴尬的事情。

当时服务之间的调用方式，全部都是通过HttpClient直接调用目标服务。假如，我先启动A服务，A服务依赖B服务，B服务没启动，A服务初始化时会报错。那么，到底先启动谁后启动谁成了一个棘手的问题。

我查看了每一个服务的工程配置示例，发现每一个服务的config.properties，都有一个配置为root的选项，标识该服务的发布路径，例如，用户服务，他的config.properties 会配置 root=http://zhuanlan.51cto.com/userservice/ ，我就知道了，调用该服务肯定是这样的http路径：:port/userservice/xxxx。config.properties中，也会有一些带有如下特征的配置 reference_user=http://ip:port/userservice/xxxx。我很自然的明白了，这肯定是配置了该服务依赖的其他服务的调用地址。因此，我就想到，我可以根据每一个服务的配置文件理顺服务之间的调用关系。

为了确保我的猜想是正确的，我用网上的工具反编译了一个工程，发现，果然原来服务之间都是通过HttpClient调用的。

然后我就画了工程依赖图，仔细抽丝剥茧的梳理出来了程序的具体的依赖关系。最后，我终于对服务的部署顺序和方式有了思路，而有些程序员，私下已经有人开始说干不下去了要离职。

怎么部署终于明白了，可是紧接着的一个尴尬的问题就是，程序都启动了，也调通了，但是领导要求负载均衡，集群化，一个服务里直接调用另外一个服务使用了HttpClient直连的方式，怎么搞负载均衡？怎么搞？怎么集群？