【关于写博客这件事】
初入职场大概1年左右，慢慢从转行不知所措的进入到了一个能够应付日常工作的适应状态。当时手里有一个不大不小的线上项目，也会经常做一些边角料工作，与产品沟通的时候也会抑制不住想要发火。就是从那个时候开始，慢慢接触到写博客，将一些对技术的积累通过文字的方式转变成文章。
但坚持了仅仅几个月，不知道从哪里看到一个观点，说开始学习写代码的新手不要写博客。不知道为什么，可能是为自己的懒惰找到了理论依据吧，就停了博客。这一停基本就是接近4年的时间，期间基本没怎么写，现在想来除了后悔还有就是感觉自己被那篇文章给耍了。
其实写博客，是一种全方位的锻炼。且不说文笔、表达、思路这些软性的东西多么的通用，仅仅是计算机技术、工程经验以及学习笔记的积累都是技术人员的一笔宝贵财富。在这个过程中，为了文章的完整、清晰、全面、准确，我们会逼迫自己去查资料，做实验，学习以前并不知道或者很模糊的东西，在没有考试压力以及其它的动力时，这是一个非常好的激励自己前行的手段。
写，不仅是为了记录，更是逼迫自己去思考。一个技术人员，在过了进入职场的适应期之后，很容易陷入一种思维的惰性：只关注自己的一亩三分地，只关注自己生活的小九九；如果业务渐渐趋于稳定，或者公司的技术无关的杂事逐渐增多，很容易让自己迷失在这种环境下，并渐渐对技术失去敏感。每天面对一些自己已经非常熟悉的工作内容，没有动力去思考，只是改改业务的实现，群里吹吹水，时间长了，就只有工作年限的增长而没有技术水平的增加。长时间不作出改变，那么到了一定年限，必定会让自己成为一名高级新手，把自己的职场生涯开进了一个非常尴尬和危险的境地。
这种情况在国企，或者类似国企的一些公司是比较普遍的。虽然感觉上，稳定的环境、宽裕的时间好像能够让自己有更多的时间来进行技术的成长，但是真正能做到自我精进的人很少，大部分都是把时间拿来做了不相关的事情。反而是一些面临着很大的生存压力的小公司里的同学成长非常迅速，因为环境逼迫他们思考。这也跟时间管理有关系，此处不展开细说。
【从细小出着手，不要看不上自己的日常工作】
在之前一次面试的时候，BOSS问了我一个问题：公司里有很多同学觉得自己的日常事务非常繁琐，每天都是处理同样地事情，觉得没有成长，你怎么看这件事情？我想了想，这个事情可以划分一下，哪些是与人相关的事情，哪些是和机器相关的事情。如果是与人相关的事，那可以大家一起商量下，定个章程，怎么让沟通和效率更高，不要让冗长无意义的事务占用大家太多的时间。这其实是一个制度与沟通的事情，如果能够把占用大家的时间都降低而原先的事务也有效地处理了，那么我想大家也是很乐意去做的；如果是与机器相关的事情，那这是自己的本行了，可以在日常工作中，将自己的工作内容程序化、脚本化，把能够交给机器做的事情尽量都交给机器做，尽量降低这种重复性劳动在工作时间中的比重，我想这也是一个开发人员效率上的精进。如果觉得自己的工具不错，那还可以把它立个项，让大家都来使用你的工具，不断的迭代与升级这个工具，最终能够提升整个团队的工作效率。如果做出了影响，把工具开源或者做成产品，岂不美哉！应该说，BOSS对这个回答是很满意的。
当然，也不是说当时的自己就真正做到了这些，而是我觉得这应该是一个良性的发展方向。所以后来在碰到了持续集成的相关工具时，我就觉得一定要把这个东西运用到工作中去，再到后来学习了Shell脚本，一直走在一条不断提升处理日常事务的路上，可以说已经成为了一个刻在脑海深处的条件反射式的东西了。在《高效程序员的45个习惯》这本书中，作者提到了频繁集成，尽早集成，看到这一点的时候我觉得体会还是蛮多的。在之后的工程开发中，我不断的根据实际的工作场景进行脚本的编写，包含服务器上的Shell脚本，以及自己处理本地事务的Dos脚本，甚至是模拟一个初始环境，迅速在自己的服务器上搭建想要的各种中间件（脚本化搭建）。这对提升效率节省时间起到了巨大的作用，让我受益匪浅。
再到后来，接触到了一个CodeGenerator的工具，发现可以对工作中常常使用代码框架中，比较套路、规律的部分进行自动生成，我相信无论是前端、后端还是运维，只要是有代码要写，必定能够从这个思路中获取益处。最近打算用node结合vue2，electron做一个桌面版的代码生成以及其它日常常用功能的工具，支持自己快速开发。这样一来，就能够把精力花在处理架构的设计，业务的沟通和其它更重要的事情上，而不是日常常规的需求驱动、bug驱动自己对熟悉的代码反复敲，来回敲。
其实关于如何去思考，如何总结归纳，如何复盘工作，网上有太多的文章可以参考，如果你始终有一颗积极向上，渴望成长的心，那一定看过不少。是否践行，可能是另外一个故事了。这里推荐一篇别人的分享，我觉得写到了我心坎里。链接：https://zhuanlan.zhihu.com/p/139367834
这里摘抄一些比较具体的做法，供自己也供大家参考：
任何一件看起来很不起眼的小事，只要进行深入思考，稍微纵向挖深或者横向拓宽一下，都是足以让人沉溺的知识海洋。 举一个例子。某次有个同学跟我说，这周有个服务OOM了，查了一周发现有个地方defer写的有问题，改了几行代码上线修复了，周报都没法写。 可能大家也遇到过这样的场景，还算是有一定的代表性。其实就查bug这件事来说，是一个发现问题，排查问题，解决问题的过程，包含了触发、定位、复现、根因、修复、复盘等诸多步骤。 花了一周来做这件事，一定有不断尝试与纠错的过程，这里面其实就有很多思考的空间。比如说定位，如何缩小范围的？走了哪些弯路？用了哪些分析工具？ 比如说根因，可以研究的点起码有linux的OOM，k8s的OOM，go的内存管理，defer机制，函数闭包的原理等等。如果这些真的都不涉及，仍然花了一周时间做这件事，那复盘应该会有很多思考，提出来几十个WHY没问题吧… 再来说下总结沉淀。这个我觉得也是大多数程序员比较欠缺的地方，只顾埋头干活，可以把一件事做的很好。但是几乎从来不做抽象总结，以至于工作好几年了，所掌握的知识还是零星的几点，不成体系，不仅容易遗忘，而且造成自己视野比较窄，看问题比较局限。 适时地做一些总结沉淀是很重要的，这是一个从术到道的过程，会让自己看问题的角度更广，层次更高。遇到同类型的问题，可以按照总结好的方法论，系统化、层次化地推进和解决。 还是举一个例子。做后台服务，今天优化了1G内存，明天优化了50%的读写耗时，是不是可以做一下性能优化的总结？ 比如说在应用层，可以管理服务对接的应用方，梳理他们访问的合理性；在架构层，可以做缓存、预处理、读写分离、异步、并行等等；在代码层，可以做的事情更多了，资源池化、对象复用、无锁化设计、大key拆分、延迟处理、编码压缩、gc调优还有各种语言相关的高性能实践… 等下次再遇到需要性能优化的场景，一整套思路立马就能套用过来了，剩下的就是工具和实操的事儿了。 还有的同学说了，我就每天跟PM撕撕逼，做做需求，也不做性能优化啊。先不讨论是否可以搞性能优化，单就做业务需求来讲，也有可以总结的地方。比如说，如何做系统建设？系统核心能力，系统边界，系统瓶颈，服务分层拆分，服务治理这些问题有思考过吗？ 每天跟PM讨论需求，那作为技术同学该如何培养产品思维，引导产品走向，如何做到架构先行于业务，这些问题也是可以思考和总结的吧。就想一下，连接手维护别人烂代码这种蛋疼的事情，都能让Martin Fowler整出来一套重构理论，还显得那么高大上，我们确实也没啥必要对自己的工作妄自菲薄… 所以说学习和成长是一个自驱的过程，如果觉得没什么可学的，大概率并不是真的没什么可学的，而是因为自己太懒了，不仅是行动上太懒了，思维上也太懒了。
这些内容很具体，我觉得实操性也很强，我觉得对比一下手头的工作，很快就能够找到方向。只有一点，你是不是愿意去实践。
【关于跳槽】
在互联网行业中，跳槽的频繁仿佛是一种标配，两年一跳，一年一跳，甚至一年几跳很常见。但是就我之前的几份工作经验来看，对于大部分同学而言，频繁的跳槽会让适应成本变高，同时也没有办法真正融入进这家公司的业务，也就谈不上在技术上有什么成长。这里不讨论那些内心驱动力极强，知道自己想要什么，知道自己在干什么，也知道什么环境适合自己，目标明确的大神，我觉得自己没有这个见识和眼光来评判。对于大多数人来说，我认为这一结论是基本正确的。
就我自身的感觉，前几段工作，每进入一家公司，我都花了不短的时间来熟悉公司的人，技术栈，以及业务模式。从磨合到熟悉到自然，这一个过程往往就要花掉几个月的时间。如果是要了解共事打交道的同事们，可能需要花费的时间更长，如果要对整个公司有一个更加感性的认识，这个时间恐怕是以年为单位来进行计算的。
起码对我来说是这样。当对身边的一切都非常熟悉的时候，我才能自动地调动全部资源来处理自己想要深入学习的方向，在深入挖掘技能和积累业务经验来说，这才算是刚刚开始。熟悉了身边的一切，就能够花费更小的代价，更少的精力，处理身边的人和事，那么节省下来的精力我们才能去处理类似重要而不紧急的事情。
对于刚才说的，无法融入真正的业务，就谈不上技术的成长，可能由很多人并不以为然。我觉得很多同学会走进一个误区，包括我自己曾经也这么认为，就是一定要花时间自己去做某一个技术的研究，深入挖掘，就能够达到一定的水平。我觉得这个也对也不对，自己研究肯定是能够达到一定的水平，但如果不结合实际的业务的话，这个水平应该不会太高，时间一长细节就会遗忘掉。不结合业务来做，那么很多场景，很多困难，我们是无法想象的，只有真正进入到了真实的业务场景，我们才能谈得上有体会，有经历，有沉淀。我们需要遇到困难，需要讨论，需要不断地迭代才能够对于技术细节和人们关心但是容易忽略或者做不好的地方进行深入的打磨，这个过程是自己学习的过程中很难模拟到的。有些时候对于bug，其实是一种很开心的状态，因为这就说明我们的理解和事实的真相又有了一个更近的机会。就像读源码，如果源码顺利执行，我们调用api也顺利执行，那几乎不会对里面的什么内容有感觉，但是出现了一个bug，我们深入源码发现了为什么会产生这个bug，并找到了对应的解决方法，那这个过程一定是收获不菲的。我们应该认真对待每一个这样的机会，而不是放任不顾，或者用什么暴力手段处理掉问题，掩盖了这个bug的真实原因。
所以，结合自己的工作内容，在此基础之上，挖掘细节，透过当前的技术点，追踪源码，深入协议，了解VM，了解操作系统内部发生了什么......这完全是一个可以深入到底的路径。
【沟通和交流】
之前的工作经验中，有一段是做了创业相关的事情，几乎是体验了从商业的规划，立项，需求讨论，技术落地，运维上线这一整条链路的所有事情。我觉得对我来说，最大的意义就在于，让我明白了沟通和交流的价值。在之前的工作体验中，我也发现跟组里的同学多讨论也能够在很多维度上省时省事；而有了这次的经历，我甚至觉得如果一个开发人员没有意识去跟其它岗位的同事多交流，那么对于他来说成长肯定是大大受限的，好的机会也难得垂青到他身上。
有机会就要多跟身边的人交流，了解他们对于业务和工程的想法。在需求落地的过程中，勤讨论，多讨论，甚至是不要怕麻烦的讨论，才能真正有效地推动高效开发。于客户要了解心理，多多耐心培养他们对于软件的正确认知；与产品，要多多沟通需求的落地方案，整个项目的进度计划与节点，评估技术的风险与需求的紧急优先度，相互体谅才能和谐有效地推动整个工作高校向前；于测试，要沟通交流自己觉得可能有问题的地方，讨论需要着重测试的逻辑和功能点......有了这些沟通，我们才能加深对于项目的认知。要知道，很多时候，一些经验是可以套用的，这也是成长。
说外身边的交流，我们来说说外部交流。
最近加了一个技术交流群，大家会在群里吹水，但是一旦有人发了遇到什么技术上的难题，也会有一群人利用自己的专长来进行解答。在这个过程中，我发现自己的眼界开阔了。原来对于一个需求，A公司是这么做的，B公司是这么做的，而奇葩的C公司居然敢这么做！不仅仅是了解了各种公司的氛围，知道了各个公司的优点缺点，也了解了技术人的生活状态，对于技术上的一些观点、看法、用法，大家都有不同的处理方法和认知，我觉得这个过程对比自己去一家一家的体会，那是指数级的成长。所以，多泡泡这样的群，也是好处很多。而且，知道有这么一群同行的人，也会让自己在探索的路途多了一分乐趣。这样的群里也会认识很多个性迥异的优秀coder，我就觉得这样的人还是有很多共同点的：对于工程有足够的兴趣，能够深入去了解事物的原理和本质。多认识一些这样的同学，也是能让自己飘起来、浮躁起来的心给沉下去，好好做自己的事情。
加油，共勉！