2017年年度总结

今年的年终总结特别难写，迟迟无法下笔，以至于每年养成的12月底写个人年终总结的习惯都无法维继，至于原因，大多是因为随着年龄的增长，看着之前年年写的总结，越发觉得无足轻重，然而更深层的原因，可能也不是因为自己越来越施展开来，而只是看到的越多就越发敬畏。

忆往事

去年几年，可能唯一值得一提的事情，一是遇到小我五岁的女大学生，然后在她还没有毕业的时候领证结婚，她勇敢乐观，这给我的生活观和人生观带来极大的改变，在去年一年的时间里她辞掉幼师的工作，独自学习日语研究教育学，然后健身、会友、甚至参加公益话剧演出，看似轻松，实则在这个忙碌的社会中，并不是所有人都可以在这种生活方式下自得其乐，要么为金钱所困，要么为孤独所惑，要么执念于成就，要么颓废于无所事事。在沉寂一年后，2017年12月的时候她开始筹备自己的公司，一个有愿景的小梦想，通过幼儿教育慢慢改变小世界，我很支持她也很相信她，我在她身上看到了太多自己不具备却极其尊崇的特质。

第二件事情，其实已经离我渐远，只是回忆起来总是无法忘怀。每个程序员都有一个通过自己的想法改变世界的梦想，曾经我也小范围做到过，一个有温度有情怀的产品，被许多人所接受，给我个人带来的影响至今犹在，当初做这些产品的时候抱着单纯的初衷，带着学习探索的态度，后来投入大量精力以让它们影响更多人的学习和生活的方式。虽然现在已经完全没有精力关注类似的领域，但是那种感觉无法忘怀，我相信有一天我还是会去寻找类似的快感，带着初心重新开始。

说正题

然而，总结终究是要写的，写给下属的，写给上司的，写给公众的，前两种总结近期写了不少，在几个年终总结会上，虚的、实的、好的、坏的，都不下一次，开始觉得压力很大，要为诸多人负责，也要为自己争取，而又觉得自己诸多不足，偶又觉得信心满满。后来，事情越理越顺，方向也越来越清晰，感觉这一个跨年之季，把去年做的诸多事情抛之身后，成长反而是最多的。

但该总结的还是要总结，一是写给未来的自己看，二是写给现在的读者看，自能看到自己想看到的。

本文主要包含三部分

一、讲讲去年一年我们团队在做什么事情 二、讲讲我对一些软性问题的思考 三、讲讲去年我自己的生活

讲团队

今年，在职业上其实挑战还是很多的，只是可能在职业上遇到的事情实在太多，一年下来竟觉得理所当然没什么可以拿出来讲的。不过依稀回忆还是可以讲讲几个里程碑。

去年年底，公司技术团队重组，对我来说最大的改变，带的团队从业务团队变成了纯架构团队，我开始从各种业务中退出，不管是前端业务，还是服务端业务（Nodejs），在这个过程中，我需要为自己寻找方向、寻找工作边界、寻找价值体现、寻找工作方式，同时也需要为团队的成员寻找这些方向，并且团队还新增了客户端的子团队，这的确极富挑战，经历过混乱、探索、稳定这些阶段后，现在我对自己团队的价值体现、工作边界、运作方式也算心里有底了，这些我在第二个话题里会详细分享。

重点讲讲今年团队做的几块大的事情吧。

1 Nodejs 在公司的价值探索。在 Nodejs 退出公司核心业务的服务端体系的前提下（Nodejs的人员规模和生态都无法支撑公司业务的指数级增长），我们迷茫过，也尝试过，最终在开放平台和应用网关等与业务中立的服务端领域取得了显著的成绩，特别是开放平台，虽然它是业务中立的，但是今年我们公司与无数公司有正向和反向的业务对接，所有对接都要经过开放平台的管理和规范，包括在金融方面与一些银行和资金方的对接，承担了公司非常核心的价值角色。这仍然是我们团队2018的工作重点，规划可以列一条街。另外今年还有一块非常出色的服务，那就是一个独立系统，支撑公司所有和“消息”这个词搭上边的中立服务，短信、推送、聊天、长连接服务、邮件、钉钉，这是一个数据量巨大，业务方巨多的服务。对于这些 Nodejs 承接的基础服务，除了“实现”，我们更关注他们管控诸多对接业务的能力，以及服务这些业务的能力，要实现这些目标并不容易，需要能够静下心来构建各种管控体系，非一朝一夕之事。

2 ReactNative 的全面推进。经过 2017 年一整年的体系构建以及推进，目前整个公司已经有五十多个业务在使用 ReactNative 构建，这是一个从顶至下强力推进的事情，现在公司基本所有移动端新业务都优先 ReactNative，为了支撑这个战略级的推进，这一年我们围绕 RN 的开发体系做了很多事情，从开发管理到工作流、集成方式、热修复管控、开发框架、组件库，经过几次大的迭代，都已经趋于稳定。而在 2018 年，事情还在继续，我们在将 RN 与 Native 做更深的融合，模糊大家对 RN 和 Native 的概念，互通能力和开发方式（RN 开发多由 Native 开发承担，以及端上强融合），公用各种 Native 基础设施，以及一些极致的性能优化等事情，感兴趣的同学可以深入私聊。

3 工程方面的积累。面对前端开发人数以及业务数的爆炸，以及 Native 开发加入到 RN 开发的大军来，我们今年对整个前端的工程体系做了诸多统一的优化，从开始开发到最终上线，中间的诸多工作流，我们都渗透了诸多工具和规范进去，与许多部门一起配合构建了规范的前端工作体系，以支撑团队的快速膨胀和业务的快速扩展。我想这也是架构团队存在的重要意义之一。

4 开源。虽然内部诸多系统均按照产品化甚至是开源规范来推进，不过今年最终开源出来的最大的项目还是 GitHub - easy-mock/easy-mock: A persistent service that generates mock data quickly and provids visualization view. ，为社区贡献更多的开源项目也是今年我们的目标之一，另外开源也不只是纯粹的输出社区，按照开源规范来要求自己，也是我们规范团队工作方式，以及代码质量的一种方式。另外，今年也有向外分享输出一些我们的解决方案，例如把前端从管理系统中解放出来的 React For Java（一个可以在 java 代码中写 React 数据和逻辑的方案，所以我们公司的管理系统都是 Java 开发自己写的），还有我们和 RN 相关的一些解决方案等，感兴趣的可以细聊。

5 社区活动。今年年底重启 NodeParty，组织了两次聚会，创办了一个基金会（ GitHub - Hangzhou-Node-Party/Node-OpenSource-Foundation: NodeParty 开源基金会，开放透明的收入和支出，用以回馈社区活动、对社区有贡献的个人和组织等。 ），虽然后来年底大家事情太多再次停滞了，但是觉得这个事情很有意义，而且手里也有各方面的资源，今年我想在这方面还是会做一些事情的。

侃大山

上面列举的实事，大部分都是团队合作输出的结果，我更多时候是起到协调的角色，帮大家寻找方向、寻找资源、聚焦方向、把控边界，所以这些成长其实更多是团队整体的成长，而对于我个人来说，大多成长其实是软性的，无法用言语表达清楚，更无法用数据或者其他什么去衡量。

今年最大的改变是所带团队人员和方向的调整，从之前单纯的角色划分的团队转变为职能团队（架构团队），从宏观上来说，这是一个很正确的方向，团队可以更专注于输出某方面职能，而不是混作一团，一边关注技术一边梳理业务，很难平衡各方面的比重，这也是我之前最为苦恼的一个问题，对我个人来说总是把关注点更多放在技术方面，但是又深知需要关注业务的发展，但是却很难在个人精力和人员管理上做到平衡。今年有了新的团队和角色之后，很多事情都慢慢变得清晰起来，当然转变的过程并非一帆风顺。

一，什么是“业务”？什么是“架构”？架构不是单纯的代表所谓“高级”“复杂”“好玩”的技术，而是要切实解决团队的一些通用或者底层的问题的一个职能的美称，架构无法完全脱离业务，架构必然是为业务服务的，那架构和业务的边界是什么？一个技术或者开发上的问题出现后，怎么判断他到底是应该架构组去解决还是业务团队自己去解决？这个问题的核心就是：如何划分业务和架构的边界？业务团队并不是不需要关心技术细节只是从事重复的生产，架构团队也不应该只是关注产出解决方案却无法落地到业务，然而每个团队有每个团队的痛点，在这方面，我们不同阶段有不同的尝试，不同时期大家有不同的理解，一直在不断优化这个“边界”。

二，什么是“前端架构”？架构这个词听起来有点玄乎的成分，什么角色，加上架构两个词就听起来好像高级起来了，但是在我理解来，架构只是一个开发角色而已，并没有什么特殊的。另外针对前端，“架构”一词的含义更多时候其实与传统的架构并不是一回事，更多时候是关于“工程化”，这个工程化包含了与开发相关的方方面面，解决的是效率、稳定、规范等方方面面的问题，通过方方面面的手段和方案。只因前端天生的分散性，我们解决的问题更多是如何在不同的项目之间更一致、更高效，而不是如何分离、解耦、组合、管理。当然不排除有本身非常复杂的系统需要做真正的“架构”，但更多时候，还是用工程化来描述架构团队的工作更为贴切。

三，架构团队如何工作？这其中最大的挑战就是，架构团队不对接业务，没有业务方，没有产品经理给你产出需求文档，没有设计师为你产出交互稿，没有项目经理为你跟踪项目进度，甚至没有测试为你保证质量。这是一方面的挑战，为此我们除了让每个人有自我推动的意识，还需要在团队中制定一些规范的独特的工作流程，以保证我们的解决方案可以顺利落地。另一方面，因为没有帮你做推动的角色（也就没有可以甩锅的角色），所以很多事情都需要亲力亲为，这就需要架构团队的成员反而要拥有比业务开发更强力的推进能力，可以协调各方配合你完成方案的产出和落地。所以架构团队绝非是一个只专心于钻研技术的团队，这可能是很多人容易误解的地方，在团队最最开始创建的时候，我时常跟大家讲一个衡量标准，一个架构师，写代码的时间不能超过自己工作时间的 20%，这80%的时间，要用来产出方案、与业务相关方讨论优化方案、与老大确定最终详细方案及文档、方案的分解、优先级、里程碑、排期计划、产出使用文档、产出单测、跟进落地计划等等等等，这些事情对有经验的程序员来说比写代码更有挑战，如果一味的只想写代码，那其实是一种精神上的偷懒。

四、另外还有一个挑战，就是多角色的磨合，在我们团队，有 前端、Nodejs、iOS、Android，很多方案都是需要各个角色配合产出的，这其实是非常有挑战的，首先各个角色技术栈的能力不同，做事情的方式不同，考虑问题的方向不同，很多方案需要各个端各自实现类似的逻辑，难保某个端没有按照约定实现某个逻辑，这时候就需要建立非常强的信任感和责任感，才有可能促成一个大型方案的产出，另外还需要有一个主导者，对各方的技术都有所了解，承担中间桥梁的角色。

总结下，今年在团队方面我个人的总结：

1 关注做事方式，而不只是事情本身

2 架构不可脱离业务场景

3 但是架构并不是要解决业务中出现的所有和技术相关的问题，聚焦很重要

4 架构方案需要自成体系，架构团队需要自我管理

聊生活

除了工作之外，今年花在生活上的时间并不太多，没有什么业余作品出现，也没有去什么地方旅行解压，今年入了主机游戏的坑，PS4/Switch 上面花了不少钱，玩了不少游戏，不过那都是年中的事情，后面越来越忙已经没有时间可以大块的投入玩游戏这件事情上了。工作之余，还会写写代码，偶有开源项目，但是也没有维护的很好，都是一些小东西。今年看了一些书，都是和技术无关的，关于哲学的有一些，关于数学的有一些，关于写作的也有一些，主要是一直在想自己有什么理想，感觉过的年岁越多越想不清楚自己有什么理想，我觉得看看这些书，可能会有一些启发。如果现在问我，我的理想是什么，我的回答可能会是，写一本小说，我觉得这是一个很有意思的事情，不是说单纯的卖弄文字，还需要严谨的构思，需要对不同类型人生的理解，需要合理安排对待生活不同态度的人的命运走向。所以我想，现在先多看点东西，不管是理论，还是实践，说不定哪天突然就开窍了也难说。

另外，今年仍然没有任何买房的计划，也没有要孩子的计划，所以生活还是过得很潇洒的，基本没有太大的支出，所以生活质量会比较高一些，把钱都花在吃吃吃上，所以越来越胖了，已经有些失控。

2018

2018，公司业务应该还会快速发展，可能会投入更多精力，但是团队成员事实上也在快速成长，能够帮我分担不少，另外今年还会再发一轮期权，离“财务自由”又近了一步，不过即使没有这些，其实现在也活的没有什么压力。

2018，在团队技术方面的规划其实已经基本明确了，包括一些工作边界和工作方式，所以这春节是可以安心度过的。

2018，想去国外再玩一趟吧，憋家里挺久的了，感觉一直铺在工作上有时候精神还是很紧绷，偶尔需要放纵一下。

2018，老婆做的幼儿教育小创业项目，我也想能够帮她一把，有一些想法，看有没有时间实施。

2018，还要想想到了这个年纪，除了工作，还需要做些什么积累，为下一次人生机遇做做准备？