一、前言

1.1 背景

最近 CSDN 开展了猿创征文，希望博主写文章讲述自己在某个领域的技术成长历程。
之前也曾想找个机会写篇文章，记录下自己的成长历程。
因此，借着这个机会写下这篇文章。

在回顾自己的成长历程的同时，希望对一些同学的学习和工作也会有一些启发和帮助。

1.2 主要内容

阅读本文，你可以了解到以下内容：

我当初做出一些重要选择，如弃理从文、弃文从工的原因。
我的校招和社招的经历，以及曾经作为求职者和面试官的一些经历和经验。
分享猪场、有赞和蚂蚁工作感受。
自己的写作经历和经验。
自己的比赛经历和经验。
自己的工作经历和经验，如如何快速熟悉新项目、如何更好地做好项目，如何更好地学习源码等。
工作之外参加的各种活动。

二、弃理从文 - 青春无悔

高中的时候，是班级里公认的 “数学小王子” 很多题目都可以给出多种解法。英语也不错，
当时偏理科的分数挺高（数学、物理、生物），偏文科的分数（英语、地理、历史）也不错。

后来文理分科时，大多数同学包括我的班主任都认为我毫无争议地会选择理科。
然而，当时暗恋一个女生，她虽然不能说非常漂亮，但是写字非常好看，而且有些科目（如地理、英语）成绩非常好，后面得知她选了文科。
当时总感觉如果选了理科，以后就再难相见（现在想想挺可笑的）。为了有更大的概率分到一个班级或者临近的班级，毅然决然地选择了文科。

最后，没有分在一个班级，也不在一层楼，尴尬。
偶尔会在同一天上体育课，万千人中一眼就可以认出她，眼里只有她，就像手机相机里的人像模式，然后默默地看着，或许这就是喜欢吧。
后来问她要了一份她手写的英语字帖，复印了很多份，反复临摹，导致我的英语字体非常“秀气”几乎和她的一模一样。虽然没有在一起，后面写英文字依然可以想起她，或许这就是青春吧。
她的每一个字条，送的每一张照片都珍藏起来。
后面交集越来越少，而且总觉得她挺优秀，自己长相也不出众，家境也非常普通，配不上人家，高考后也不在一个学校，就渐行渐远。
其实，有时候太喜欢一个人，就会觉得自己配不上人家；喜欢一个人也未必在一起才叫完美，有时候知道她过得好，也会感到非常满足。
青春或许会有很多遗憾，但无须后悔。恰是这些遗憾，才让青春更值得怀念。
所以，没错，弃理从文，因为曾经喜欢的一个女生。

三、弃文从工 - 热爱可抵漫长岁月

3.1 专业选择

当时家里还没有电脑，高中时家长也不允许去网吧，他们见到别人用电脑都是看电影、打游戏，认为“玩电脑" 的都是坏孩子。

高考完偷偷跑去网吧，发现网吧同学是看电影、打游戏，自己也和朋友一起打过游戏，可惜技术很菜就不太喜欢玩游戏。
在网吧里，更喜欢做一些与众不同的事情，如听听一些伤心情歌，为电脑换壁纸、练练金山打字通等。
也听说过一些黑客的事迹，感觉他们很酷。

大学选专业的时候挺想选计算机的，但由于对计算机的误解，还是没有选择计算机专业。
由于自己的英语成绩比较好，最后选择了英语专业。

3.2 冥冥中的缘分

我们英语专业的宿舍之前恰是计算机学院的宿舍，刚搬入的时候看到有“齐鲁软件设计大赛作品” 的光盘。
大学开学不久，各种社团纳新，计算机学院的 IT 精英协会会长带着一些部长来宣传，现场演示如何“破解”电脑密码，宣传有能力进入教务系统修改成绩，会长拿了山东省的软件比赛一等奖（当时我们学校一年最多只有一个该比赛的省级一等奖）等，非常羡慕和崇拜。

后面在日常学习之余，经常去图书馆看计算机相关的图书，选修计算机相关的课程等。
印象最深的是，《计算机入侵与防御》当时老师演示过某鸽子入侵软件，可以操作别人电脑，挺受震撼。
选修了 《Java 基础》，选择这个课的大多数都是计算机学院的同学，他们认为过于简单，很多人并不会认真完成作业，但由于我比较感兴趣每次都会非常认真完成。
买了电脑之后也自学了 CMD ，易语言和 C 语言等。

大学期间使用阿里的某个产品，其中有一个活动叫“写给十年后的自己”。
当时写的其中一个愿望就是“十年之后能够进入阿里巴巴”，最后也算如愿了。

3.3 巧遇恩师

有一次 Java 选修课的老师生病了，让我后来的恩师陈老师代课一天。
当时有很多疑问，请教了该老师，有一个问题没能当场解决，就加了 QQ 后面交流。
陈老师发现我对计算机有极其浓厚的兴趣，决定免费指导我。
现在想想挺佩服老师的魄力的，一个英语专业的学生，能不能学好编程真地很难说。
从此，Java 的学习逐步走上了正轨。

老师会介绍大概需要学哪些内容，怎么学，遇到问题请教也会帮及时解决。
当时买的电脑配置很低，只有一个 1G 内存条，使用 Eclipse 都很卡，老师送了我几个内存条并帮装好。
暑假没地方住宿，老师将自己学校附近买的教师公寓的房子免费让我住。
当然，老师对我的帮助远不止这些。

工作以后，逢年过节有时间都会去看望老师，和老师聚一聚、聊一聊，送老师一些公司的公仔等。

3.4 废寝忘食

白天有很多英语课程，如英语语法、英语听力、英语阅读、英语写作、英语翻译、英语口语，还有第二外语日语课等。
记得当时晚上放学吃完饭会第一时间冲回宿舍，打开电脑，看着传智播客毕向东老师的视频，边看边敲代码。经常不知不觉，就到了晚上十二点甚至凌晨一点。
对于一些可上可不上的课，都会选择不上，回宿舍学编程。

暑假在老师的教师公寓写代码，开始的时候还是毛坯房(和下图差不多)，整栋楼房还没怎么有人入住，平均两三层楼才入住一户。好在有电、有电梯。

当时自己拿被子席子铺在地上睡，有些胆小，晚上怕黑就一直开着灯学到天微亮，再睡。

遇到问题先自己分析，解决不了就百度，再解决不了的就去技术群里请教一些大佬。
有时候遇到问题卡住了，在技术群里请教大家，会有一些大佬给一些建议，帮助解决了不少问题。

这也是我为什么经常将遇到的问题的解决方案持续分享在博客里的重要原因。
有时候一篇文章，一个回答，可能就能够帮助某个像我当时那样的学生少走很多弯路。

3.5 质疑

中间也有一些质疑的声音，有一个高中同学得知我学计算机，喷我 “计算机学院的学生那么多，你一个英语专业的学生学啥计算机，再怎么学也比不上人家啊，有什么意义呢？浪费时间！” 诸如此类。

自己也有过些许的自我怀疑，自己真得能学好计算机吗？其实自己也不知道。

但是计算机让我感受到更“实用”，能够感受到“快乐”。或许这就是所谓的“不为了什么”的坚持。

比如电脑中毒了，知道怎么杀毒。同学电脑系统坏了，也经常找我给装系统。英语课的时候老师的 U盘经常中毒，真实文件被隐藏导致无法打开 PPT讲课，我主动请缨，一顿 CMD 指令将隐藏的文件恢复并打开。自学安卓开发，开发一个简单的短信发送软件，使用女友的照片当背景，能够发出短信就非常兴奋。

也曾和自己的另外一个恩师邵老师对此问题有过交流，他挺支持我去学计算机的，很多人毕业都没有找自己专业的工作，这也让我更加坚定了信心。

3.6 牛刀小试

后来，通过计算机学院的同学得知有“齐鲁软件设计大赛”（现在改名为“山东省大学生软件设计大赛”），就机缘巧合得报名参加了。

当时我作为队长，和计算机专业的 3 名同学组成一组报名参赛。
学校给参与这个比赛的同学安排了专门的实验室，大多数团队要么不来，要么就晚来早回，大多数团队都在比赛快结束一周内才开始来实验室搞比赛。

中间还发生了一件令我印象颇深的事情，负责值班的同学没见过我，询问情况发现我是英语专业，虽然解释了我已报名参赛，但依然不允许我进实验室。最后团队其他同学找学院的老师协调才被允许进入实验室。

这个比赛的作品从创意到核心代码的编写、测试，大多数都是我自己完成，后面也是我去济南山东建筑大学答辩，最终得了当年我们学校在该比赛中唯一的省级一等奖。而这个比赛恰是入学的时候宿舍光盘中涉及的比赛，也恰是入学社团纳新时 IT 精英协会会长拿到的奖项。

3.7 跨专业考研

虽然编程也学了不少，也有一些比赛获奖，但内心总不够自信，也对就业有些担忧。
计算机相关岗位的要求大都是“计算机及相关专业”，而且也想接受正规的计算机专业学习。
因此，决定跨专业考研。

跨专业考研的优势在于英语好一些，最大的难点在于数学，因为英语专业不开数学课程，需要花很大的经历学数学，还有没上过计算机的专业课。

主要通过看新东方的视频和线下的考研培训班来学习，最终考到了杭州电子科技大学软件工程专业的硕士，完成了英语专业到软件专业的转变，正式成为一名全日制的计算机学院的学生。

幸运的是，大学里虽然花了大量的时间来学习编程，但专业课学的还可以，通过了英语专业四级和英语专业八级（当时我本科学校英语专业的班级大概只有不到一半的同学通过英语专业八级）。研究生阶段每年都能拿到一等奖学金，综合成绩一直在年级 TOP 5。

所以，弃文从工，是因为非常痴迷编程，软件更“实用”，也能给自己带来一定的成就感。

四、我的比赛之路

4.1 比赛经历

本科主要参加了山东省大学生软件比赛（省级一等奖），研究生参加过“挑战杯” 国赛（全国三等奖）、“全国研究生移动终端应用设计创新大赛”（全国二等奖）、“全国研究生智慧城市技术与创意设计大赛” （全国三等奖）等。

参加智慧城市大赛的时候还有幸在北京大学宿舍住了两晚，在北大和清华校园里转了很多次，印象颇深。

其中一个印象：北大的食堂饭菜好便宜。

4.2 比赛经验

下面是结合我自己和身边朋友的参赛经验，总结出来的，希望对大家有帮助。

4.2.1 读懂要求

很多同学参赛的时候没有认真读取比赛的要求，最后因为偏题导致淘汰或者因为忽视评分规则而被打低分。
因此，参加比赛一定要读懂“题意”，这是一个非常重要的前提。

4.2.2 分析历届优秀作品的特点

重点分析历届一等奖、特等奖作品的特点。

比如对于一些软件比赛来说，尤其是本科的软件比赛，一等奖和特等奖的作品都有一些共性：
（1）创意通常符合当下的大的时代背景，如节能减排、环境保护、万物互联、共同富裕等。
（2）有一定的创新性，算法创新、玩法创新、商业模式创新等
（3）代码可读性强、健壮性强、拓展性强
（4）文档详尽，设计文档、测试文档等非常专业而且详尽
（5）配套的 PPT 非常结构化
（6） 配套的视频制作精良，能够凸显自己的设计亮点和技术深度

4.2.3 选好队友，强强联合

很多比赛会存在“蹭奖”的现象，一个团队里就那么一两个人最上心，其他同学要么水平不行，要么不用心。
大家参加比赛尽量选择好队友，避免上述情况的发生。
如果有机会可以选择实力和自己相当甚至比自己更优秀的同学合作。
这样不仅获奖的概率更大一些，而且参赛体验也会好很多。

4.2.4 常见问题准备充分

你的作品的主要创新是什么？
你的作品已经得到了哪些认可或验证？
你的作品的盈利模式是什么？
你的作品亮点有哪些？
你的作品有哪些不够完善的地方？未来的改进方向是什么？
如果 XXX 该怎么办？（想出至少 5 个 “意外”情况）

4.2.5 PPT 反复打磨，答辩反复练习

PPT 要反复修复，不断练习。
多一些图，少一些字；内容要非常结构化，重点突出；台下反复试讲，卡准时间，衔接流畅。
有机会可以找老师给组织一下模拟答辩，感受答辩的氛围。

4.2.6 态度要端正、时间要保障

很多同学参赛的态度不端正，只是想蹭奖，需要付出的时候找不到人，领奖的时候很积极。
很多同学的创意不错，但是没有投入足够的时间，最后没做出来或者做的非常粗糙。

五、我的写作之路

5.1 为什么要写作？

5.1.1 恩师推荐

最初是前面讲到的陈老师推荐我写技术博客。推荐可以写一些学习心得，可以记录一些问题解决的方法，可以写写对某个知识点的理解等，一直坚持到现在。

5.1.2 程序员精神

前面其实也有讲到，自己在学习 Java 过程中，网上的一些文章和少数靠谱的技术群对我帮助挺大的。
因此，我更愿意将自己遇到的一些坑总结到博客中，帮助别人少走一些弯路。有时候自己的同学、同事解决某个问题搜到我的博客，告诉我，我也会非常开心。有时候有网友在文章下留言，卡了好几个小时看到我的博客解决了，也会让我有些欣慰。

5.1.3 以教为学

很多时候能够通过通俗易懂的语言教会别人，才代表自己真正理解了知识。写作时会查一些参考资料，理解也会更加深入一些。

有时候写文章不够严谨，看有些朋友的评论，会发现自己对某个知识点的理解不够深入，可以查漏补缺。

5.1.4 记录成长历程

有时候翻翻自己的博客就大概知道每个时期都在学什么，博客是很好的成长见证。

5.1.5 认识更多朋友

很多不错的朋友是通过 CSDN 博客认识的。

5.2 主要作品

现在是 CSDN 、阿里云开发者社区、 51CTO 博客的专家博主。

写过 《解锁大厂思维：剖析《阿里巴巴 Java 开发手册》》、《再读经典：《Effective Java》 独家解析》 ，两个技术专栏。
主要从方法论的角度讲述《阿里巴巴 Java 开发手册》、《Effective Java》一些规定背后的底层原理。

写过 《Java 校招求职如何拿大厂 Offer》专栏，帮助校招生了解校招的底层逻辑，抓住校招复习的重点，分享一些面试技巧等。

写过《性能优化方法论》技术电子书（直接搜 “性能优化方法论 藏经阁” 即可）。该书分享自己对性能优化方面的思考；讲述技术层面和非技术层面的优化思想；技术层面如升软件、提硬件；空间换时间、提高资源利用率、串行转并行、利用时空局部性等；讲述性能优化在常见技术中的应用。非技术层面如砍需求、提升用户体验等。

在阿里内部的 ATA 技术博客上也发表了不少技术文章。

5.3 写作经验

5.3.1 文章要结构化

文章要能够按照一定的顺序来写，以便读者更容易理解。
可以按照时间顺序、空间顺序和逻辑顺序来写。

如可以采用 3W 的方式来写，即先写某某知识点是什么? 然后再讲为什么？最后讲怎么做。

参考文章：
《结构化思维，让你的工作有条不紊》
《我对“结构化思维”的理解》

5.3.2 文章要差异化

现在网上的文章千篇一律，如果我们写的文章和别人几乎一样，我们写文章的意义在哪里？
可以是诙谐幽默的语言风格；可以是精美而又恰到好处的配图；可以是自己对该问题的独到解读等。

5.3.3 重视排版

有些同学的文章排版非常混乱，看着就不想读下去。
有些同学文章开头带上思维导图，文章中间会有适当的配图，文章结尾是引导关注、点赞的图片等。

5.3.4 深入原理、授人以渔

大家写文章的时候，不要只人云亦云，也不要只讲现象不讲原理。
写文章，尽量能讲清楚原理，能够让读到的人知道根本愿意，能够举一反三解决一类问题。

5.3.5 专题化

尽量可以讲透一个主题或者一个系列，能够让读者通过看你的文章系统化掌握某个技术。

5.3.6 功夫在平时

我不太喜欢为了写文章而写文章。
大家平时在学习和工作中，解决了某个疑难杂症，就可以讲自己的分析思路和解决过程写下来。
在平时的工作中，看到一些 BUG 或者 故障，某个问题好的解决方案，就可以将这些经验积累下来。
平时有一些想写的话题，可以作为素材的内容积累下来，等写的时候就会文思泉涌。

六、我的求职之路

6.1 校招与社招

这些年，经历过校招和社招。
校招拿到了美团、网易等 Offer，社招进有赞和蚂蚁集团。

校招本质上是选择聪明的、学习能力强的，沟通表达能力强的同学。
校招重点看学校、名企实习经历、大型比赛获奖、高水平的论文等。
对于非名校的学生，如果想进大厂，最好是有不错的实习经历或者大型比赛的获奖。
校招重点考察专业基础。
校招会的问题要回答全面又有深度，不会的问题有思路则回答出自己的想法，没思路则直接说不会。
更多详细内容可参加我的 CSDN 校招专栏：《Java 校招求职如何拿大厂 Offer》

社招重点看工作经验，通常会选择技术能力强，项目经验丰富，懂原理，能够快速做项目和解决问题而且沟通能力强的同学。
社招准备好项目相关问题，常见的中间件的原理都要懂，清楚自己的亮点和不足。

6.2 求职者与面试官

当过求职者，也当过一段时间的面试官。
求职者和面试官的心态是完全不一样的。

之前也做过一段时间的面试官，面试官都是按照公司的面试标准来挑选候选人。
拿到简历后对简历进行圈注，主要看学校、公司，看技术栈和项目经验，会问一些基础问题确保基础足够扎实，也会问一些中间件的原理，还会问项目的亮点、难点，一些地方是如何设计的，为何这么设计，有何局限性等。
有些常见的问题回答不上来，通常会被打上“基础不够扎实”的标签；如果有些功能只会用，不懂原理，则容易被打为“技术深度不够”的标签。项目中很多设计讲述不清楚，很多设计不能给出令人信服的理由，容易被打上“经验不足的标签”。

6.3 猪场、有赞、蚂蚁

接下来谈谈在猪场、有赞和蚂蚁的感受。
猪场，印象最深的就是 APP 做的比较精致，餐厅免费而且选择众多，吃的挺好。但工作只配台式机，不配 MacBookPro，大家都是自己购买。

有赞，电商相关的技术非常成熟，微服务、中台搞得都挺不错。“家庭日” （即周三不加班， 6点就可以跑路，通常大多数团队周五也是晚上6点就可以跑路）也是一大特色。 Java 程序员会发 MacBookPro 携带起来非常方便。

PS： 本人还有幸被选作有赞校招官网的“学长代表”。

蚂蚁， Java 程序员会发 MacBookPro， 也可以选择 M1 芯片的机型。和阿里一样，蚂蚁对数据安全管控很严。
印象比较深的是技术氛围很好，有 ATA 技术论坛，蚂蚁自己的技术社区等；有各种技术分享的直播和视频教程；有各种代码评优比赛，各种代码重构比赛等；重视单元测试和代码审查；有各种自研的工具和平台；蚂蚁有很多自己设计的公仔非常漂亮，节假日有各种定制化的礼品。

七、我的工作心得

7.1 工作能力

7.1.1 关于做项目

关于更好地熟悉项目
实习、校招、社招初入公司需要上手项目，那么如何更好地上手新项目呢？
（1）看需求文档、技术方案和提测文档等。如果有相关的文档，一定先了解清楚，对后面理解项目的逻辑有极大地帮助。
（2）从功能入口往下捋。熟悉功能。找到要需要修改项目对应的 UI 界面，可能是 WEB 页面，可能是移动 APP 界面，也可能是小程序界面，触发相关功能，通过查看核心日志、远程 DEBUG 等方式熟悉核心逻辑。
（3）请教身边的同学。有些地方确实不太熟悉，可以请教之前参与过的人员或者对应的测试同学。平时可以适当分享一些零食，请一些奶茶之类的，后面请教就比较容易。

如何更好地做项目，减少出错的概率？
（1）以终为始，思考业务价值。做项目前要深入熟悉需求，更要思考项目的价值，以终为始去思考问题，可能会发现有些设计可以优化，做项目就更容易有的放矢。
（2）磨刀不误砍柴工。做项目一定要重视设计，设计方案时先总体后局部，充分各种异常情况，充分考虑拓展性，这就会降低返工的概率。
（3）编码时要努力遵循各种经典的设计原则，如高内聚、弱耦合；降低复杂度的原则。设计模式的六大原则等，灵活运用设计模式来解决问题。
（4）提高单测覆盖率，充分自测。一定要充分自测，做好自测记录，不仅要覆盖正常的用例，还要覆盖各种异常用例。重视代码审查，尽量在编码阶段发现隐藏的 BUG。
（5）重视错误日志。在自测或测试人员对我们的功能进行测试时，一定要多看错误和 WARN 日志，有些场景即使出错页面表现也会“符合预期”。
（6）多和 Master 分支比较。通过和 master 比较，可以避免误修改，可以做好代码审查，可以更好地评估改动点。
（7）做好代码审查。可以从功能、性能、可读性、可拓展性和可维护性等角度对自己的代码进行自我审查，当收到其他同学的审查建议时辩证地采纳。 详情可参考：《CodeReview 的正确姿势》
（8）做好发布计划。发布所需要的各种配置，服务之间的依赖关系，发布和回滚的顺序等都要写清楚。

7.1.2 关于源码学习

【1】很多人读源码收获并不大，原因有哪些？

缺乏整体思维，迷失在细节中（如调试源码时跳来跳去，最后跳晕了）缺乏思考（学而不思则罔，思而不学则殆！）不知道读源码究竟读什么（如源码的设计思想）角度单一（如从解决问题角度、性能优化角度、设计模式角度、每次提交、单元测试、注释等）方法单一（如不懂的高级的调试技巧，不懂的时序图插件）缺乏输出（不会输出成文章，不能讲给别人听）

【2】读源码究竟读什么？

读目的：该框架是为了解决什么问题？比同类框架相比的优劣是什么？这对理解框架非常重要。
**读注释：**很多人读源码会忽略注释。建议大家读源码时一定要重视注释。因为优秀的开源项目，通常某个类、某个函数的目的、核心逻辑、核心参数的解释，异常的发生场景等都会写到注释中，这对我们学习源码，分析问题有极大的帮助。
**读逻辑：**这里所谓的逻辑是指语句或者子函数的顺序问题。我们要重视作者编码的顺序，了解为什么先写 A 再写 B，背后的原因是什么。
**读思想：**所谓思想是指源码背后体现出了哪些设计原则，比如是不是和设计模式的六大原则相符？是不是符合高内聚低耦合？是不是体现某种性能优化思想？
读原理：读核心实现步骤，而不是记忆每行代码。核心原理和步骤最重要。
读编码风格：一般来说优秀的源码的代码风格都比较优雅。我们可以通过源码来学习编码规范。
读编程技巧：作者是否采用了某种设计模式，某种编程技巧实现了意料之外的效果。
读设计方案：读源码不仅包含具体的代码，更重要的是设计方案。比如我们下载一个秒杀系统 / 商城系统的代码，我们可以学习密码加密的方案，学习分布式事务处理的方案，学习幂等的设计方案，超卖问题的解决方案等。因为掌握这些方案之后对提升我们自己的工作经验非常有帮助，我们工作中做技术方案时可以参考这些优秀项目的方案。

【3】读源码也存在很多误区：

开始就尝试大型开源项框架，容易信心受挫，导致放弃。读源码没有规划，随心所欲。直接看源码的解析，直接看源码的写法，缺乏关键的前置步骤，即先自己思考再对照源码。

【4】如何读源码效果更好？

先会用再读源码。如果用都不会用，读源码就成为空谈。至少写一些 DEMO，如果写 DEMO 需要花费很多时间，可以去 GitHub 上搜一些实例快速上手。先易后难，循序渐进。先看架构再读源码。可以先通过框架的官方文档了解其整体架构，了解其核心原理，然后再去看具体的源代码。查看核心类的函数列表。先看整体再看具体细节。如学习 Spring 生命周期，重点学习 org.springframework.context.support.AbstractApplicationContext 的核心函数 refresh ，把握好整体再去研究细节。要以设计者的角度来学源码。从设计者的角度读源码是一条极其重要的思想。体现了**“先猜想后验证”**的思想。学习源码时不管是框架的整体架构、某个具体的类还是某个函数都要设想如果自己是作者，该怎么设计框架、如何编写某个类、某个函数的代码。然后再和最终的源码进行对比，发现自己的设想和对方的差异，这样对源码的印象更加深刻，对作者的意图领会的会更加到位。从设计模式的角度学源码。

【5】有哪些好的阅读源码的技巧？

通过注释学习源码。优秀的开源项目注释非常清晰，对我们了解用法和理解设计理念有极大地帮助。通过单元测试来学习源码。优秀的开源项目通常单测覆盖率极高。我们想学习某个类，可以通过运行单测，调试单测来学习，效果会很好。从入口开始学习源码。借助 IDEA 插件来学习源码。可以借助根据代码生成类图、时序图等，更好地学习源码。根据 issues 学习源码。源码通常比较庞杂，可以从小处着手，每个 issue 通常只专注一个问题，可以查看已经解决的 issues ，了解问题的原因和解决方法。根据提交记录来学源码。可以看这次提交做了什么，通过哪些方式添加了新的特性或者修复了什么问题。跟着专栏来学习源码。有些源码解读专栏质量很高，循序渐进，跟着专栏学更系统，

篇幅有限，如果想对阅读源码有更全面地了解，可参考的一篇 GitChat ：《你真的知道该怎么读源码吗？》

7.1.3 一些问题的看法

【1】关于新技术

有些同学想让我讲讲对新技术的看法。
很多底层原理都是通的，我们如果能够有扎实的专业基础，如操作系统、数据结构和算法、计算机网络、数据库等非常扎实。各种中间件原理、常见的框架源码读得都恨透。学习新技术会容易很多。
新技术要去评估是否需要学，即使不去深入学习也大概知道它解决什么问题，大概的原理是什么，当工作上确实需要掌握时，快速上手学习即可。

【2】关于 DDD

DDD 整体上来说是通过增加领域层，降低耦合的一种解决方案。

其中 DDD 包括战略和战术两部分，战略即各种概念的理解，领域模型的划分。战术则更侧重于领域模型的落地。
由于 DDD 涉及的概念众多，落地时也会遇到各种问题，不同人的对一些问题的处理也会有些差异，上手成本略高。
由于篇幅原因，里面具体的概念和实践这里先不作过多展开。
想了解更详细地内容可以看相关图书和专栏。如《领域驱动设计》、《实现领域驱动设计》（张逸）、《解构领域驱动设计》、《领域驱动设计精粹》、《领域驱动设计实践》专栏（张逸）等。

7.1.4 其他能力

排查问题的能力。如采用二分法定位是前段还是后端的问题；恢复 master 代码，判断是之前的问题还是新引入的问题；采用源码分析、代码调试、日志分析、Arthas 等方式定位问题。

还要掌握做 PPT 的能力。要能够通过结构化的方式设计好 PPT 的骨架，能够重点突出、结论先行，多一些图形少一些文字，将亮点、重点、难点都说清楚，体现出自己的思考和价值。
还要掌握良好的沟通能力，可以看《非暴力沟通》。
还要掌握好项目管理能力。及时识别项目的风险点并解决。

7.2 工作之外

7.2.1 DIY 班

之前参加参加过《阿里巴巴 Java 开发手册》、《码出高效》作者，孤尽老师的 DIY 班。

DIY 班的含义：
其一，Deeply Inspire Yourself
深度激发自己
其二，Do It Yourself
实践出真知

DIY 班前几次作业孤尽老师就强调大家要重视 “快速学习的能力”、 “学习如何学习的能力”、“举一反三的能力”。
孤尽老师提到学习的四部曲：记忆、理解、表达和融合。
DIY 收获很大，其中一个就是学技术要深入原理，知其所以然。

详情参见：《我眼中的Java大牛之孤尽老师》

7.2.2 编码比赛

公司内部会有很多代码重构、发现代码 BUG 的各种比赛。
当过选手也当过出题人。

这类比赛有时间都会积极参加，能够提高自己代码的健壮性，有些比赛也能拿到不错的结果。
作为选手会认真寻找每道题隐藏的 BUG ，作为出题人则会精心每个考察点，希望能够通过题目的设计帮助大家在工作中避免遇到类似的问题。

7.2.3 智囊团

公司内部的很多重要的技术课程，有时候也会招募智囊团，有时间也会积极参加。
当智囊团能更早学习课程，有更多地和大佬交流的机会。

7.2.4 代码评优

参加过公司第一季代码评优，并获得 TOP50。

也当过第二季代码评优的大众评审对其他同学的代码进行打分，并被评为优秀大众评审。

比较认可：“写代码是个良心活”，“优秀的代码都有一些共性”。

7.2.5 讲师

也会参加一些讲师能力的课程培训，学习一些讲课技巧。
现在已经是成为一名预备讲师，后面争取早日成为一名正式的讲师。

7.2.6 金光闪闪

由于在指导新人和技术分享方面做的相对较好，也获得了两个公司的“金光闪闪” 奖项。

八、总结

热爱可抵岁月漫长，温柔可挡艰难时光。
热爱编程就会详尽一切办法去努力提升，就更容易不知疲倦。
希望本文对大家的学习和工作能够有一些帮助。
有任何疑问欢迎评论区和我交流。
我近期也会对文章进一步进行优化修改。

---

创作不易，如果本文对你有帮助，欢迎点赞、收藏加关注，你的支持和鼓励，是我创作的最大动力。

本文正在参加 CSDN 猿创征文，如果本文对你有帮助，可以点赞、评论来支持我，感谢。