@jianhua.cheng
2018 年终总结
February 04, 2019
工作
今年，随着公司可喜的进步发展，工程师团队从开始的小团队日渐扩张到现在人数客观的”大“团队，在年初公司的组织架构也发生了变化。此时也成立了我比较关注的“Client Infra”组，这是一个“大前端”团队，有着 Android、iOS、Web 以及自动化测试的团队。因为我此前一直在做的事情的缘故，我来到了“Platform”组，其中负责的是中后台的任务，主要是后台管理系统的建设以及部分服务于多业务的 2C 移动端项目。因为在当时我是前端工程师中对公司业务最熟悉的人抑或是加入团队早的缘故，为了更好的协调团队内前端工程师的工作，我被赋予了一个“协调者”的角色。我能够解答新人一些对公司业务的问题，以及回答一些技术上的考虑；在工作中我需要注意一些需求在工程师的角度抑或是团队的角度放在何处来解决而是合适的；我需要和其他的前端同学进行 1 on 1 并在我与 leader 1 on 1 时将我收集到的以及我自身认为可改进的内容反馈给他。这个过程中开始有些忐忑，但是后来更多的还是对自己的自信以及越发对协调这件事的认可和得心应手。我相信我能让我们团队中的前端同学能够协调得更好，同时我也希望能够跟大家一起获得更多的成长机会。
到了年中，平台组中的前端同学也变多了，此前的新同学也比较熟悉公司的业务了，我按照一开始的意愿选择了希望加入“Client Infra”，并也被准许加入了。在成立这个团队前，我就一直很乐于关注前端的工具设施、新技术并也做出了一些“公共”的贡献。对于在“Platform”中我的角色以及相对较为舒适的工作，我还是选择了希望能够不断地专注解决一些不好预估但是更具有挑战性的工作，这个选择符合我一向对自己的成长方向的期许以及个人风格。这两个选择没有明确的好与不好，是以一个“协调”者的工程师身份逐渐探索管理的能力还是作为个人贡献者解决不可预知更有挑战性的问题，我在偏好与个性中自然得出了答案。
在这大半年的工作中，我收获了不少，也有了一些反思和期望。
前端服务部署
这是一个基于 Kubernetes 实现，专于提供前端服务的轻量部署系统。能够做到让前端零配置即可部署一个服务，以及在快速迭代下，保障稳定的构建和部署，使我们的项目真地做到便利高效的持续集成和持续部署。极度简化了 Web 服务的建立，适应于业务快速发展下项目日渐增多的现状。
同时这也是我这大半年来主要的工作内容。涉及到的技术有 Node.js，Golang，Kubernetes。为此了解了 Kubernetes 的概念及其基本使用，使用 Golang 编写其与 Kubernetes 交互的逻辑，Node.js 完成用户交互的业务逻辑。这些给我带来了非常大收获，使我了解了 Golang 这门语言；熟悉了 Kubernetes 的概念以及使用方式，对运维相关知识多了些了解；同时使用 Node.js 开发后端服务让我对 Node.js 更加熟悉，对一个 Node.js 应用的建立和维护以及需要解决的问题也多了些理解和经验。
对于一个专职且主要精力都在前端的工程师来说，这部分知识的补充能够赋予我从用户到服务器这中间多段链路的全局视角，对为用户提供 Web 服务有了更全面的认识，一定程度上面避免了我们在为用户提供 Web 服务时因为视角的局限性而无法定位到更关键的链路来解决问题。所有的这些都能帮助到我今后理解一个系统内服务间的协调关系，以及更好得利用这些运维知识来赋能前端服务。这样一来前端能够轻松获得以及利用公司的服务基础设施。
但是从个人的主观角度来看，我对我掌握这些知识这件事本身就有困惑和疑虑，那么接下来我就谈谈对个人成长以及选择的一些考虑。
因为缺乏相关经验以及专业性，且考虑到人的精力是有限的，我相信且也不得不相信我应该无法在这些事情上做到精通且同时不影响我在前端方向上的成长。对此我也有过困惑，也与当初赋予我这项任务的 leader 沟通过，他对我花费精力做这件事给予了肯定，我也很能接受。但是可能在沟通前我心里应该就有了答案，这件事情我该做，且也是受益巨大的。我犹豫的是认为自己在 Web 前端这个细分领域下还没有做到足够专精的情况下，耗费这些精力成本获得的收益可能不是长久的，“通用”的。“一精多专”，首先需要“一精”再是“多专” 的观点被许多人认可。现在这个问题就变成了我认为较长时间不接触前端技术圈，而是获得一些并不精深的后端，运维知识违背了先“一精”再“多专”的时机选择。但是我知道能够在前端工程师的工作范围内接触这些知识并运用它们对我的个人成长以及完成团队目标都是一件好事情，在这个年终，这个项目也取得了一定的成果，我也确实收获个更多的知识已经开阔了自己出前端以外的视角，在前端方面我依然存在着我独立的判断力。我对 “学习能力是一个工程师的核心竞争力” 更加深信不疑，不过在面临庞杂或精深的选择时依然需要做出合理的选择，每件事情都是对的，但是只有在对应的前提和基础下某些选择才是“对”的。
其实这个决定和认同的产生并不困难，但是它引发我对自身的思考这一点是需要在意的。学习或者说是成长都是 “逆水乘舟，不进则退”，在面临选择和方向的时候，我又一次确定了自己的核心认知并在结果中肯定了它，这是我今年很大的一个收获。
工具包
因为需要将公司内经常做的一些事情给抽象封装起来，我和团队内的同学分配了一些各自负责的任务，我完成了例如埋点，工具函数等。这些都需要对解决方案的设计以及对许多情况的考量。
为了考虑工具能够支持在浏览器以及小程序中使用的同时又降低我的维护成本，保持统一性，我参考了 react 项目的构建方式，从中学习到了在构建时通过编写构建工具的插件来完成我的目标。
为了了解如何更方便地解决环境变量的配置以及选择以及我从 babel-plugin-macros 中获得的灵感，我决定实现自己的 macro 来解决问题。顺藤摸瓜我了解了 babel 的大致思路是如何将代码处理成 AST 并进行后续处理。通过这些了解我编写出了迄今为止我个人唯一一个能称得上是 npm package 的 penv.macro。
为了能够让 API 的 “Breaking Change” 能够轻松得转换成新的 API，我了解了 “codemod” 并通过对 react-codemod 等成熟解决方案的参考完成了 codemod 用于解公司内部包的大升级时导致的调用方式变化，一个指令即可将旧代码转变成新代码。
在这个过程中为了更好的保证包的质量以及方便我的维护，我了解了 lerna 这种 mono repo 的方式来管理包；为了更好的使用 rollup 以及方便打包，我了解了类似 react-scripts 的方案来打包我的包，借鉴 kcd-scripts 后我定制成了自己的 packages-scripts；为了保障质量我现在已经在近两年的实践经验中能够熟练的使用单元测试保障它。
诸如此类的我就不一一列举了。在这一方面我今年并没有做的非常特别，更像是经验值的累计以及对自己想法的不断测试和验证。我了解了更多的开源项目，我不断地思考我遇到的每个问题下的多种解决方案，我有了些许自己的创意，不仅是阅读和模仿。这让我收获自信的同时也有更多的紧张感。新事物层出不穷，大多数时候我对这些变化甘之若饴，充满热情，偶尔也会有疲倦和懈怠的情绪。我就像一个登山者，不断地征服越来越高的山，但是我认为我征服的山还不够高。我能了解中小型工具的实现和设计，但是对于 react 这类复杂的项目我还没有抽出时间来认真了解，我仍然只是一个使用者。不知是对于著名项目的“敬畏”还是对自己的不自信，抑或是想做的事情太多，精力不够。我还不能确定我能吃透这样的复杂度以及做到更加的胸有成竹。所以我在今年给自己留下了这个困惑，但我相信我能在下一年消除自己的担忧。这将是我今年要攀登的下一座山中的一峰。
任务管理
转入到“Client Infra”后的工作和之前最大的变化在于自主性，此前的工作任务基本上都是来自产品经理或者其他需求方提出的明确需求，我的任务只是将提供的以自然语言描述的解决方案翻译成程序语言描述的解决方案，其他的不需要过多关注。但是在“Client Infra”中因为我们是直接服务于开发者的，且我们并没有一个专门的角色负责来提供场景下的问题描述以及对应的解决方案，所以这部分的职责身为开发者的我们也同时担任了。虽然我们可以从与业务方的定期周会中收集到需求，但是还有很多时候我们需要先于其他人发现需要解决的问题，并且自行得出解决方案的设计；其中很多创造性的任务是无法准确估计完成的时间。
这些问题在初期让我不适应，可能也是半路接手的事情较紧急，也没有习惯于建立良好的任务管理，大多数时候凭着感觉在完成任务。缺少对任务的拆分以及中间状态的及时同步。有些时候做的事情存在于脑海中并没有在任务管理中记录，对任务的估时也难以下判断。现在看来对任务的估时难以下判断除去创造性任务的难以估时外，还是存在一些个人的客观原因的。一方面是经验不足，用于估时的参考比较少；另一方面是不够自信，缺乏对自己完全负责事务的决断心，这个意思是不敢完全担下错误估时导致的责任，因而踌躇犹豫。
不过在经历了半年的工作后，现在也逐步改进了。现在我能在出现需要解决的问题时将问题以超出大多数人的详细程度描述清楚问题，并按照背景，解决方案的形式来记录。即使是线下的讨论也会将关键的讨论过程和结论补充到任务管理工具中，中间状态也会及时更新。很多时候明确了责任边界以及决断权的时候也能比较自信的估时并放心因此可能会有的责任问题。这带来的另外一个启发是：在工作中，明确责任边界以及决断权的范围之于协作是至关重要的。不明晰的边界容易导致”踢皮球“以及推进动力不足的问题。
同时，因为任务是自发性建立的，且我们的工作是服务于其他开发者，但是在解决问题的过程中有时候我以及组员们会以一种”完成了再说话“的方式来完成项目。这样的问题是他人难以了解我们所建立的任务在什么时候会完成，以及在什么时间会有哪些项目开始。所以开源项目中大型项目的 Roadmap 也是我们需要借鉴的方式。清晰的路线图能够帮助他人指定计划以及安排资源。
以上都是工作中涉及到的任务管理，但是个人的任务管理仍然从中受益，只不过大多数时候没有投入时间到个人项目和计划中。
个人
大部分的我没有将工作和个人的技术成长区分得很开，在技术方面的个人成长大多和工作结合在一块。所以个人方面我只谈谈技术之外的事情，可以是对技术成长的一些体会也可以是对自身的一些想法。
看了下豆瓣中的统计，发现看的书是越来越少了……对于现实的焦虑，今年看了两本比较初级的理财相关的书，基本上来说就是开源节流，至于如何做到开源，工作之外的方式脑中仍无想法也未有行动。节流倒算是做到了降低了自己的欲望。以前会认为降低欲望是难以启齿的，是没有办法的办法。回归现实，这确实是没有办法的办法，但却也是个合理的好办法。等到真地降低了欲望的时候，才发现想买的电子设备，想换的手机，想换的平板都不是自己真正想要和需要的，不需要它们对我的生活毫无影响，我最在乎的远不是这些。但是降低欲望不等于降低自己的期许和逃避问题。这些只是使得能够让自己计较，不快乐的事物以及焦虑的来源又少了一些，程度轻一些。但这已是很好的一件事了。
最近在读《亲密关系》，这本书分析了许多人与人相处之间的心理活动。很多观点都对日常生活具有很大的借鉴意义，其实当初就是为了拯救我的榆木脑袋，希望能让我和女朋友相处得更加愉快。可能读书读的少，偶尔一读就能感受到收获……平时总会以工作忙为由忽略这方面的投入，心里认为这读书是好的但是并没有真的去看书，这就像我们软件工程师眼中的“单元测试”一样，明知道好，但是这样那样的借口和担心使我们踌躇不前。
今年的一年在我看来做得最差的就是没有平衡好工作内外的时间安排，对个人成长的焦虑感使然，过多的将精力以低效的方式耗费在工作或技术相关的事务中。如此对时间的利用投入产出比是很低的，既对个人成长意义不大，也牺牲了陪伴女朋友的欢乐时光。没有真正学习和采用高效的时间管理是这一年的主要问题。曾经我对所谓的“方法论”嗤之以鼻，认为过于违反了人的天性以及僵化。但是现在我不这么认为了，这种傲慢的态度无疑是没有任何意义的，合理的利用时间管理的方法论是我们这些初入职场的新手以及想要获取进一步成长的人都需要具备的素质。
也长也短的一年化作了这冗长的一篇总结。我就一些具体的问题详细地描述了我在一些在过程中的思考以及而后得出的反思。每个人因环境不同，自身不同而经历不同，我就我这一年的经历给自己一个总结反思的机会，我的目的达到了，同时也希望我的思考也能给其他人带来些许意义。
