我理解的阿里无线前端“架构”

写在前面的话：

对于文中涉及“脱敏”的内容，链接经常一环套一环，无法输出，很抱歉…
怀着一个酝酿了蛮长时间的念头，打开电脑，想对一些思考做一点记录。关于标题，关于“前端”，关于“架构” 。
其实是有蛮多话想说的，但是前面这几个字却打上去了又删掉。想为下面的内容找一个合适的开始。但是似乎总是不那么如意。
回到这个话题，或许应该从以前的认知慢慢说起。

过往的认知

不可否认的说，曾经很长的一段时间，当我大部分时间还集中在业务上的时候，对“架构”这个词有点嗤之以鼻。尤其是“前端架构”。觉得说“前端”这个软件工程化都相对薄弱，还在拼死拼活的往成熟的语言领域，往已有的软件工程慢慢靠近的的方向，真的需要所谓的“架构”么。

总觉得在这个阶段，

• 所谓的前端架构更多的是在纸上谈兵，拿以往的软件工程的思想和概念硬往自己身上套。

• 所谓的做架构的同学更多的是在炫耀自己的技术深度和视野，看到前沿的技术不管合不合适就拿来做方案，硬往业务上推，来成全自己的KPI

• 总觉的所谓的“技术架构”无非就是一些个人主观化的思路和概念，形成一些看起来成体系的代码组织方式，以便完成业务后可以说：看，基于我的架构有多好的通用性，扩展性，代码看起来多优雅…

回到我现在的立场，我看到的当前团队中不同的同学对于“架构”这个词的认识和看法，无非有两种：

• 要么和之前的我一样，嗤之以鼻，做架构的有什么了不起，无非是老板给你安排个“轻松点的活”，做做方案，不用受业务的压迫。还得逼着一线每天认真辛苦的码代码的同学接受你一时想出来的Idea。

• 要么是另一个极端，觉得做架构的同学就NB，觉得比做业务的同学从概念上就高一个等级。然后死命的想要往“架构”这个方向靠。

可是当有一天我自己需要站在团队的角度去思考基础建设的缺失，思考怎么才能帮助到团队的时候。才发现“架构”这个词既没有想象中那么“不堪”，当然也没有想象中那么“容易”。同时，也没有别人眼里那么NB，高人一等。
反而是越来越多的谦卑甚至恐慌，当沉下心来想想，确实，我们可能误会“架构”本身了。我们自己往他身上加了很多的主管臆想。

我理解的架构：是团队的，不是架构师的

第一条我就想说这个，因为TA的确应该是大前提，如果做架构的同学不是站在团队的角度来思考问题，思考解决方案，而是以自己过往的经验，自我的判断说应该怎么怎么样。那必然是会沦落到被人嗤之以鼻，甚至拖业务和效率的后腿。

• 架构一定不应该成为只是你想要的样子，也不能只是老板想要的样子，一定应该是团队想要的样子。

在我正式接下为团队基础建设方向做规划和思考这件事情之前。去年在团队内做了一段时间的“SWAT”，也就是真正意义的上的“灵活资源”，做团队任 意方向的支持。在做“团队支持”这个期间，参与了不同形态的业务项目，产品化的，运营化的，长线的，短线的，消费者端的，商家端的，前台重视内容和体验 的，后台重视效率和结构化的，等等一系列不同的项目，包括一些不直接透明到业务的专项。当前参与程度深浅不一，但总体这个过程让我感受到了一件事情：

• 不能凭想象和自我经验判断说团队需要什么？你要的答案一定要去和团队对话，和团队成员对话，或者参与到不同形态的“他们”当中去，去发掘他们想要什么。

收集信息和问题是做决策和方案的第一步，这个观点说出来大家都知道，但是实际做的过程中可能不一定能想得到了。举个例子：

• 你要做工具，做给新人的，就要站在新人的角度来使用它，发现它是不是真的有用。做给流程规范的就必须站在项目实践的角度去实践TA，而且不是你自己觉得好用就乐呵呵，因为你自己并不是“架构”这个方向的真正用户

• 更典型的例子，前端的自动化测试。做之前第一件事情是弄清楚在当前时间节点下，当前团队状况下，团队是否需要TA。进而才是怎么在团队的层面上去落地这件事情。而不是自己想当然的做一套方案。当前的团队并不需要这个东西，那么方案再完善又有什么用？

“架构是属于团队的”，这个观点一个方面是上面所说的，TA的需求和解决方案应该来源于当前团队。另一个方面是架构的进展和设计一定也是对团队透明和公开的。

如果进展和方案不能随时保持对于团队的公开和透明，也很难保证当到了最终产出的时候，还能保持最开始的方向一致性。

今年上半年开始，我们的周会内容有了小小的变动，把以往的单纯的团队内分享的例会转变为一个始终围绕团队基础建设，团队发展，和个人发展的交流会。植入了一个每周固定的环节，就是“基础建设进展和问题一周汇总”。
保持公开和透明，也可以随时就问题进行讨论。给自己和团队一个面对面的机会。
确保是大家想要的，同时也希望能潜移默化的形成大家对于团队建设的方向感和全局观。

我理解的架构：是横向全局的

这应该是做“架构”最基础的要求。也就是需要对整个团队，结合整个行业的发展保持全局的观望和了解。并且可以在此基础上基于团队现状做出对未来的基本判断。

“做出判断”这件事情，说简单也简单，说难也难。简单的是无非就是做几个选择题，选出今年，或者近期内要做的事情。难得是怎么来保证你的选择在当前的团队来看，是正确的。什么阶段做什么事情。

我记得今年上半年开始，我开始尝试担起前端团队的基础建设收敛相关的事情的时候。结合去年和今年的现状，整理过一个简单的框架图。在 “手淘前端在工程化道路上的“匍匐”” 文章里面有Po过。后来有过一些更新和小调整。大致如下：

归结起来是

• 两个中心 （端和效率）

• 八个方向

  • 基础库+功能组件+UI框架 （对应“效率”）

  • “端”的延伸 （对应“端”）

  • 规范和工程流程

  • 工具链路

  • 数据和性能

  • 自动化测试+持续集成

  • 前端安全

  • 服务和周边

八个方向中，落实到两个中心的必然是今年的重点。工具和性能是去年的重点，今年在已有基础上升级。其他的子方向在今年会开始探索。

这其中由于团队历史和现状的原因，其实有一些点是大家都在火热在抓的，但在我们团队中并没有放到今年的重点。比如

• 前后端分离

也有在当前团队现状还不到时候做的（并不紧迫）的事情，比如

• 前端基础服务（包括构建和工程的服务化，新人系统，内部项目域名和服务资源申请和部署自动化.. 等等）

以上的信息可以理解为“架构是横向全局” 这个观点的一个表现。

个人觉得做出判断的前提确实是需要了解别的优秀的团队在做什么，行业在做什么。再结合团队的现状才有可能知道我们需要做什么。
然而，了解别人的过程，其实反而也是让人“谦卑”的过程。

有时候知道的越多，会让人觉得越渺小。

你觉得自己在某方面做的还不错了，但是一定有人有团队有更优秀的方案和实践。

所以，“全局”，不仅是对于自己团队现状的全局认知和判断，也是在其他团队放到一起的“全局”评估。

• 全局意味着 – 清楚的知道团队在当前阶段应该做什么事情

• 全局意味着 – 清楚的知道团队的现状，优势和问题

  • 不至于高傲的迷失了方向

  • 也不至于卑微的找不到出路

我理解的架构：也是垂直深入的

在我的理解里，所谓“做架构”的同学们，不应该只是单纯的有“全局观”。同时也需要对每个垂直的领域保持一定的“绝对深度”。

就拿上面关于“全局”的几个子方向来说，我希望在当前定下的细分领域，想要做“架构”的同学在任何一个细分领域上都能保持一定的绝对深度。可能对于一个人的精力和资源会有一些挑战，但是我觉得在一定程度上是应该的。

在精力允许的范围内，每一个子领域里应该都需要尽可能的参与方案的探讨，制定，代码的实现，团队的落地整个过程。

拿我们自己团队的情况来说，至少应该知道：

• 基础库和组件库，UI框架

  • 未来形态的发展应该是什么样？

  • CommonJS模块范式的迁移的自动化实现方案是什么？代码实现思路是什么？

  • 模块依赖关系弱关系到强关系的包装需要做哪些事情？

  • 控件的规范是否需要迁移到WebComponents？

  • 如果迁移，规范是什么，怎么定最小Feature的polyfill集合？

  • polyfill代码应该怎么来实现？

  • UI部分的组件复用应该怎么来做？可视化还是命令化？

  • UI库的mixin部分的style-lib和组件层面的view-lib怎么更好的管理？

  • …

• 端的部分

  • ReactNative的现状和痛点是什么？解决方案是什么？代码实现的难点在哪里？

  • RN的组件库怎么来组织构建？一个RN的组件应该怎么来写？

  • RN在性能和稳定性上的解法有哪些？现状是什么？

  • 业务层面的数据上报方案是什么？代码上的思路该怎么做？

  • 是否能明晰的判断未来，知道什么时候该坚持？什么时候该寻找别的出路？

  • GDOS的目标和意义是什么？为什么要做GDOS？

  • 对接通用算法和选品的难点是什么？怎么样定商品化的json schema?

  • 甚至java的部分，hsf的对接是否也能够参与？

  • …

以上举例，提出每个子方向细化的问题，在心里对重要的细节有认知，有答案，也是我认为做“架构”的同学所必须要明白的事情。

同理，工具层面，规范层面，工程流程，性能，单元测试，前端安全等等，期望尽可能深的参与到具体的实践和落地上去。(包括代码的具体实现…)

做架构不是只有idea，然后全部推动别人去做，更重要的是自己需要深度的参与，才能保持清醒的认知。

这是我个人的认知，不一定对，当然

• “在保持广度的情况下还要保持一定的深度”

也会对于个人的时间精力有一定的挑战。

反过来说，如果“架构”已经大到需要5个人以上的团队才能支撑，那时再做合理的分工也不迟。

我理解的架构：是海纳百川，是透明开放的

在之前的表述中，提到“架构”至少是需要对团队透明的，来源于团队，尊重团队，也服务于团队。而这里说的海纳百川，开放透明更是侧指我们以公司单位，那么理应在公司内也是透明和开放的。

• 对外不用多说，公司自有公司的壁垒，但至少对内，我们应该共享一片蓝天。

当你不关注，不闻不问的时候，或许还不觉得，但是当有心想去了解一些事情的时候，却发现似乎并没有想象中那么透明。

我在 上周的周报:不聊技术，聊感受 中其实提到了一些关于“技术栈”和“技术栈”之前的壁垒问题，也包含“前端”本身团队壁垒的问题。

我的观点是：

• 团队技术壁垒不是问题，毕竟每个团队的业务形态，抓的方向并不一致。但是不透明是问题，想发掘其他团队的好东西却要费点功夫。

其实回过头来想想，集团内其实有不少的方式似乎想解决这个问题，比如淘宝的“懒懒”，支付宝的“芝士会” 等等，从定期主题分享的方式尝试抹平BU间不透明的问题。也有属于集团层面的技术博 ATA， 包括前端也有自己的 委员会，本质上也是希望打通BU间的信息。

我们看起来有这些途径，理应可以解决不少壁垒不透明的问题才对，可是到我真实的感受却是还有好多有价值的信息，方案，项目等，我从上面的渠道获取不到的。

可能是“粒度”的问题，可能是“传达”的问题。咋们暂时先不去细究。说实话，我个人觉得比较直接打破我觉得有壁垒的苦恼的事情是 @拔赤 公开的周报。

我近期了解到很多航旅有价值的信息，他们近期着重发力的方向，不可置否的说，基本都是从 @拔赤 每周的周报中觅得的。当然，这和他向来高质量的周报内容有直接关系。

所以，我做的第一件事也是把无线前端从今年上半年开始的每周基础建设，架构的方向和进展以周报的形式公开来。一方面从我们自己开始做到“透明化”，同时也愿意以谦卑的心态和大家进行讨论和交流。

阿里内外的周报系统我觉得是个好的开始。既然有选择“公开”的选项，我觉得也应该加上“周报关注”的功能，只要我关注的人某一周的周报内容是“公开”的，不管他的周报有没有直接抄送我，我都可以收到。

话题有点扯远了，我要表达的意思是，我期望寻得一种途径，可以让我短平快，高效的知道优秀的大家们都在做什么事情。

最近在团队内开始推动一个叫做 “取经之路” 的计划，其实也就是希望团队的同学都能保持有心思去发掘其他团队的优秀的东西，以取经的形式主动去了解，再带回来传道授业解惑。
希望团队本身能从中开拓视野和思路，同时对于做“唐僧”的同学来说，本身也是一种成长。

我理解的架构：关键词不是“高精尖”，而是“合适”

最近越发的觉得“合适”这个词的精妙与深意。站在外人的角度，去评判一件事情的好坏，一个技术方案的优劣，不应该从你的角度去看，连行业的普适标准甚至都不一定受用。因为可能在你看来有失偏颇的方案在他的团队的当下就是“合适”的。

换句话说：

• 在我看来，技术方案优和劣或许没有绝对之分，只是因为团队的历史原因，团队现状，发展出了不同的样子。只要它对于当前的团队是合适的，我就认为它是好的。

说到这里，我不免又想到了“恋爱”这件事。如果这么说来的话，不觉得和“恋爱”的情况略像么。通俗点说：

• 爱美之心，人皆有之；漂亮的女孩子，谁都喜欢，你费劲心思去追一个大家公认的女神，这件事情能不能成，最终是变成“金童玉女”的千古流传段子还是 变成“癞蛤蟆想吃天鹅肉”的恶俗剧情，前提是要认清自己。当前的自己如果如果就是配不上女神，那何必自讨苦吃，还不如努力锤炼自己，到有一天走上人生巅峰 再去赢取白富美也不迟不是么。

比方不一定恰当，但是道理是通的。我想说的是，技术的方案和设计是不是好的，对的，不是看你用的技术，选的方案是不是够高精尖，够前沿。而是看TA是不是适合你当前的团队现状。

举个例子：

• ES6 当下被好多团队在实践，吵得火热。可以理解为ES6的产品化，包括周边polyfill的完善，以及一整套方案的打通，在当下看起来是靠前沿的，面向未来 的，高精尖的。 如果我们的团队就那么几个人，如果团队负责的业务就那么两三个，形态也相对单一，那么我觉得快速的拥抱ES6，尝鲜，玩新技术没有任何问题。而反过来，如 果当前团队的体量，现状，团队组成不允许一个步子迈这么大，那么这件事如果硬按“拔苗助长”的方式推进，有可能会产生很大的副作用，开发效率，质量保障可 能都会收到影响。