最开始写 Kubernetes 专栏的时候我并没有十分明确需要到达的目的地，写的过程中知识树是一点一点生长起来的，我是一个 Go 后端开发，更多的是带着想把 Go 写好的心态，去学习优秀作者的代码和想了解云原生相关内容。
全部重要，就是都不重要
最开始读 Kubernetes 源码的时候，想写大而全的内容，完整的把整个 Kubernetes 的源码讲解一遍，但是后来发现相应的课程其实很多，然后在看的过程中会发现一个很严重的问题：没有重点。
如果每个模块我都花同样的精力去写，不仅产出的内容质量得不到保障，深度不够，看的人学后也很难有用的上的内容，而且对我自己的精力也是一个巨大的挑战，可能还没开始写我就会劝退了，所以果断放弃了这个写作的思路。
我也发现学习 Kubernetes 如果冲着大而全去的话，很多时候是学了前面忘了后面。
我也一直秉持着学习是“为我所用”的原则，如果用不上，那宁可把学习的时间用来打游戏或者运动。
接着我调整了学习的方向，通过自己感兴趣的网络知识点去深入 Kubernetes 负载均衡和网络包流转的知识，先通过官方文档了解 Kubernetes 网络能力和边界，然后心里有概念后再通过源码去验证自己的想法。
去看 kube-proxy 和 apiserver 是如何相互配合来实现网络负载均衡的功能。
我在学习的过程中积累了一些自己的 读代码包含实操的方法论 ，所以也写了一篇 《开发同学应该如何学习 Kubernetes》 ，也算是对自己的学习阶段的总结和实用的方法论，可以立即去尝试做起来的指引。
这些技巧也非常的实用，不仅仅是在阅读 Kubernetes 上可以用到，在阅读其他任何开源项目源码的时候都能够去使用的。
写的过程中我发现我自己的读代码的实操方法也不断被修正，理解代码的用法也有自己明确的一套思路。
例如，在最开始有些地方的代码读不懂，随着逐渐的深入，不断的笔记和心得的记录，慢慢领会到其中代码设计的精妙，甚至能够和自己写的文章碰撞出一些想法，感觉就像是和过去的自己在对话。
我不可能一开始就把所有知识都搞懂，内容是一步一步在积累的，每次我多了解百分之一，写下来，不断积累，复利的效果让我瞠目结舌，隔了一段时间我去回顾的时候，会发现很多东西会被串联起来，从而打通了“任督二脉”，以前觉得困难的内容也迎刃而解。
不能解决实际问题的知识不会产生价值
我最开始也是喜欢研究 unix 网络编程的内容，最开始积累的时候是因为做 Web 后台经常需要网络相关的内容，但是只停留在 HTTP 和 GRPC 等应用层会让我觉得很多东西都是黑盒， 我不想只是做一个工具的使用者，更想了解工具的构造，这纯粹是我个人的兴趣，到后面发现工具的构造了解了之后能让我更加灵活的去使用工具。
比如做单机应用的时候内部服务间通信，不需要通过网络，而是直接通过 unix 的文件 socket 实现，而不是只通过内存共享来实现。
在这个过程中读了《技术的本质》，回过来看Kubernetes 写作主题的时候，我觉得可以从技术的演进来看K8s，本身是依赖操作系统的功能来实现，更多的是对node节点资源的管理和pod 资源的调度分配。
拥有越多的视角，则能获得的信息越多
这是对于同一个信息而言，同样是K8s，作为运维开发能看到的是应用部署操作的简易程度。作为后端研发则是看到它在并发编程的优雅处理，作为产品经理能看到的是云原生带来的持续高可用。
在过程中从理论知识的串联，到源代码的剖析，记录起来后逐渐对 Kubernetes 有一个整体的认知。这个时候我的目标变成了如何通过学习来反哺自己的业务设计，从 Kubernetes 整体设计来提升自己设计组件的复用性、扩展性及性能等。
我尝试写一些实用性非常强的内容，如《看了Kubernetes 源码后，我的Go水平突飞猛进》和《看了Kuberentes源码后，得到的 Golang 工程化实践》，也是对我平时遇到的问题实在读过 Kubernetes 后写Go代码的实践经验总结。
发出来后反馈了两者看法： 一种则是在实际中很难去用到这些方法；一种是这些代码封装方法有点华而不实，都是装逼用的。
知行合一往往是最难的，“道理我都懂，但是就是过不好这一生”，要在实际通过这些方法是写代码，需要不断地刻意练习。
大部分是业务需求时间紧就不会去认真斟酌代码的设计，这无可厚非，完成产品才是我们的首要目标，但是忙的中间我们也要抽点时间出来思考，在项目、时间和结果之间做平衡。
人最有价值的部分是思考，思考才能让我们衍生出不可替代的价值。思考怎么用知识来改善我们的工作质量，才能让我们更上一层楼。
至于第二种是否华而不实，这个要靠自己的实践去体会，软件工程的所有方法都是在致力于提升软件研发的效率，如果有一天这些方法不能提升我们工作效率，我们就把它抛弃就好了， 没必要执着于某些方法。 这到最后会迷失了我们自己用方法论的方向， 沦落为工具和方法的傀儡。
可以看到在写 Kubernetes 的专栏的这一年里，我是在不断修正自己的方向，写出来的东西要想清楚服务的是什么人，出于什么目的， 这个是不断的在调整的，没有一开始就固定了目的，而是通过专栏生长的过程中不断地去优化我的目的。
从最开始想写好 Go 去开始，后面因为不断的学习、回顾，调整到了实用性强的内容上，在这个过程中我不断的调整自己的角度，产出的方向也一直在进行调整，到我写这篇文章的时候也只是我当前最优的感悟，随着我继续深入的探索，说不定也会全部推翻，但是这个过程记录下来后，我的思考更加结构化，也更少的去遗漏问题。
好的学习，是做一个东西出来
我深刻学习到讲清楚一件事要从降低读者的认知难度开始，可以试着用一个生动的例子去说明。
把学到的东西做成一篇通俗的文章帮别人去学，讲出来教别人掌握，是自己学习最有效的一种方式。写出来文章就是我做出来一个东西去讲给别人听。、
这个过程我必须把我脑子里觉得已经明白了的知识实体化出来，会发现很多内容其实对我来说还是相对比较模糊的，这个时候我就需要更再次进行打磨。
直面错误，别让大脑安慰我们
写作是不断修正我自己想法的过程。能帮助我们减少“认知失调” ，我们觉得自己在某个方面很聪明的时候，就会下意识的去欺骗自己，从而错失了调整自己的机会，在不知不觉中下次又会犯相同的错误。
而写作的时候我们会不断的记录我们当时的最优解，不容篡改，让我们更能够发现自己之前想法的漏洞，再推进自己去改进漏洞，避免下次再犯就可以。
人非圣贤孰能无过，允许自己犯错、承认自己犯错，是改正错误的前置条件。
我坚持写内容五年，翻看以前文章，每次给我的感觉都是以前的文章还有很大的改进空间。
这也让我很欣慰，因为我以前能发布出来的文章，都是我自己觉得写到最优的了，但是隔一段时间看之后我能发现里面的缺点和漏洞，证明我自己已经有了进步。
我就会将文章重新进行组织，并且在重新组织的过程中，重新进行更深入的思考，和我这段时间积累的内容进行融合，产出了更有有深度的思考点和内容。
