的理解写在前面的话：对于文章中涉及“脱敏”的内容，链接往往是一个接一个链接，无法输出。对不起……怀着酝酿已久的思绪，打开电脑，想记录下一些思绪。关于标题，关于“前端”，关于“架构”。其实想说的还挺多的，只是前面几个字打出来了，后来又删掉了。试图找到一个合适的地方开始接下来的事情。但似乎总是不太尽如人意。回到这个话题，或许我们应该从之前的认知慢慢说起。不可否认，从以往的认知来看，在很长一段时间里，当我大部分时间还是专注于业务的时候，我对“架构”这个词有点嗤之以鼻。特别是“前端架构”。感觉“前端”的软件工程比较薄弱，还在朝着成熟的语言领域努力，慢慢向现有的软件工程方向靠拢。真的需要所谓的“架构”吗？总觉得现阶段所谓的前端架构更多的是纸上谈兵，把以前的软件工程思想和概念套用到自己身上。所谓建筑系的学生，更多的是炫耀自己的技术深度和眼光。当他们看到最前沿的技术，不管合适不合适，都把它当成解决方案，强行推到业务上去完成自己的KPI。所谓“技术架构”无非是个人的一些主观想法和概念，形成一些看似系统的代码组织方式，以至于在业务完成后，你可以说：你看，通用性、扩展性、代码有多好基于我的架构？怎么看怎么优雅。。。回到我现在的位置，我看到现在团队里不同的同学对“架构”这个词有两种理解和看法：要么和我以前一样，冷笑，做架构有什么大不了的，无非是老板给你安排了一份“轻松的工作”让你做打算，不受业务的压迫。你得强迫每天辛辛苦苦写代码的一线同学暂时接受你想出的Idea。要么是另一个极端，认为做建筑的同学NB，认为做业务的同学概念上高了一个层次。然后拼命想往“建筑”的方向靠。但是当有一天我需要考虑缺乏基础设施以及如何从团队的角度帮助团队时。才发现“建筑”二字并没有想象中的“不堪”，当然也没有想象中的“轻松”。同时也没有别人眼中的NB，高人一等。取而代之的是越来越卑微，甚至是恐慌。当我们静下心来仔细想想，的确，我们可能误解了“建筑”本身。我们自己对他做了很多行政假设。我理解的架构：它是为团队服务的，而不是为架构师服务的。这是我首先要说的，因为TA确实应该是大前提。根据自己以往的经验和自我判断，应该怎么办。那难免会招来别人的鄙视，甚至会阻碍生意和效率。架构一定不能只是你想要的，也不能是老板想要的，一定要是团队想要的。在我正式接手之前规划和思考团队基础设施建设的方向。去年，我在团队里做了一段时间的《特警》，这是真正的“灵活资源”，可以支持团队的任何方向。在“团队扶持”期间，参与了不同形式的业务项目，产品化、运营化、长期、短期、消费端、业务端、前端看重的内容和体验，以及后端看重的是效率和结构有一系列不同的项目，包括一些不直接对业务透明的特殊项目。目前的参与程度参差不齐，但总的来说这个过程让我有一个感受：不能凭想象和亲身体验来判断团队需要什么？你想要的答案一定是和团队交谈，和团队成员交谈，或者参与不同形式的“他们”，去发现他们想要什么。收集信息和问题是制定决策和解决方案的第一步。这个观点大家都知道，但是在实际做的过程中可能想象不到。举个例子：你要做一个新人的工具，你要站在新人的角度去使用它，去发现它是否真的有用。做流程规范，必须从项目实践的角度去实践TA，你不高兴因为你觉得好用，因为你不是“架构”方向的真正用户。一个比较典型的例子就是前端自动化测试。.做之前首先要做的就是弄清楚在当前的时间节点和当前的团队情况下，团队是否需要TA。然后就是如何在团队层面落实这件事情。而不是想当然地制定一套计划。现在的团队不需要这个东西，完善方案有什么用？“架构属于团队”，这个观点的一个方面就是上面提到的，TA的需求和解决方案应该来自于现在的团队。另一个方面是架构的进展和设计也必须对团队透明和开放。如果进度和计划不能随时对团队保持公开透明，那么也很难保证在达到最终产出时能够保持最初方向的一致性。从今年上半年开始，我们的周会内容略有变化，由以往简单的团队内部例会变成了始终围绕团队基础建设、团队发展、个人发展展开的交流会。植入每周固定链接，即“每周基础设施进展和问题总结”。公开透明，也可以随意讨论问题。给你自己和你的团队一个面对面的机会。确保是大家想要的，同时希望潜移默化地形成大家对团队建设的方向感和大局观。我理解的架构：它是水平的和全局的。这应该是对“架构”最基本的要求。也就是说，需要对整个团队和整个行业的发展保持一个整体的观望和了解。并且在此基础上，我们可以根据球队的现状，对未来做出基本的判断。“作出判断”这件事，说起来简单，说起来容易，说起来难。简单的事情无非就是做几道选择题，选择今年或者近期要做的事情。难得的是如何保证自己的选择在目前的团队中是正确的。什么阶段做事。记得今年上半年开始尝试打理前端团队基础设施融合相关的事情。结合去年和今年的现状，整理了一个简单的框架图。工程化之路上手淘前端的《爬虫》一文中有细分。从那以后，有一些更新和小的调整。大致如下：归结为两个中心（端和效率）八个方向基础库+功能组件+UI框架（对应“端”）扩展“端”（对应“端”）规范和工程流程工具链接数据和性能自动化测试+前端安全服务和周边八个方向的持续集成，两个中心的落地一定是今年的重点。工具和性能是去年的重点，今年我们将在现有基础上进行升级。今年将探索其他子方向。其中，由于球队的历史和现状，其实也有一些大家急于把握的点，但我们球队并没有把今年的重点放在上面。比如前后端分离在当前团队状态还没有的情况下也有事情要做（不急），比如前端基础服务（包括建筑工程服务，新人系统，内部项目）域名和服务资源申请和部署自动化。。等）以上信息可以理解为“架构是横向的全局态势”这一观点的体现。个人觉得做判断的前提是了解其他优秀的团队在做什么，行业在做什么。结合球队目前的情况，就可以知道我们需要做什么了。然而，理解别人的过程，其实也是一个“谦卑”的过程。有时候你知道的越多，你就越觉得自己渺小。你认为自己在某个方面做得很好，但肯定有人带团队有更好的计划和做法。所以，“全局”不仅是对自己球队现状的整体认知和判断，也是其他球队拼凑出来的“全局”评价。大局意味着——清楚地知道团队在现阶段应该做什么。大局意味着——清楚地知道团队的现状、优势和问题，才不会自大迷失方向，不会谦虚找不到出路。我理解的结构：也是垂直的，有深度??的。在我的理解中，所谓的“架构”同学不应该简单的有“大局观”。同时，还需要为每个垂直场保持一定的“绝对深度”。以上面关于“全局”的细分方向为例，希望在目前的细分领域，想做“建筑”的同学在任何细分领域都能保持一定的绝对深度。对一个人的精力和资源可能会有一些挑战，但是我觉得应该做到一定程度。在精力范围内，各子领域尽可能参与讨论、制定、代码实施、团队落地的全过程。以我们自己团队的情况为例，我们至少应该知道：基础库和组件库，UI框架未来的发展应该是什么样的？CommonJS模块范式迁移的自动化实现方案是什么？代码实现的思路是什么？从弱到强包装模块依赖需要做什么？控件的规范是否需要迁移到WebComponents？如果迁移，规范是什么，如何确定最小Feature的polyfill集？polyfill代码应该如何实现？UI部分的组件复用应该怎么做？视觉还是命令？如何更好地管理UI库mixin部分的style-lib和组件层的view-lib？到底ReactNative的现状和痛点是什么？解决办法是什么？代码实现的难点在哪里？如何组织和构建RN的组件库？一个RN组件应该怎么写？RN在性能和稳定性方面有哪些解决方案？现状如何？业务层面的数据上报计划是怎样的？code的idea怎么办？你能清楚地判断未来，知道什么时候坚持吗？什么时候应该另寻出路？GDOS的目的和意义是什么？为什么要做GDOS？对接通用算法和产品选型有哪些难点？如何定义商业json模式？连java部分，hsf连接也能参与吗？&hel唇;对于上面的例子，我提出了各个子方向的详细问题，心中对重要的细节和答案有了一个了解。这也是我认为做“建筑”的同学必须要明白的。在工具级别和规范级别也是如此。、工程流程、性能、单元测试、前端安全等，期望尽可能深入地参与到具体的实践和实施中。（包括代码的具体实现。。。）做架构不是光有想法，然后全部推给别人去做。更重要的是，您需要深度参与以保持清晰的认识。这是我个人的看法，不一定正确。当然，“在保持广度的同时保持一定的深度”也会对个人的时间和精力造成一定的挑战。反之，如果“架构”大到需要5人以上的团队支撑，那么再合理分工也不迟。我理解的架构：包容、透明和开放。在前面的表述中提到，“架构”至少需要对团队透明，源于团队，尊重团队，服务团队。这里所说的公开透明，是指我们公司是一个单位，所以在公司内部应该是透明公开的。对外不用说，公司有自己的壁垒，但至少对内，我们应该共享一片蓝天。当你不注意或不在意的时候，你可能感觉不到，但是当你想了解一些东西的时候，却发现它并没有你想象的那么通透。我上周的周报：不谈技术，谈感受，其实提到了一些关于“技术栈”的问题，以及“技术栈”之前的壁垒，包括“前端”团队本身的壁垒.我的观点是：团队技术壁垒不是问题。毕竟各个团队的业务形态和方向并不一致。但不透明是个问题，要从其他团队发现好的东西需要付出一些努力。其实回过头来看，群里其实有很多方式似乎都想解决这个问题，比如淘宝的“懒人”，支付宝的“芝士会”等，从定期主题分享的方式到尽量顺畅解决BU之间不透明的问题。集团层面还有一个技术博客ATA，包括前端也有自己的委员会，本质上是希望打通BU之间的信息。我们似乎有这些渠道，应该可以解决很多不透明壁垒的问题，但我的真实感受是，还有很多有价值的信息、方案、项目等，是我无法从以上渠道获取到的。可能是“粒度”的问题，也可能是“沟通”的问题。为什么我们暂时不进入它。说实话，我个人认为更直接的突破我认为有障碍的苦恼的方法是@巴红发布的周报。我最近了解了很多关于航空旅行的宝贵信息。不可否认的是，他们最近都在关注自己的努力方向，基本上都是从@巴红的周报来看。当然，这与他的优质每周内容有直接关系。所以，我做的第一件事就是把从今年上半年开始的每周无线前端的基础设施建设情况，以周报的形式发布架构的方向和进展。一方面，我们开始对自己“透明”，同时，我们也愿意以谦虚的态度与您探讨、交流。我觉得阿里内外的周报制度是一个好的开始。既然有选择“公开”的选项，我觉得也应该加上“周报关注”的功能。只要我关注的人的周报内容是“公开”的，不管他的周报是否直接抄袭我，我都会收到。话题扯得有点远，我想表达的是，我希望找到一种方法，让我能够快速高效地知道优秀的人在做什么。近期，团队开始推进一项名为“取经之路”的计划。其实就是希望团队中的同学能用心去发现其他团队的优秀的东西，主动以取经的形式去了解，然后再带回来传道授业。解决疑惑。希望团队能从中开阔眼界和思路，同时也是对“唐僧”同学们的一种成长。我理解的结构：关键词不是“高科技”，而是“适合”。站在外人的角度，你不应该站在你的角度去判断一个事物的好坏，或者一个技术方案的好坏。即使是行业的通用标准，也未必有用。因为在你看来可能有偏见的解决方案对他的团队来说是“合适的”。换句话说：在我看来，技术方案的好坏可能没有绝对的区别，只是因为团队的历史原因和团队现状，发展出了不同的东西。只要适合现在的团队，我觉得都可以。说到这里，我不禁又想起了“爱情”。这么说的话，是不是觉得有点类似于“恋爱”的情况。通俗地说：每个人都有爱美的欲望；人人都喜欢漂亮的姑娘，但如果你努力去追一个人人都认可的女神，不管这件事能不能做到，最终都会成为“金童玉女”流传下来的笑话千古依旧成为“蟾蜍要吃天鹅肉”的庸俗情节，前提是认清自己。如果现在的自己配不上女神，何必自讨苦吃，还不如努力磨练自己，哪天走上人生巅峰，再拿下白富美也不迟，正确的？这个例子可能不恰当，但理由是合理的。我想说的是技术方案和设计好不好，是的，这不取决于你使用的技术，而是选择的方案是否足够成熟和前沿。就看TA适不适合你现在的团队状态了。比如：ES6目前很多团队都在实践，很吵。可以理解为ES6的产品化，包括周边polyfill的完善，以及一整套解决方案的开放。在当下，它似乎是前沿的、面向未来的和复杂的。如果我们团队只有几个人，如果团队只负责两三个业务，形式比较单一，那么我觉得快速拥抱ES6，尝试新技术，玩转新技术是没有问题的。另一方面，如果以目前团队的规模、现状、团队的构成不允许迈出这么大的一步，那么如果按照“推苗助长”的方式推进这件事的话，它可能有很大的副作用，开发效率和质量。保修可能会受到影响。所以架构和方向不要往“高科技”方向走，那不应该是目标，“适合”才是最好的。在对的时间，用对的计划做对的事，就像在对的时间遇到??对的人一样。
