从六月份开始，断断续续写了80篇左右的blog，基本上是比较符合预期的。但是在这个过程中，逐渐感觉到会有一些力不从心的方面。这里小结一下，好的地方继续保持和发扬，后期如果状态不佳，可以查看帮助快速恢复状态；不好的地方，继续寻找有效的办法，在实践中进行不断地反馈和迭代，最终的目的是形成一套正向的循环。
1.为了防止没有可写的主题，特意设置了一个list清单用于收集平时的idea和有意思的bug。实践之后发现虽然有些问题（后面会提），但这确实是一个很好的习惯。起初只是为了保证blog的素材和内容，所以遇到这种有疑问、反常的情况时会注意把它们简短地录入list，如果当时就能解决那么当天就会把这个问题写成blog，这其实是相当于复盘记录了；但如果当时解决不了，那么也会特别积极主动地去搜索相关的资料，过一段时间就会形成一篇blog，一般来讲，这一篇的质量应该比直接解决的要好一些，因为查资料的过程中会让自己学到很多东西，而写的过程又会强迫自己重新整理和组织这一批知识点，收获会比较大。同时，长期进行这种活动，甚至会影响到思维的过程和习惯，让自己对身边发生的bug和异常情况都会更留心一些，相比于具体的知识点的收获，我觉得思维和习惯的转变是更为难得和宝贵的。
2.为了保证自己的说法能够立稳，一般在写之前都会去查证、去实验，这个过程本身就是一种搜索与学习。很多时候，我们也知道这个知识点，并且如果让我们去做选择也能做出正确的选择，但我们并没有百分之百的把握。这种从不确定到确定的转变，一方面会加深我们对知识点的理解和把握；另一方面，当遇到复杂、组合的问题时，我们往往能够特别坚定地把我们有百分之百把握的内容从中剔除，从而为解决剩下为数不多的麻烦铺平道路，这在定位某些bug的时候尤其明显。很多时候之所以解决不了一些问题，就是因为组合的、综合的问题出现时，我们没有把握一一化解。实际开发中，遇到一些写出坏味道的代码的情况，并不是不想写好的，而是改写了一番之后，我们会对这种改动没有把握，内心存疑，当任务比较紧迫时，就会趋向于或者说不得不使用坏味道但是我们有把握的代码，这样长期积累下来，就会形成一堆堆谁都不想动谁都看不懂的烂代码。
3.写blog确实会对理解一些基础和概念性的问题带来帮助，尤其是去梳理了技术的背景，解决的问题，适用的场景，同类型技术对比之后。这种不断加深的基础性的理解，也会为更为系统，更为深入该领域创造条件和动机。所谓的动机，就是确实有动力、有好奇心，会去想它的过程是怎样的、它是怎么解决这个问题的...有了这个动机，我们才能顺理成章地、也更符合人的行为天性地去学习和了解。避免出现学了但是完全不知道学了什么，有什么用...如果真的有这些感受，我觉得基本上只算是填鸭了一些杂乱的知识点，如同无源之水无本之木，时间稍微一长就会忘掉，几乎无效。所以解决这个动机，对于这类有背景、有原理、有应用场景的技术是很重要的一件事。
上面写了一些写blog之前没有想到过的收获，当然不止这些，但写出来的基本上属于是写之前想不到但写之后感受深的一些点。我觉得把它们表达出来也更能够坚定写下去的信念，毕竟每天花这么多时间和精力来做这件事情是需要毅力和坚持的，如果没有充足的理由，肯定不会持续长久。
接下来要总结的是目前遇到的一些暂时想不到怎么解决的矛盾点：
1.最开始预期的list是能够一边录入，一边就消化掉编程一篇篇blog，最终形成一种动态的平衡。但实际过程中发现，录入的速度大于写blog的速度。这就导致list中始终会有一些主题，因为题目内容太过庞大或者自己基本不熟悉，只是刚刚了解背景就想来一篇有点质量的内容，所以本能地每次都会跳过，这是一个要解决的问题。
2.方向分散一。这主要是说，在录入list时，由于一开始没有这方面的意识，什么方向的问题都录入。这就导致后期花费了时间和精力，但由于根基太浅，所以这个方向的内容只能算是粗略了解，完全达不到一定的深度，同时，工作的内容与之关系又不大，所以最终要么效果不好，要么就一直呆在list中每次都被跳过，时间一长会有种挫败感。虽然说，也希望自己能够成为一个全能选手，但是全必定就会对深度欠缺，尤其自己计算机基础还是飘着的状态，这其实是策略上出现了失误。
这一个分散，主要是想说明需要对方向的把控和取舍，要设定一个合理的选择范围，把时间和精力花在当前收益最大的问题上。而下一个分散，主要是说明另一个问题：时间的安排。分散一主要说工作上不涉及的大方向，比如前端，DBA，产品等在当前这个阶段基本可以考虑不去花费时间和精力；分散二是要讨论当前工作紧密相关的内容和基础学习的精力冲突。
3.方向分散二。在六到九月的这段时间里，初期会遇到分散一中的战略失误，但是后期有了这个意识之后还是迅速调整了思路，不去碰自己工作不相关的内容了，把精力留给常用技术的深入理解上，这样在学习和实践的效果上是能够找到伙伴进行讨论，并进一步加深理解，且对当前工作有收益的。
但最近这段时间越来越觉得，虽然缩小了范围，但是自己的后端领域里天然包含的需要很好掌握的主题还是范围不小，比如JDK，JVM，Spring，JPA，ORM，TCP/IP，分布式，架构，代码质量，MySQL，Redis，Jenkins，Linux，操作系统......所以每次找到一个主题，花了几天写一些相关的内容，但随着工作里出现的其它问题，可能又会迁移到另一个阵地中.....时间过去了两三个月，但是发现对于这些主题，自己全都是在各种主题的外围进行涉猎，没有沿着某一个主题进行单线深入挖掘的时间了。
这其实牵扯到了时间和精力的分配。一方面，自己规划地还不够合理紧凑，所以偶尔出现了思维空档（那几天不知道想干嘛，也没有热情去投入某个主题），多出来的时间会去群里吹水，玩手机，游戏（不合理地超时）等等；另一方面，确实是基础太弱，所以到了哪里稍稍深入，都会有以前没听说、不明白的点浮出水面，从这个角度上来说，所做的这些工作也是值得肯定的，值得投入时间精力的。但是，时间一长，没有在某个领域里完整地看完一本书，或者完全走完一遍主要的知识点内容，想想还是有些沮丧。
目前基本上遇到的明显的问题，就是以上3个。对于1和2，只要自己把控住录入的主题，基本上可以很大程度上避免，这是一个意识问题。而第3个是资源的合理分配，其实是比较棘手的。当下的想法是，要想办法建立机制开辟两个主线，一条主线用于这些分散、但是遇到了具体场景，解决之后能够提高相关理解和能力的问题；另一条主线，是要把握住一个方向，长期啃书本，做实验，输出blog，从而形成深入的认识。后一条主线其实需要不断地提醒自己基础的重要性、同时还需要合理的时间和精力安排，其实挑战不小，只能在后续的实践过程中再次感受，并总结整个安排是否合理，是否有达到预期。
最后，在这个边写边梳理思路的过程中，我甚至感觉写完之后在动力上又有一些提升，思路也较之前更为清晰，再次对自己证明了这种做法的有效性和必要性。