自我的阶段性总结
随感
阶段性地写一些自己的总结经验至关重要，但是之前却没有任何行动力将之落之行动。这方面可以找到很多原因：没有时间、没有积淀、个人的碎碎念难登大雅之堂……但是归根结底逃不过一个字：懒。时间挤挤总会有的，个人的博客也很难称之为大雅之堂，一些之前的碎碎念很早之后再翻翻看，说不定有着别样的理解。打破自己的懒惰和“矫情”，正是我当前所做的事。
之所以觉得自己非要做总结不可了，也是我近期发现自己的记忆力真的不够用了。“好记性不如烂笔头”真是一句实话，哪怕有一些心得感悟记在心里了，时间一长还是忘的一干二净，就算没忘细节也忘得差不多了。
而魔鬼就在细节中。
之前考虑过个人的IDP，给自己立了这么一项：一定要形成自己的方法论，而不是完全凭借“感觉和经验”。方法论可以不完善甚至是错误的，这个可以通过学习、实践等逐渐完善。如何进行方法论的积累、完善和进化？光靠头脑可不靠谱，阶段性总结必须要做，而且要频繁做，长期做。
要形成方法论，而不是凭借感觉和经验
这一条我认为是最基本的，也是当前我最应该做的。写感想总结就是其中沉淀的总要一环。正如一次个人发展规划学习中学习到的一句话：“这个世界上你遇到的所有问题基本上都有其他人给出了答案，你所需要做的就是去学习。”学习、实践是个人的经验积累，我工作5年多，不管积累多少，总归有些收获。但是只靠经验是完全不行的，会让我陷入经验主义的误区，解决问题的能力完全局限于之前的经历和他人的道听途说，或者一不留神就会陷入“熬资历”的过程，对个人的成长来说也是一个危险的信号。
实践是检验真理的唯一标准，学习、实践、再学习、再实践，归根结底是为了解决问题，而有一套自己的方法论，则是解决一切已有问题和未知问题的利器，也是一个“经验丰富、能力很强”的专业人士的专业壁垒。
方法论的形成不是一蹴而就的，自我方法论的形成不仅仅是表面上的总结那么简单，需要自己不断地总结与完善，在实践和学习中应用和思考。网上也有很多专业人士的心得，但是自我方法论和别人的总结最大的一个区别就在于自我方法论的形成是自己实践过的、经过实际应用检验或者待检验的自己的方法论。正如看一个算法苦思冥想，就算明白了过一段时间也会忘的一干二净；而真正程序中应用过了，就会发现其中的关键所在。看别人的总结学习的过程，应用之时就是经验的积累，而应用之后和知识点结合总结的过程，才是自我方法论的形成。
既然是需要完善，保持谦逊和虚心学习同样重要。在和别人争的面红耳赤差点大打出手，最后发现还是自己的方法论有问题，那么该低头还是得低头，该认错还是得认错。面子不重要，个人成长才是。
在实践中学习，而不是只学不练
在形成自己的方法论的过程中，学习是重要的一环。据我近些年学习的经验，抱着一本书或者一堆视频啃，收效甚微。就算偶有所得，也很难应用，随着时间的拉长而逐渐遗忘。但是真正应用过的知识，就算不去刻意记忆和背诵，在遇到类似的问题时却会主动地从脑海中跳出来。只学不练和边练边学，吸收的知识差距差的不是一点半点。
我高考之后花了一个暑期时间研究erlang语言，如今只记得一个名称；我反反复复研究了好几趟rust，不如上次写了两个rust程序来得印象深刻，哪怕其中一个只是模拟账号注册的客户端，另一个只是接受prometheus的告警回调然后发短信；弄懂了不少hard级难度的算法题，不如实际动手写出几道简单或者中等难度的题来得深刻，而且后者的实际使用机会远远大于前者。会用永远比弄懂重要。
对于学习到的知识“系不系统”，我认为在“发现问题-解决问题”的循环上去研究解决各种拦路虎，这样沉淀下来的知识本身就是“系统”的。就算边练边学的知识体系不系统，在应用时也比只进行“系统学习”来得有效的多。在如今一个讲究快速学习和成长的时代，效率就是生命。
但是也不能陷入另一个极端：纠结各种细枝末节越陷越深，而忽略了核心思想。比如我去实现一道算法题，在c++、rust、golang、java等各种语言之间来回切换，纠结于各种语言特性，而写来写去算法本身就是一道easy题，没多少花哨。这个世界上并不缺代码，缺的是思想。优秀的研究工作者为我们提供了很多优秀的思想，我们要去学习，要去实践，要去应用，用其创造价值，而不能局限于其他的边边角角，买椟还珠。
其实这一条的道理也是很简单很直白，甚至可以说是常识。但是自己却经常跑偏，值得时刻提醒自己注意。
解决问题，而不是完成事情
这一点在最近工作中深有感触。完成了一个平台，给的任务是需要每个业务方都接入，但是业务方不上心甚至有些抗拒，怎么办？
咨询了一个大佬，大佬说你先总结一下他们的痛点，然后针对性地提出新的方案，利用新平台解决了他们哪些痛点，然后发一封邮件出来到达能够拍板的人，如果给出的方案依旧不能接受，再由领导出面。最后我发了一封邮件，让业务对接人牵头由业务方内部产品部门进行了讨论，进度得以推进。
虽然是一件很小的事情，但是却足够引起我的深思。在平时的工作中我一直有意识地去学习大佬们是怎么考虑和解决问题的，发现有一个很重要的共性在于，一个问题的思考和解决一定要从本质问题是什么，而不是当前面临的问题是什么。一个需求很难实现、技术难题很难解决，除了硬刚展现技术实力之外，其实可以跳出思考一下这个是问题的本质吗？真正需求方是否不关心这个？其他替代方案是不是更能有效解决问题？
之前听过一个名词，叫做“向上管理”，直观上就是说“把自己当成领导，解决领导真正关心的问题”。领导关心什么样的问题呢？答案不是唯一的。但是一旦开始这样思考，就会发现不一样的世界。
从实际需求出发，而不是从设计出发
最近在做一个项目，发现整个流程和工作流非常类似，顿时打了鸡血，在工作流上研究了一通，整体架构设计上也是完全按照这个来，加上事件驱动、消息队列，整体显得大而复杂。但是评审的时候才发现，真正的需求没有这么复杂，业务方不关心，这种过度设计的后果却是导致和其他人沟通困难、排期较长、可靠性降低。
不管是架构设计也好，程序代码编写也罢，它们一定是由其业务价值的。在满足业务价值的基础上充分简化其设计，这正是一个好的架构师或者开发工程师的目标。设计规划的根本目的是控制系统复杂度，做加法很容易，做减法很难。
当前流行的敏捷开发其核心也是如此：快速迭代。首先有一个小儿可用的系统，然后通过迭代做大做全，快速产生商业价值。这也正是毛泽东思想的精髓：“抓住主要矛盾”。其实不仅仅是软件开发，包括自我的学习也是如此：先学习核心内容，再在实践中逐渐系统化和完善化，化为自己的经验，形成自己的方法论。人生苦短，知识爆炸，必须让自己“敏捷”起来。
沟通与表达比技术和学习更为重要
对于应用类技能，输出是王道。软件开发的过程其实也是输出的过程：输入的是各种需求和规划，加上自身的技术和经验储备，输出一条条满足需要的代码。程序运行的过程也是”人与机器沟通“的过程，让机器按照我们的需要有所产出。
但是人的精力有限，真正的需求也并非一个程序就能满足。我们需要更复杂的系统，这个系统的实现就需要各种角色的人与机器进行沟通表达达成一致，通力合作才能实现。之前我们只需要让”机器懂我“就行了；而现在，我们需要让”大家懂我“，然后”我也懂大家“才行。
我个人的表达能力一直很有限，随着工作之后改进了很多，但是还是没有达到令自己满意的程度。”将自己大脑中的东西灌输给别人并让其接受“远远比”让机器知道下一步要干什么“要难得多，也重要得多。我不想自己学了很多东西但是没法有效表达出去，我也不想别人从我这会意到的并非是我的真实想法。
结构化思维是一个好东西，在做一件表达之前先表达核心想法，然后列举各种情况，包括正例和反例，最后做一个总结。这是我目前学习到到一个让自己表达更有条理的方法。但是要做到更为有效的表达，更为清晰、流畅、准确、全面、打动人心，自己还有很长的路要走。
自我管理
说到管理，我的第一反应就是管理岗位。我一向认为自己是没有管理才能的，没法管理住人，所以一直考虑技术路线。但是经过深思，才发现管理无处不在，而管理能力的强弱决定了自己的上限。
对于个人，我需要管理自己的时间分配、生活和饮食习惯，需要管理自己的金钱、精力和情绪，管理自己的体重，管理办公桌的物件摆放，管理自己和家人的关系；对于开发，架构设计与代码逻辑设计本身就是为了管理代码的复杂度；架构师还需要管理需求的支撑进度、后续开发和测试人员的投入时间、系统运维和运营成本、系统本身落地的各种风险；对于管理者来说需要管理的就更多了，管理他人的工作、时间甚至情绪，提升他人的产出，为公司产生更多价值，我想这正是管理者的职责所在。
管人可比管里软件困难多了。对于当前的我来说，需要做到的首先是“管好自己”。管好自己的时间，管好自己的精力，管好自己的人生规划。我必须有一个较为清晰准确的目标，而各种管理就是为了让自己更好地达成这个目标。这很难，但是我必须开始行动。
要有取舍
取舍真的很难，但是却很常见。为了控制体重，我必须注重饮食，也就意味着不能喝一些发胖的食物。当一杯免费的奶茶放到我面前，而我因为自己的“控制体重”决定必须放弃时，我相信当时自己一定是痛苦的。
取舍有时候很简单，只需要选择最重要的一个就行了；但是问题往往是自己并不知道哪个才是最重要的，或者已经知道重要的是什么了，但是为了达到这个目标，代价让自己有些难以承受。
对于生活上的取舍，有时候痛苦的根源在于自身的懒惰，这时有一些办法可以让决定做得更为轻松点。比如“肉体带动灵魂”，我觉得就十分有用。如果我必须要学习，我就先什么都不想，带上书本去书店，看几页书；如果我有一件重要紧急的工作，立刻进行任务拆解；如果我必须早起跑步，早上闹铃响过之后就什么都不想先把衣服穿上。这样过一段时间就会发现，自己好像养成了了不得的习惯。
有一些取舍源于自身安排的不合理不得不取舍，这个时候“四象限法则”就有用武之地了。重要紧急的事情立即做，重要不紧急的事情优先做，不总要紧急的事情外包给他人做，不重要不紧急的事情不去做。哪怕是一件长期看比较重要的事情，但是当下没有时间也不适合去做的也可以不做。这种自我的时间管理其实也是取舍的过程，需要持续摸索出一套自己的管理方式。
有一些取舍难的根源在于对未来的未知。对于架构师这种情况很常见，取舍的理由往往没有那么直观，这时就需要依赖于自己的经验和方法论了。只有先实施，然后对比结果，不断复盘，修正自己的方法论积累，才能让自己在未来更为游刃有余，成为一个“有能力”的人。
个人发展规划
对于自己的未来发展其实之前是有做过类似的计划的，但是实施起来并未完全按照设想进行。一份太细的规划可能并不适合我，但是一份清晰的长远计划还是能给予自己不少帮助的。
我的初步设想是前几年提升自己的专业素质，成为一个合格的专业的技术从业者。目前看是已经差不多实现了，但是用了5年的时间。这几年的时间里很多知识积累与技术成长很快，但是一个明显的问题是多而不精，没有一个自己深耕较久积累较为深厚的领域。目前可以选择的方向太多了，但是很遗憾，个人精力不允许齐头并进，必须做出取舍。如果全抓不放，必然会导致深度不够。
对于下一个5年计划，我的初步设想是着力于架构、中间件等技术方向或者是具体的业务领域方向，着重发力，形成技术深度；同时以博客、社区、项目等方式进行输出，提升竞争力，做出一定的成绩。在此同时让自己的沟通合作等软技能得到充分锻炼，不再成为自己的短板。期间肯定会遇到很多问题，通过课程学习、向他人学习、自我总结、业务复盘等多种方式，做好自我管理与取舍，辅助自己成长。
成长的过程很是痛苦的，但人总会成长的。祝我早日成为自己期望中的那个人。