毕业工作三年总结

毕业工作三年总结

我是2019年毕业的，到今天算起来也有三年了，这三年里干了很多的活，学了很多的技术，吃了很多的亏，踩了很多的坑。今天我就把自己三年的工作经历做个总结吧，写到那儿算那儿。

首先在2019年7月入职了西安华为技术有限公司，在云核心网产品线的一个负责微服务开发框架的部门里面工作。我自己在学校里面学过Java，并发、多线程、Web，基本都可以很好的使用。刚开始工作的时候呢，感觉自己技术知识还挺厉害的，啥都知道些，但是一接触工作中的实际软件项目就有点儿懵。

我刚入职的时候是有六个月试用期的，会有师傅带着完成学习任务以及项目任务。现在还记得刚入职的时候连Git和maven都不知道是啥，提交代码都要问半天才搞的定，记得当时我不知道一个技术问题，但是我师傅呢又比较忙碌，然后我就等啊等，等到快下班的时候，他忙完了，我才去问他，现在回想起来感觉好心酸，同时也感觉自己好菜。

所在项目组负责自研微服务框架。注册中心（ServiceCenter）采用Golang开发，是多实例无状态服务，数据都存储在ETCD数据库。这篇文章是自己工作三年的经历总结，就不详细描述技术细节了。

刚开始接触的项目并不是注册中心（ServiceCenter），而是服务治理服务（ServiceGovernance），一个纯Java项目，基于微服务框架提供的java sdk而开发的。刚接触的时候啥也不懂，代码层次稍微深一些就看不明白了，太多的函数跳转，跟着跟着就不知道自己看到哪儿去了。

机缘巧合的一次机会，一个大佬级别的老程序员来我们部门传授经验，然后他在整个讲话过程中强调了一件事情，四个大字——多看代码。他讲述了他的学习经历，刚毕业的时候部门主管让他去整理文档资料，然后他也是听从了组内老程序员的建议——多看代码，然后就不停的看代码，最后走上了编程修炼之路。当时人家还说了一个比喻：熟读唐诗三百首，不会作诗也会吟。我当时听见这句话还在小声的笑，后来证明这可是学习编程的王道啊。

后来我和小伙伴们也一起开始讨论怎么提升自己的编码能力，其中有个同事说他抄代码，然后我也就尝试了一下，我把代码函数调用简化成一行行的伪代码，但好像还是不太行，后来尝试画流程图和类图，但是我面对的是两三万行代码的工程，这种方法根本不适用。后来又看我师傅写的博客，采用了一种按主题阅读代码的方式，也就是将整个工程中关于一个主题的关键代码都聚合到一篇文章中，然后进行解释和阅读。我当时觉得这种方式挺好的，然后就采用了一段时间，感觉收获还是很多的。但是这种方式有个问题啊，那就是你得自己确定要阅读得主题。我当时由于没有经验，所以就在工程里面随机读，读到哪个模块就是模块，读到哪个主题就是哪个主题。

由于当时项目得代码量太大了，而且各个模块的代码质量参差不齐，所以采用上述方式阅读代码给我带来的提升不是很大，因为太耗费时间了，每天还得完成开发任务呢。现在回想起来，觉得应该先对项目代码有个整体的认识，至少画出一个大致的模块关系图，知道某个模块是干嘛的，知道整个服务工程完成的功能是什么，与其他服务的关系是什么，项目背景又是什么。先把这些整体层面的东西搞清楚了，再挑项目代码中关键的主题进行阅读。那么什么主题才是关键的呢？我认为承载服务核心功能、存在技术难点和承担项目架构核心部分的主题代码才是关键的。选好了值得阅读的主题，然后再深入项目代码中进行阅读，这也就是常说的“要带着目标和问题进行代码阅读”。

服务治理服务中有一个关键的业务逻辑是服务实例自愈流程，本质上是一个有限状态机，当时阅读那部分代码的时候也是差点把脑壳搞晕。现在想想，那部分代码确实写的非常复杂，各种条件跳转，根本记不清楚。但其实那部分代码就是在表达服务实例状态之间的转换，可以画一张状态转移图来理解。其实这儿还有一个问题啊，那部分代码逻辑复杂，但是没有太多的技术知识点。如果不用维护微服务实例状态转移的业务的话，其实阅读那部分代码是没有用的，即使画出来那个状态转移图也是没有多大意义的，只要知道那部分代码是在处理微服务实例状态转移的业务就可以了。从这个地方也可以得出一个小结论哈，在阅读业务代码的时候，如果和自己负责的工作不相关，并且也没有技术知识点在里面，那么其实大概了解一下就可以了，等到真正需要的时候再详细阅读也是不迟的。再往深的总结一下哈，也就是说阅读代码之前要想清楚是否有价值，如果没有的话，就节约一下自己的时间吧，生命诚宝贵哈。

还有就是在阅读代码的时候，特别要关注热点代码。啥是热点代码呢？经常出现问题的部分，完成自己工作必须要涉及的部分，项目核心功能必须要涉及的部分。看见没，热点代码其实是和业务强相关的。所以说，到最后会发现代码其实是对业务逻辑的表达。这让我想起了一位软件专家说过的一句更加抽象的话，代码是知识的表达。当时听这话的时候感觉很迷糊，问题就是在于“知识”到底是什么呢？结合自己的实际工作经历，这个“知识”就是业务逻辑。至于技术，比如Java、C++、Golang、Python等语言，它们是表达业务逻辑的手段。然后再来理解一下Spring、SpringBoot、SpringMVC这些又是什么呢?它们是方便你表达业务逻辑的工具，或者叫辅助手段，要是没有这些框架，一样的可以写业务逻辑，只不过会比较麻烦，效率比较低。

上面基于自己三年的工作经历谈了一下对阅读代码这件事的心得体会，下面我继续讲我的血泪工作经历和教训。

我整个实习期的技术学习都是围绕ServiceGovernance服务进行的，不过还做了一项贼烦的工作，那就是清理CodeDex，其实就是修改老代码中检测出来的静态告警，这个事情我再重点说一下，里面牵扯到很多的教训。

在清理CodeDex的过程中，给我分配的任务不仅有Java语言的项目，还有C++和C语言的项目，这就导致我要去了解其他语言知识，会把自己的技能栈扯散，这是第一个大的问题。在完成清理CodeDex任务过程中，我被参与了两期，周围一起进来的小伙伴都是参与了一期，这个具体的原因是多方面的，但是我觉得最大的问题在于我自己缺乏主动争取，基本就是别人安排啥我就做啥。

虽然是刚进去的新人，但是也要主动的为自己争取机会，比如前面提到的技能栈被扯散的问题，要是我主动提出就想做Java方面的工作，估计也就不会给我安排C++和C方面的告警清理了，还有就是安排第二期CodeDex告警清理的时候，我主动反馈一下，估计也可以避免再次参与其中。就是由于两期的CodeDex任务参与，导致我刚开始的两个月都没有办法真正的接触项目业务内容。

有一种可能是他们觉得我刚毕业，而且确实没有实际开发经验。但我还是想说，一定要有清晰的规划，并且要主动争取，特别是在华为这种大厂里面。说白了，就是别人只关系他们自己任务和KPI有没有完成，并不会真正的关注你的成长以及你的目标。如果有刚毕业不久的同学看到这里，一定要注意我提到的两点哈。

两个月的CodeDex清理结束后，就进入到正式的业务工作了。刚开始的时候我对着ServiceGovernance服务工程就发懵啊，代码太多了，不知道从哪里开始看起，也不知道该看什么。然后就是处理问题单，我觉得新人处理问题单是一个学习业务知识和软件知识最好的方式，处理问题单其实就是在定位bug，定位问题的时候有种解数学题和调查案件一样的感觉，就是在依据现象和已有线索去缩小怀疑的范围，找到原因或者猜测到原因后就到服务代码中去验证。但是这种方式也有局限性哈，那就是你学习到的业务知识和技术知识都是零散的，但总比啥都不知道要强的多。

这里插一点儿，我们新人入职后都会给安排一个导师的，并且华为还有导师制度和考核，这点真的要给华为点赞哈，不亏是大厂，我算是很幸运的享受到了这个福利。但是这儿要再提一点，要主动和导师沟通、请教，他们毕竟都是项目组骨干，平时很忙，不可能时时刻刻关注到你，别人也没有太多的义务像老师一样手把手教你，毕竟不是在学校了。但是他们有义务解答你的疑惑，所以这个时候一定要发挥自己的主动性，脸厚一点都没有关系，大不了他不喜欢你呗，但是学到的东西实实在在的是属于你自己的，并且这也是你以后立足的根本，特别是对于校招的同学。

我实习期的后面都是在处理ServiceGovernance的业务，刚开始的时候处理问题单，后面慢慢熟悉业务代码了就开始做一些模块开发了，当做模块开发的时候才发现自己好多东西不会呢，特别是设计模式。再然后就发现自己对于整个服务的业务功能不是很了解，对于服务中用到的技术知识不了解，这些都是在后续完成工作任务中发现的不足和短板，然后就疯狂的补充技术知识。

其实这种提升自己能力的方法，有点儿滞后性，就是当需要某些知识的时候才去进行学习和补充。但同时也有一个好处，那就是学到的东西马上就能用上。这同时是一个坏处，那就是可能用过一次之后，你当时学的知识就再也用不到了。这里我要提一个非常重要的理念，那就是要预判未来，即使能够预判一小步那也是好的，这样你就可以提前准备，提前储备知识。如果再结合清晰的规划，那么就能有不错的发展。同时要说的是预判未来和清晰规划都是特别难的事情，尽力而为就好。

还有就是我发现对于技术知识的学习确实是实践才是最好的方法，但是不要等着在项目中实践，一是有一定风险，二是这种机会很少，特别在自己是新人的时候。如果我回到当初，我会为自己搭建一个类似的业务环境来学习业务知识和技术知识。

随后由于业务需求，我接触了注册中心ServiceCenter，这是一个由Go语言开发的服务，当时还特意学习了Go语言，它里面的协程很棒，但是我也犯了之前的问题，阅读代码的时候采用饱和式攻击的方式，啥都读，没有一个重点，随后也基本了解服务里面重要业务逻辑和知识，但是时间代价巨大。

在学习ServiceCenter服务工程的时候又遇见了一个新的成长问题，那就是注册中心涉及到很多分布式的东西，特别是它所依赖的数据库ETCD，当时对于分布式相关的知识很迷，但是由于自己实际任务中用不到，也不用关注，所以就忽略了。这种做法是非常不好的哈，其实被我忽略的知识才是整个注册中心的精华知识。也是由于当时目光比较短浅吧，希望自己以后可以看的更加长远一些。

在学习注册中心的分布式相关知识的时候，我现在认为应该从业务项目中提炼出来单独去学习，甚至可以拓展至相关的分布式知识，很遗憾，当时的我并没有这样去做。

后来由于自己对于代码、业务和技术的能力提升，慢慢的在组内也能承担一些比较重要的工作了。然后，又发生了一件值得反思的事情。这件事情不是关于技术和项目的，是关于职场和人的。简单说呢，就是当时我们组经常加班，我确实长期疲惫并且已经有厌烦的情绪了，我认为这都是小领导安排的不合理导致的，再然后在一个比较晚的加班场景下，当时大概快晚上12点了，还要让我处理一个问题单，说实在话，我当时内心是奔溃的。

后续的工作中我已经出现负面情绪化了，然后在和小领导、另外一个同事一起处理问题的时候，小领导他写了一段代码，但是他自己没有提交，而是让我提交，当时的我傻傻地就提交了，都没有好好检查一遍。然后就出事情了，那段代码上了集成测试环境后出现了问题，然后定位问题同事就找到我这儿来了，并且气势汹汹地问责，当时的我那遭的住这架势，而且有点儿归罪小领导，这个代码本来就是他写的，然后让追责的人去问小领导了。这算是一个导火索吧，后续我被整的够呛。再最后我被换到了旁边业务相关性比较大的小组。

也是从这件事情开始，我慢慢的体会到了什么是职场，什么是上级领导，什么是管理层级。相对来说我觉得有点儿悲观，并不是我想象中的那样真正的平等。但同时也折射出来我认知中的一些不足。这个方面的事情我后续还会再讲，整个串起来会有新的发现。

新的小组虽然也是开发微服务框架相关的东西，但是他们所有服务和工程都是C/C++的，而且大部分是C语言。到了新组之后，刚开始一个月那叫一个难受呀，各种函数指针看的我头疼，还有C++的语法更是难以捉摸，辛亏我当时及时看了两本书《C++ Primer》和《C++ Primer Plus》。当时是白天上班，晚上九十点下班了就回去看一会儿书，要是实在太晚，超过十二点的话，我就不看了。我从那段看书学习的经历中总结出来一点，就是在看书学习的时候一定要做习题，书本后面的习题都是有针对性的，并且可以有效提升技术知识点的掌握，这是看网上博客所不能获得的。

由于之前锻炼出来的定位问题和看业务代码的能力，让我在新组里面很快的站稳了脚跟。后来新组里面来了一个大需求，是移植一个大的RPC框架到现有的微服务系统中，我很幸运的参与了这个需求开发中。整个需求完全使用C开发，之前学习到的语言知识可以用上了，RPC框架的代码非常偏底层，而且涉及到Linux *** 作系统select io的 *** 作，以及事件驱动编程。这些知识对于熟悉C/C++开发的程序员来说可能很普通，但是对于我这个刚接触C/C++两三个月的人来说很吃力。辛亏的是我看懂了整个RPC框架的业务流程和核心代码逻辑，凭借着这两点我顺利的完成了这个需求中的任务。

按照常理的话，我在这个小组可以有很不错的发展。但是由于感情的原因，我从西安迁徙到了成都，还是在华为工作。到了成都之后，我到了一个做远程运维的部门，具体一点儿就是负责华为存储设备的离线性能数据分析系统的开发、演进和维护。做这种工具性质的服务，其实感觉没有啥意思，但是好处是再也不用被催着赶进度了。我也没有真的闲着，而是浏览了整个系统十几个微服务的代码，梳理清楚了关键的业务流程以及数据流，并且还学习了MongoDB、SpringBoot、Kafka、Redis、Dubbo和Zookeeper，这些偏应用层的技术在之前的团队是接触不到的，因为之前更偏向于开发系统本身，对于第三方组件的依赖很少。在之前项目组的环境下是很锻炼人的，首先一个是有技术含量，二是业务比较核心，还有就是开发、维护框架是有比较高代码质量要求的，稍微不注意就会产生大规模影响，别的部门就会来追责的，在这种环境下，编写出来的代码质量可想而知，质量是相当高的。

虽然说在成都项目组里面没有学到过多的业务方面知识，但是技术知识有一个很大的提升，首先就是对一块业务进行系统性理解的能力得到了提升，我会用比较抽象的方式来梳理整个系统的关键业务流程。还有就是接触到了完整的Java技术生态以及NoSQL数据库。

但是在成都项目组里也踩了一个大坑。由于我在成都的同学很少，而且也是个外地人，组里面其他的同事全是成都或者四川其他城市的，有的时候他们说方言，我完全插不上话，还有确实存在一些隔阂。在这个项目组，由于自己想急于做出来一些东西，并且整个项目组的业务我确实不怎么看好，所以和小领导存在一些本质上的冲突。

这儿还要重点说一个方面的事情，由于组里面和我经常吃饭的两个早来两三年的同事经常抱怨项目的一些问题，以及小领导的一些问题，对我的影响还是挺大的，也是导致后续事件重大原因。现在回想起来，我受到这两个同事的影响是非常大的，反正就是把的态度带向了消极的方向。这儿总结一下，一是要远离本身消极或者给你传递消极态度的人；二是要培养自己独立的认知和判断；三是不要得罪直系领导，还有就是尽量避免和直系领导的潜在冲突。现在想想，项目组就是社会的缩影，有好人也有坏人，而且坏人也不是那么好识别的，特别是对于我这种刚毕业不久的人，一定要形成自我保护意识，老祖宗说地好：害人之心不可有，防人之心不可无啊！

在成都项目经历也折射出来自己的一些不足，那就是自己对于人性的理解很浅，基本等于没有，还有就是自己确实识别不了某些同事的欺骗和诱导，特别是在扯皮的时候，这些方面有点儿暗黑了，我也不想过多的描述，反正就是自己被整的很惨很惨！总结一下，注意保护自己，提升阴暗面识别能力。虽然我不愿提这些方面的事情，但实际工作经历告诉我这些东西它真实存在，我不得不面对，所以只有提升自己的识别能力和应对能力。

最后再提两点关于学习技术和业务知识方面的东西吧。

一是注重文档。不管是业务代码还是开源工作尽量去找到对应的文档，先读一遍再说，文档里面都包含有宝贵的知识，这些知识可能要读很多代码才能提取出来的，特别是业务代码。

还有一点是要多与人交流，不管是同事还是网上大佬，跟他们多交流，你会获得新的知识、视角和技巧，说不定还可以交到朋友呢。

最后还要强调一句，不要人云亦云，特别是别人抱怨部门或工作岗位的时候，可能人家有更好的去处了，或者说那些话的人本身看事物就不全面，更有甚者可能别人在故意传递负面消息和消极态度。至于部门、工作内容、岗位真的没有什么更好或者最好，关键是要适合自己，缺钱就去找高薪的，想搞技术就去偏底层的，想轻松一点就去业务节奏慢的。每个人的目标不同，选择的工作也不同，所以就不要去跟风了，更不要被别人带偏离了自己本身的路线。顺着这个思路我再讲深一点儿，那就是规划好自己的发展路线后一定要坚持，尽可能地坚持，坚持自己的判断和思考。实际经历告诉我，其他人的判断和决策很多时候都不一定比我们自己英明。

就写这么多吧，要是阅读完这篇文档的人有建议或意见，都欢迎。