这是我参与11月更文应战的第18天，活动详情查看：2021终究一次更文应战
袁小白开开心心的在例会上共享了关于llb.State和Definition的了解。 得到了龙飞和贾大智的一致好评。 能在短短的时间里把握到关健的数据结构用法，的确是件了不起的工作。
由于绝大多数状况下，咱们宁愿自己写都不想看他人代码的原因就在于代码的复杂性。 本来觉得自己还挺优异的，但一到看他人代码时，就会多少对之前的决心产生怀疑。 加上看不懂的时分还不少，就一次次将怀疑实锤了。 这当然是不好的体验。
从实践的状况来看，读他人代码的确也存在应战。 假如代码写的标准，朴实，读起来简略易懂，这当然是好代码。 但一起这也是较高的要求，要求对设计形式、算法、数据结构、结构及编程范式等等都了解的很到位，这样写出来的东西都是一些程序员之间的共同语言，当然容易沟通一些。 但往往这种理想的状态不容易到达，加上许多时分，咱们再把复杂的业务逻辑揉入其中，就更是难上加难了。
贾大智对袁小白赞赏之余，也提了点建议。 那就是能不能用这些把握了的知识，把之前llb.State第一印象中完好的比如，整理一遍，既能验证了解的正确性，也顺便能够加深了解。
话是这么说，袁小白不由心里还是泛起了嘀咕：你怎么不去整理啊。
想归想，袁小白还是找机会，认真的看起了源码。
递归Marshal思维
递归实例了解
根据对examples/buildkit0/buildkit.go实例的了解，加上了解到的递归思维，袁小白对用例进行了整理：
- 根据构建好的llb.State链表，假如要进行Marshal，最先会从终究一个结点开始进行递归，但为比如中所有的操作都是SourceOp和ExecOp类型，所以都会有自己的Marshal方法。
- 假如有多重依靠，会按顺序完成对应的递归，如图中步骤3, 9, 16都是SourceOp
- 由于是深度优先算法，所以会将每一个依靠尽头，处理完后再进行下一个依靠的处理，只有在都处理完后，才会处理真正的终究一步18.
从结构上来看，像是一颗反过来的树。
llb.State实例了解
假如要将准备好的State都转化成Definition，那对应的llb.State调用顺序又会长什么样呢：
- 能够看到起先是各自独立的State，如S1, S2, S3，也就是经过llb.Image创立的结果，这时他们互相并不知道对方的存在，并没有相关
- 跟着一步步的履行, e5将咱们相关到了一起，由于复制操作要将src复制到dest，而ExecOp的会从Mount中获取位置信息，所以就将几个ExecState相关了起来
- 终究履行咱们的终究操作
ls -l /bin
经过一番整理，袁小白的确比以前更有决心了。 这也为后边的PoC打下了良好的根底。
