正经人谁写日记
这周想瞎扯淡一下，聊聊近一个月的事。
感觉自己近一个月充满了负能量，每天都在被各种Bug花样吊打，意识已经有点模糊了。
如果看过我前几篇文章的同学，可能就会知道我最近在整合系统。
有的同学可能不知道整合系统是什么样的概念，听着好像挺牛逼的，其实前期的工作无非就是拷贝代码到另一个应用下，启动起来，校验各个服务正常后，把另一个应用给下线掉。
这个过程中会遇到非常多的问题，在开发侧上可能最花时间的就是解决依赖冲突的问题。
应用A本身是一个独立的系统，应用D也是一个独立的系统，各自有的自己的依赖（环境）。有可能应用A是SpringBoot搭建的，而应用D是Spring搭建的，现在要把应用A合到应用D上。
三歪近一个月每天坐在工位上，就在排除各种的依赖。写bug、修bug 、写bug、修bug、写bug、修bug.....
“卧槽，这怎么又没启起来啊”
“这什么鬼啊，为什么说我的 group 没找到啊，明明有的啊”
"这牛逼啊，报错信息都没，就是启不来，这能怎么排查啊"
“求你了，赶紧给我发布成功吧。”
“靠，我这配置信息怎么没被读取到啊”
“完了，我绕不开这个Bug了”
“这怎么就返回302了啊，都请求到nginx了，怎么没打到接口上”
“我这个问题已经两天了，能不能帮我看看”
这段时间修了很多Bug，上线过几个Bug，也很可能“埋下”了许多Bug。
整合系统也快要结束了，回顾一下近一个月我的想法。
本来想吐槽一下自己为什么这么菜，能遇到这么多的Bug，解决起来还十分费劲，还有这么一大堆不懂的东西。
后来感觉这好像也没什么好写的，我这负能量也不应该再传达给别人。
还不如定个小目标，成为一个我自认为的”强者“应该要有什么样的能力。
想要成为一个强者
近一个月越来越发现自己还有很长的路要走。虽然毕业也快一年了，但总觉得自己就是一个废物，没有毕业一年该有的水平。
可能是身边的人实在是太强了吧。
如果我认为一个人很强，会有几个方面评估：
- 看到这个人写的代码很吊。真没想到还能这样封装，还能这样写代码。
- 看到这个人解决问题能力很强。基本有什么Bug去问他，很快就能有思路解决。
- 看到这个人对业务理解很深。在业务上会有自己的理解和见解，对别人的业务也能快速上手。
说白了就是编码能力、解决问题能力、业务能力。
编码能力
这次在整合系统和中间件相关迁移的时候又重新看了一下系统以及相关组件的代码。
发现我现在维护的整个系统以及相关组件几乎都是同一个人写的。
认认真真看了一下封装好的组件以及他的编码风格。
在最开始的时候会发自内心的感叹：”这人的代码有点东西啊“
再到后来：”这人怎么这么强阿“
再到后来：”我靠，看不懂了看不懂了，怎么这么多层抽象啊“
最后：”我感觉我再过一年也写不出这样的代码“
当我分享给隔壁的小伙伴的时候，他说：”这人是在中间件团队干过的吧？“
有的人的编码风格给人看起来就很舒服（虽然有的时候觉得有炫技的成分）。可能没碰过面，没聊过天，但一看代码就能知道写代码这人是真的有东西。
你还在写各种if else的时候，人家用Pipeline 模式将代码优化了一把
....
设计模式如果不了解它，可能在最开始看的时候不太好理解代码，会感觉绕来绕去的。了解它以后，发现维护起来是真的舒服啊！
解决问题的能力
前段时间在知乎看过一个问题，（具体记不太清了）类似的题目就是《程序员 要看这么多源码，这些时间要怎么合理分配呢，怎么才能成为Java专家》
看到不少的大佬在回答，其中我在里边看到了一个观点。
源码和技术都是看不完的，程序员更重要的是需要有解决问题的能力。
三歪个人是挺认同的。
为什么说公司喜欢招有经验的程序员，因为有经验的程序员往往会遇到各种的问题，这些问题都解决过后就会有自己的一套方法论去解决，或者可以给没遇到过的同事给分享当初的解决方案，这可以省下很多时间。
还是最近的经历为例，我这边要整合一个系统A到系统D，可能需要花费4天。而我组内的大佬，可能花两天就完成了。
那这时间的差距在哪？其实就是解决问题的能力和方法论上，总不能我单纯拷代码比人家拷代码要慢两天吧。
方法论
在前期迁移的时候，我是先把对外提供的RPC接口层先拷贝，然后该接口所涉及到的数据访问层再拷贝进去。
虽然代码是拷贝进去了，但启动项目的时候就很难受，会有一大堆没遇到过的问题（迁过去的服务层和数据访问层我都不知道有没有问题）。
我当时的想法是：可能有的接口是没用到的，那就不拷贝了。还在用的接口先拷，不在用的接口就不要了。这样我后期的改动就会少一点。
后来问了一下大佬是怎么做到这么快的，他说：”你可以先拷贝数据访问层，然后先启动起来，一层一层去搞，那就会快很多。在前期其实不建议动太多的代码，后续优化就好了。“
这么一想，的确也是。先搞掂数据访问层，等搞服务层的时候，如果出了问题，数据访问层就基本不用考虑了。
有经验的人会有自己的一套做事或者解决问题的”套路“。
基础能力
可能我遇到一个问题，然后要花1天才能准确定位到所在的问题在哪。但大佬遇到问题，很快就能理清这很是出现在什么地方，然后解决掉。
最近我司要把MQ上云，在切换的过程中，我启动项目后发现Consumer不消费了，是项目下的所有Consumer都不消费。
项目也能正常启动，就是Consumer不消费。看了日志，报了几句简单的错误，大致就说Consumer已经被shutdown了，拉取不到数据。
我排查了1天，也感觉自己没改过什么东西。我当时的想法是：Consumer和Consumer之间在我使用方的角度是隔离的，即便某个Consumer挂了，也不至于影响该应用下的所有Consumer。
我就一直在找是什么问题给造成的，一度怀疑是不是依赖冲突了（毕竟我这个月几乎都在解决各种的依赖问题）。
后来实在顶不住了，问了一下组内的大佬，给大佬讲了我现在遇到的问题，中间排查过的问题，以及自己认为是哪儿存在问题。
大佬听到后，就说：”你的Consumer 有shutdown吗？“
我说：”有啊，但业务上就是这样干的。shutdown应该不会有影响吧，即便shutdown有影响，那我其他topic的Consumer 应该也不会有影响呀。我一个Consumer一个实例的“
大佬就去看shutdown里边的实现过程了，过了一会告诉我说：”这shutdown 应该还有些问题，待会找MQ的负责人聊一下“
果真，最后还真的是shutdown处理导致的。
解决问题其实很考验程序员的水平：排依赖、快速理解代码、系统运转的整体流程（从请求到域名解析到proxy 代理再到本机nginx然后才到tomcat端口)等等、猜测某个功能是如何实现 等等。
有的时候你问他Git的使用，他就会告诉你如何使用Git。
有的时候你问他Maven是怎么选择某一个版本的，他就告诉你Maven的仲裁机制。
有的时候你问他数据是怎么流转，他就告诉你Storm、Flink这些是怎么实现的。
有的时候你问他SQL调优，他也懂
.....
业务能力
很可能大多数人都是做业务，业务能力在我看来也很重要。这决定了你所负责的系统跟别人的系统的差距在哪。
他们会拉各个公司的系统来跟自己的对比，看看自己的系统有哪些不足，再结合当下的环境把那些可行的功能给实现掉。在为公司创造价值的同时，自己也能得到成长。
我的Leader曾说过：”校验一个人的能力，就看他能不能把自己所负责的系统从零再搭建起来“
”假设你换了一家公司，没有现在这家公司的基础架构设施，能不能把你现在所负责的系统从零快速再搭起来“
反思
平时学学设计模式，写写文章什么的可还行，但真正去落地、把设计模式运用到实际的生产环境中，还是差得有点多。
发现自己基础解决问题的能力还有很多不足的地方，Maven的仲裁机制都是问同事的，Git回滚版本相关的使用也是问同事的....
没有对新的功能充分校验和测试，就把代码给上线了，这是非常不应该的。
在遇到线上问题的时候，没有保持冷静的思考和fix操作，导致排查问题的时间会延长。
....
时常怀疑自己是不是专门就是写Bug的。
时常担心以后把系统交接出去，接手系统的同事会在背后说我在代码里边下毒。
时常担心自己的改动影响到了线上的问题，然后出了大问题。每次发布后，如果内网有人找我，都要慌一慌。
大家 一起 奥利给！
各类知识点总结
下面的文章都有对应的原创精美PDF，在持续更新中，可以来找我催更~
- 92页的Mybatis
- 129页的多线程
- 141页的Servlet
- 158页的JSP
- 76页的集合
- 64页的JDBC
- 105页的数据结构和算法
- 142页的Spring
- 58页的过滤器和监听器
- 30页的HTTP
- 42页的SpringMVC
- Hibernate
- AJAX
- Redis
- ......
扫码或者微信搜Java3y 免费领取原创思维导图、精美PDF。在公众号回复「888」领取，PDF内容纯手打有任何不懂欢迎来问我。
原创电子书
原创思维导图
 |
|
我是三歪，一个想要变强的男人，感谢大家的在看收藏和转发，下期见。