又是一年D2：颇具匠心的中台技术修养-CSDN博客

杭州、西溪、冬、烟雨朦胧，又是一年阿里 D2。同样的会场，同样的人，但却是不一样的感受。

这届 D2 的主题是“匠心”，令笔者最为触动的词是“中台”，而笔者今年关注了 D2 新加入的主题“前端技术管理”，关注了团队与个人的“技术修养”问题，因此，结合几个关键词，给这篇文章起了一个比较文艺的题目《颇具匠心的中台技术修养》。

与以往不同，由于在团队中身份的转变，这次来 D2，对业界方向的关注要远超于对前端技术细节的关心，因此，“技术管理”和“技术方案的整体设计”是这次笔者所重点关注的。

第一小节 —— 成长

经过几年的发展，前端的技术成熟度和稳定性已经到了一个很高的水平，虽然各种轮子层出不穷，但是技术体系和架构已经趋于稳定，这个时候，如何管理好团队使用的技术栈，既不“故步自封”，也不“横冲冒进”，是现在前端团队、终端团队管理者需要重点关注的问题。而今年，D2也推出了前端管理的主题，几位有丰富经验的前端团队 Leader 向大家分享了他们的经验。

其中，让笔者感触最深的是月影带来的 《自我成长的多元化团队》。笔者从之前的单打独斗，到现在带领团队一起奋战，团队成员的成长一直是笔者花费很大精力去关注但成效不多的地方，而遇到的问题大部分都在月影的分享中被提到，因此感触颇多。其中 “多元化” 和 “闭环” 是其中笔者觉得最为核心的两点。

在一个团队内，包含着风格、性格、能力各不同的成员，如何让每个成员都能体现出应有的价值，一直是团队 Leader 所遇到问题中的比较棘手。尤其是向笔者所在团队 YMFE 这样的负责公司大前端础架构与中台方案的团队中，每个成员体现的价值与其能力有时候相差甚多。再加上，团队每年都会招入一些没有什么业务经验的应届生，如何让应届生表现出其突出的价值，以致让团队认为其值得培养，并倾斜资源，也是件很闹心的事情。

在这里，月影提出一个观点 —— “重组织、轻管理”，对每个人单独的管理不如更宏观地规划处一系列的“大道”，让成员自行选择。当然，这里的一系列“大道”肯定要满足两个条件，就是上文所说的“多元化”和“闭环”（下图是 奇舞团 的多元化、多维度的成长空间）。虽然，当前团队也有类似的“大道”，但是维度并不足够；而且，当团队发展到一定的规模后，低维度的成长空间会可能会制约团队成员的行动力，所以，根据公司、团队自身情况建立不同的成长空间、成长路线是很有必要的，或许这将是笔者2018年在团队内主要推动的事情。

相比于 “多元化”，笔者感觉 “闭环” 其实更为重要，不论是 “正面反馈” 还是 “负面反馈” 都是很有必要的。在一个纯技术团队中，成员自身的技术肯定在第一位，在技术之外，项目管理、新人导师、对外技术输出和分享等，都是很重要的。而在这些之中，尤其是 “对外技术输出和分享” 最难形成闭环，最难给从事者足够的反馈。有人说，形成闭环很简单，直接和绩效、晋升挂钩。当然只是一种方法，但它只能给成员压力，例如未完成时的“负面反馈”，而并没有带来更多的“正面反馈”。

其实，增加团队影响力，让团队成员都有团队自豪感，是最好的回馈方式。虽然这一年，团队也搞了 Conf 会议，同时也有一些开源项目，但笔者觉得收到的“正面反馈”并没有预想的那么多，尤其对低级别和新加入的成员。这不仅仅要在形式上下功夫，更要加强团队中每个人的团队意识，这应该是下一年需要重点提升的。

第二小节 —— 务实

在月影的分享中，有关管理者 “积极” 和 “保守” 的问题，也令人深省。

不管是积极的管理者还是保守的管理者，都很看重优秀的人才和高效的组织，因为优秀的人才加上高效、稳定的组织，才能形成一个优秀的团队。关于这点，绝大多数人都知道，并且有一定的认识。所以，笔者在这里就不多做赘述了，而谈一下，对前三点的看法和思考。

首先，对于 “保守” 这个偏贬义的词，笔者认为用 “务实” 更为贴切。直白点说，工资是公司发的，给公司创造价值才是当务之急，把技术用于业务、用于产品，减少业务的风险，或许是公司管理层更愿意看到的。打个比方，即时写了一个前无古人后无来者的无敌框架，如果不被业务所采用，到头来产出的也就那么几千行代码而已。

这里，可能读者会认为笔者是个偏“保守”的管理者，其实并不是。笔者是个大白羊，一往直前的创新绝对是不可磨灭的欲望，但是笔者更倾向于在“保守”的基础上“积极”，在“务实”的肩膀上“创新”。创新是着眼于未来，但你的创新是否对未来有效，却不能空口无凭。因此，所谓的创新要在务实的场景中提炼，提炼出未来所需要的创新。讲一个很简单的逻辑，在务实业务的过程中，发现了业务的痛点，需要一种新方式来解决，因此去创新。这样能保证你的创新不管结果怎样，出发点是有意义的，是可以被大家认同的。就像 React Native，它解决了业务急需热更新的需求的同时，提升了体验，做出了比 Web 更好的体验效果，因此受到了大家的青睐。而现在，React Native 的劣势也表现出来，例如，因为通信的瓶颈，List 的效率堪忧，再例如，Native 实现的组件不能热更新（至少 iOS 不行），这种情况下，我们又要如何去解决了？是做微创新，直接切入痛点，解决问题；还是做大创新，提出一个比 React Native 更好的架构形式，这才是管理者应该去深入考虑的。

第三小节 —— 中台

在上面的叙述中，笔者提到了“中台”这个词，并把团队的部分工作称为“中台方案”。其实，“中台”这个词，笔者是在 D2 上才关注到的，因为很多分享都提到了“中台”这个概念，也可能是因为分享人大多是阿里系的有关。“大中台，小前台”是阿里巴巴在2015年底提出的公司级战略，之后很多公司效仿，让很多之前的“公共支持团队”变成现在的“平台事业部”。公司战略层面的高深意义不是笔者一个小技术人员能理解的，不过，仅限技术而言，这样的战略，会减少多团队干一件事的概率，同时也让想做技术的同学可以一直单纯的做技术，不用去想“30后做管理，40后当经理”的事情。这或许是，单纯喜欢做技术的同学一个福音吧。（下图是2016年初阿里基于“大中台、小前台”战略制定的集团整体组织架构）

中台是什么？给前台提供工具、服务、模块等公共、统一化的资源。对于大前端技术来说，构建工具、开发平台、服务平台、公共组件都算作中台的范畴。在大前端基础架构趋于稳定的情况下（前端React、Angular、Vue 三分，客户端原生、Hybrid、React Native（包括类 RN）三分），除了基于现有架构，适配自身公司的基础研发外，更多的是，给业务提供技术方案支持，让业务方更快地进行开发迭代，这或许是当前大前端重点要做的。

当然，唯“中台”论，有时候也比较“可怕”。当前台的技术人员只关心业务，同时中台的技术人员不能提供满足前台的技术需求，这将是很可怕的一件事，因为很难弥补中间的空缺，或者这个问题成为拉锯战。因此，作为“中台”部分的工程师，要承受更大的压力，并拥有更深的技术。

第四小节 —— 修养

在“大中台，小前台”的环境中，大前端工程师，要有怎样的 技术修养 呢？直接贴 盒马岑安 的三张 PPT。

“以史明鉴” 一直是很好的分析方式。通过回顾前端的发展历程，每个阶段的技术，都是为了解决这个阶段的难题与痛点。虽然说，图中跟多是前端的内容，但是客户端与之是类似的。因此，可以说，大前端已经解决了从内容承载到体验优化，在从副交互到工程化，甚至包括开发模式等各个方面的问题，而解决这些问题的能力是当前大前端工程师的基本要求。

而现在呢？未来呢？笔者谈谈自己的想法。在业务形式不断扩展，“中台”变大的时代，大前端工程师，尤其是做架构的大前端工程师，更多地需要能 耐得住寂寞。不同于前几年，一个优秀的架构方案，可以翻江倒海；而现在，包括将来，要做的更多是为业务提供服务的工作，稳定和完善是关键。或者，你可能已经感受不到获得感，但是你做的东西的实际价值或许会更高，因为它会支撑比现在更多的业务。

最后，贴一张“核心竞争力”的 PPT —— 不仅仅要拆解后输出，更要落地于业务。

第五小节 —— 更好

作为中台特征明显的大前端架构，究竟要做什么？或许是，更完善的生态 和 更好的服务。

很简单的一个道理，当人吃饱了，就会要求吃得好、吃得方便、吃得有营养了。做架构也一样，当架构可以满足业务需求后，业务就会反过来，要求架构更稳定、更易用了。

上面是 支付宝加里 分享了一张PPT，类似的 Q 还包括很多，“为什么代码还是原来的”、“为什么点击没反应”、“iOS 没毛病，Android 挂了”。对于这类繁多的业务人员反馈的问题，是烦人也棘手的；你不能奢求业务人员去自己解决，况且有些问题，业务人员根本解决不了。在这时，你就需要一个完善的工具、服务等等其他的一些东西，来快速定位问题，或者来证明“问题不是框架的，是业务自身的”。因此，在未来一年或者几年，对于中台、对于大前端的架构团队，更完善的生态 和 更好的服务 应该被首要关注的。

总结

2017仍是大前端火热的一年，但发展也已经从“野蛮生长”变为“颇具匠心”，越来越多稳定成熟的架构方法被广泛使用。与此同时，时代的热点已经转到机器学习和加密货币，而主项是 UI 的大前端发展又将何去何从呢。或许历史已经给出答案，传统后端默默地做了许久的模块化、服务化，伴随着云的兴起，又迎来新一春。或许，大前端的“中台化”，是大前端发展接下来最重要的一步。

2018，新的一年，你好。

D2 更多视频和 PPT 信息，请访问官网：d2forum.alibaba-inc.com/