一、序言

日常生活沟通交流过程中，时常会被问及为什么要写作源标识符和怎样写作源标识符的难题，责任编辑则chicourt我的认知。

二、为什么要写作源标识符

首先来聊下为什么要写作源标识符。我们在做工程项目这时候通常会碰到上面的难题：

难题一：不晓得怎样去结构设计，比如说刚入婚恋时，来两个市场需求aes概述结构设计，不知怎样脱身，不得已去看现阶段控制系统类似市场需求是怎样结构设计的，然后仿效去结构设计。难题二：结构设计的这时候，考虑难题不周详，相比婚恋初学者，这妖物对两个市场需求倚靠她们的实战经验已经能够拿出两个概述结构设计，但结构设计中时常会陈述许多极度技术细节。

对于那些难题，归根结底主要就是因为实战经验不如，而实战经验主要就从工程项目实践中累积，所以招工单位通常单厢限量发行工作天数小于 3 年，因为那些人的工程项目实战经验相较较丰富，工程项目中碰到的情景相较非常多。

另外进职场后通常都要先熟识原有控制系统，假如有文件格式说实话，没文件格式的话就得她们去翻标识符科学研究。假如大家之前对写作源标识符有实战经验，所以在科学研究新控制系统的标识符方法论时就不能所以稳当了。

还有一点就是当你采用架构或者辅助工具做开发时，假如你对它的同时实原有所了解，就能最小化的减少出机械故障的可能。

比如说mammalian堆栈 ArrayBlockingQueue 里面原素入团有位 offer 和 put 方式，虽然某一天数点你晓得采用 offer 方式时，当队列满了就会弃置要入团的原素，之后 offer 方式会回到 false，而不能堵塞现阶段缓存；采用 put 方式时当堆栈满了，则会挂起现阶段缓存，直到堆栈有空余原素，入团成功后才回到。

但人是孙奂的，当你一段天数不采用，就会忘掉她们的差别，这时当你采用时，需步入 offer 和 put 的源标识符看她们的同时实现。步入 offer 方式细看，哦，原来堆栈届满时直接回到了 false；步入 put 方式细看，哦，原来堆栈届满时，直接采用条件变量的 await 方式挂起了现阶段缓存；晓得了她们的差别，你就可以根据她们的市场需求来选择了。

看源标识符最大的好处是可以开阔思维，提升架构结构设计能力。有些东西仅靠书本和她们思考是很难学到

能力的提高不在于你写了多少标识符，做了多少工程项目，而在于给你两个业务情景时，你是否能掏出几种靠谱的解决方案，并且说出各自的优缺点。而怎样才能掏出来，一来靠实战经验，二来靠归纳总结，而看源标识符可以快速增加你的实战经验。

三、怎样写作源标识符

所以怎样写作源标识符呢？在你看某两个架构的源标识符前，先去 Google 查找这个开源架构的官方介绍，通过资料看看该架构有几个模块，各个模块是做什么的，之间是什么联系，每个模块都有哪些核心类，在写作源标识符时可以着重看那些类。

然后对哪个模块感兴趣就去写个小 demo，先了解下这个模块的具体作用，然后在 debug 步入看具体实现，在 debug 过程中第一遍是走马观花，简略的看下调用方法论，都用了哪些类；

第二遍需有重点的 debug，看看那些类担任了架构图里的哪些功能，采用了哪些结构设计模式？假如第二遍有感觉了，便大致晓得了整体标识符的功能同时实现，但对整体标识符结构还不是很清晰，毕竟标识符里面多个类来回调用，很容易迷失现阶段断点的来处，所以你可以进行第三遍 debug，这这时候你最好把主要就类的调用时序图、以及类图结构画出来，等画好后，在对着时序图分析调用流程，就可以清楚的晓得类之间的调用关系，通过类图就可以晓得类的功能、以及相互之间的依赖关系了。

另外开源架构里面每个功能类或者方式通常都有注释，那些注释是一手的好资料，比如说 JUC 包里的许多mammalian组件的注释，就已经提供了它们的结构设计原理和采用情景。

另外写作源标识符时，最好画出时序图和类图，因为人总是孙奂的，假如隔一段天数后你在去看之前看过的源标识符，虽然有些印象，但当你想去看某一模块的方法论时，又需根据 demo 再从头 debug 了，而假如有了这俩图，就可以从时序图或者类图里面直接找，并且看一眼时序图就晓得整个模块的脉络了。

还有查架构采用说明最好去官网查，虽然是英文，但看久了就好了，毕竟还有 Google 翻译呐！

当然科学研究标识符时不一定非要 debug 三遍，其实这里说的是三种掌握程度，假如你 debug 一遍就能掌握，那自然更好啦。