我理解的阿里无线前端“架构”（半鸡汤，少干货） #3
Comments
|
说得好！ |
|
赞！ |
|
赞 |
|
全局意识，抓精抓细，接地气，是“架构”团队最应该注意的三点。 |
|
点赞~我一直都在强调：不在于什么新技术，适合团队的才是好的架构 |
|
赞！
很赞同上面那句话。 |
|
棒 |
|
“在适当的时候，遇上对的人。”我喜欢这句话 |
|
赞一个 |
|
赞赞赞！ |
|
这才是踏踏实实做事的人说得话 |
|
po🐷的心里话 |
|
很赞，在适当的时候，用适当的方案去做对应适当的事情。 |
|
架构的本来目的就是为了解决当下存在以及未来可能出现的各种问题，如何做到架构需求的实时回归（从一线反馈的需求）这个是个问题 |
赞 |
|
赞 |
|
很赞 补充一点个人理解。 在未来技术上的投入可以看成是微型的风险投资，收益和失败几率成正比，选择一部分余力来做还是倾囊而出，有时候还真分不出孰优孰劣，但是看到身边有大胆的人勇猛地冲怎么说都是件值得高兴的事情。前端这些年的迅猛进化，离不开这些冲动的高手们。 |
|
BTW， 业务部门的指标都很明确简单，对于架构而言性能提升和基础库搭建的作用比较明显，其他工作内容的价值就不容易衡量了。在某些糟糕的情况下，甚至衡量的重要性要超过内容本身，这也算是团队的生存现状，也是架构组需要考虑的内容。 这个问题放在前面的论述里来说，属于横向全局的考虑，也有点类似开放透明所要解决的问题。 |
|
@amio 我其实蛮钦佩勇敢往前迈进的决策者和团队的 |
|
说的不错，赞一个 |
|
我们小团队前后端分离好痛苦，环境构建确实带来酸爽，架构方面只能慢慢摸索，需借鉴你们的经验:) |
|
赞！喜欢这句话：在适当的时候，遇上对的人 |
|
赞 |
|
赞~ |
|
能看出来 是用心在写文章 很有意识 有机会请你喝酒哈 |
|
写的真好！ |
|
个人理解架构解决主要问题就是规范 效率 质量 |
|
不求高精尖，但求合适 |
|
合适:合得来 ，适配的又好。。。 赞 |
|
终究还是造了个轮子。。。 |
|
在适当的时候，选择适当的架构，随着业务的扩展不断进化。 |
|
不是前端，以后慢慢看 |
|
看到前言就赞，同感的前端人 |
|
里面几个链接都挂了，能修复一下么？ |
|
@banditsmile 文章中的几个链接是指向公司内部网络的链接，所以使用「脱敏」指代，无法打开。 |
|
‘架构和方向不应该朝着“高精尖”的方向走，那不应该是目标，“合适”的，才是最好的’ 其实这句话说的不够准确，“合适”确实是比较精深的词，我们也应该明白“高精尖” 和 “合适” 是不矛盾的，其实，在技术选型期间，我更优先考虑这些高精尖的东西是不是符合目前的场景，当然这也是一个权衡利弊的过程，毕竟新的东西有TA的优势，也有TA的弊端，如果要弥补弊端的代价大于优势带来的好处，那就可以定位这个“高精尖”不符合目前的需求，也就是所谓的不“合适”！ |
|
赞一个，合适才是最好的，而不是使用什么高深的技术。 |
|
用心在写文章，赞 |
|
good! |
|
gooddddddddd |
|
赞。。 |
|
赞！发人深省，自叹不如~~ |
|
看来，架构师和全栈比较接近了 |
|
踏实做人! |
|
说的话，说到点子上了 |
|
个人不完全赞同这句话
这句话很容易被一些不思进取的程序员甚至架构师利用来做偷懒的借口举个例子吧， 这其中值得思考的点是： 还有个问题留给大家： 那么既然要接纳新事物，为何非要被动接受，而不抱有主动地心态呢？ 如果仅仅是固守在“合适”的舒适地，那么，用现在流行的一句话，“时代抛弃你，从来不说再见”
那么问题来了，从现在来看，那个最开始到现在都一直没改动过的项目架构， 任何改动和升级必然是有风险和成本的。你不能因为这些就停滞不前了。 面向未来，也是架构师最基本的素质吧，不然不就是鼠目寸光了么？ |
and others
写在前面的话：
过往的认知
不可否认的说，曾经很长的一段时间，当我大部分时间还集中在业务上的时候，对“架构”这个词有点嗤之以鼻。尤其是“前端架构”。觉得说“前端”这个软件工程化都相对薄弱，还在拼死拼活的往成熟的语言领域，往已有的软件工程慢慢靠近的的方向，真的需要所谓的“架构”么。
总觉得在这个阶段，
回到我现在的立场，我看到的当前团队中不同的同学对于“架构”这个词的认识和看法，无非有两种：
可是当有一天我自己需要站在团队的角度去思考基础建设的缺失，思考怎么才能帮助到团队的时候。才发现“架构”这个词既没有想象中那么“不堪”，当然也没有想象中那么“容易”。同时，也没有别人眼里那么NB，高人一等。
反而是越来越多的谦卑甚至恐慌，当沉下心来想想，确实，我们可能误会“架构”本身了。我们自己往他身上加了很多的主管臆想。
我理解的架构：是团队的，不是架构师的
第一条我就想说这个，因为TA的确应该是大前提，如果做架构的同学不是站在团队的角度来思考问题，思考解决方案，而是以自己过往的经验，自我的判断说应该怎么怎么样。那必然是会沦落到被人嗤之以鼻，甚至拖业务和效率的后腿。
在我正式接下为团队基础建设方向做规划和思考这件事情之前。去年在团队内做了一段时间的“SWAT”，也就是真正意义的上的“灵活资源”，做团队任意方向的支持。在做“团队支持”这个期间，参与了不同形态的业务项目，产品化的，运营化的，长线的，短线的，消费者端的，商家端的，前台重视内容和体验的，后台重视效率和结构化的，等等一系列不同的项目，包括一些不直接透明到业务的专项。当前参与程度深浅不一，但总体这个过程让我感受到了一件事情：
收集信息和问题是做决策和方案的第一步，这个观点说出来大家都知道，但是实际做的过程中可能不一定能想得到了。举个例子：
“架构是属于团队的”，这个观点一个方面是上面所说的，TA的需求和解决方案应该来源于当前团队。另一个方面是架构的进展和设计一定也是对团队透明和公开的。
如果进展和方案不能随时保持对于团队的公开和透明，也很难保证当到了最终产出的时候，还能保持最开始的方向一致性。
今年上半年开始，我们的周会内容有了小小的变动，把以往的单纯的团队内分享的例会转变为一个始终围绕团队基础建设，团队发展，和个人发展的交流会。植入了一个每周固定的环节，就是“基础建设进展和问题一周汇总”。
保持公开和透明，也可以随时就问题进行讨论。给自己和团队一个面对面的机会。
确保是大家想要的，同时也希望能潜移默化的形成大家对于团队建设的方向感和全局观。
我理解的架构：是横向全局的
这应该是做“架构”最基础的要求。也就是需要对整个团队，结合整个行业的发展保持全局的观望和了解。并且可以在此基础上基于团队现状做出对未来的基本判断。
“做出判断”这件事情，说简单也简单，说难也难。简单的是无非就是做几个选择题，选出今年，或者近期内要做的事情。难得是怎么来保证你的选择在当前的团队来看，是正确的。什么阶段做什么事情。
我记得今年上半年开始，我开始尝试担起前端团队的基础建设收敛相关的事情的时候。结合去年和今年的现状，整理过一个简单的框架图。在 "手淘前端在工程化道路上的“匍匐”" 文章里面有Po过。后来有过一些更新和小调整。大致如下：
归结起来是
八个方向中，落实到两个中心的必然是今年的重点。工具和性能是去年的重点，今年在已有基础上升级。其他的子方向在今年会开始探索。
这其中由于团队历史和现状的原因，其实有一些点是大家都在火热在抓的，但在我们团队中并没有放到今年的重点。比如
也有在当前团队现状还不到时候做的（并不紧迫）的事情，比如
以上的信息可以理解为“架构是横向全局” 这个观点的一个表现。
个人觉得做出判断的前提确实是需要了解别的优秀的团队在做什么，行业在做什么。再结合团队的现状才有可能知道我们需要做什么。
然而，了解别人的过程，其实反而也是让人“谦卑”的过程。
有时候知道的越多，会让人觉得越渺小。
你觉得自己在某方面做的还不错了，但是一定有人有团队有更优秀的方案和实践。
所以，“全局”，不仅是对于自己团队现状的全局认知和判断，也是在其他团队放到一起的“全局”评估。
我理解的架构：也是垂直深入的
在我的理解里，所谓“做架构”的同学们，不应该只是单纯的有“全局观”。同时也需要对每个垂直的领域保持一定的“绝对深度”。
就拿上面关于“全局”的几个子方向来说，我希望在当前定下的细分领域，想要做“架构”的同学在任何一个细分领域上都能保持一定的绝对深度。可能对于一个人的精力和资源会有一些挑战，但是我觉得在一定程度上是应该的。
在精力允许的范围内，每一个子领域里应该都需要尽可能的参与方案的探讨，制定，代码的实现，团队的落地整个过程。
拿我们自己团队的情况来说，至少应该知道：
以上举例，提出每个子方向细化的问题，在心里对重要的细节有认知，有答案，也是我认为做“架构”的同学所必须要明白的事情。
同理，
工具层面，规范层面，工程流程，性能，单元测试，前端安全等等，期望尽可能深的参与到具体的实践和落地上去。(包括代码的具体实现...)
做架构不是只有idea，然后全部推动别人去做，更重要的是自己需要深度的参与，才能保持清醒的认知。
这是我个人的认知，不一定对，当然
也会对于个人的时间精力有一定的挑战。
反过来说，如果“架构”已经大到需要5个人以上的团队才能支撑，那时再做合理的分工也不迟。
我理解的架构：是海纳百川，是透明开放的
在之前的表述中，提到“架构”至少是需要对团队透明的，来源于团队，尊重团队，也服务于团队。而这里说的海纳百川，开放透明更是侧指我们以公司单位，那么理应在公司内也是透明和开放的。
当你不关注，不闻不问的时候，或许还不觉得，但是当有心想去了解一些事情的时候，却发现似乎并没有想象中那么透明。
我在 上周的周报:不聊技术，聊感受 中其实提到了一些关于“技术栈”和“技术栈”之前的壁垒问题，也包含“前端”本身团队壁垒的问题。
我的观点是：
其实回过头来想想，集团内其实有不少的方式似乎想解决这个问题，比如淘宝的“懒懒”，支付宝的“芝士会” 等等，从定期主题分享的方式尝试抹平BU间不透明的问题。也有属于集团层面的技术博 ATA， 包括前端也有自己的 委员会，本质上也是希望打通BU间的信息。
我们看起来有这些途径，理应可以解决不少壁垒不透明的问题才对，可是到我真实的感受却是还有好多有价值的信息，方案，项目等，我从上面的渠道获取不到的。
可能是“粒度”的问题，可能是“传达”的问题。咋们暂时先不去细究。说实话，我个人觉得比较直接打破我觉得有壁垒的苦恼的事情是 @拔赤 公开的周报。
我近期了解到很多航旅有价值的信息，他们近期着重发力的方向，不可置否的说，基本都是从 @拔赤 每周的周报中觅得的。当然，这和他向来高质量的周报内容有直接关系。
所以，我做的第一件事也是把无线前端从今年上半年开始的每周基础建设，架构的方向和进展以周报的形式公开来。一方面从我们自己开始做到“透明化”，同时也愿意以谦卑的心态和大家进行讨论和交流。
阿里内外的周报系统我觉得是个好的开始。既然有选择“公开”的选项，我觉得也应该加上“周报关注”的功能，只要我关注的人某一周的周报内容是“公开”的，不管他的周报有没有直接抄送我，我都可以收到。
话题有点扯远了，我要表达的意思是，我期望寻得一种途径，可以让我短平快，高效的知道优秀的大家们都在做什么事情。
最近在团队内开始推动一个叫做 “取经之路” 的计划，其实也就是希望团队的同学都能保持有心思去发掘其他团队的优秀的东西，以取经的形式主动去了解，再带回来传道授业解惑。
希望团队本身能从中开拓视野和思路，同时对于做“唐僧”的同学来说，本身也是一种成长。
我理解的架构：关键词不是“高精尖”，而是“合适”
最近越发的觉得“合适”这个词的精妙与深意。站在外人的角度，去评判一件事情的好坏，一个技术方案的优劣，不应该从你的角度去看，连行业的普适标准甚至都不一定受用。因为可能在你看来有失偏颇的方案在他的团队的当下就是“合适”的。
换句话说：
说到这里，我不免又想到了“恋爱”这件事。如果这么说来的话，不觉得和“恋爱”的情况略像么。通俗点说：
比方不一定恰当，但是道理是通的。我想说的是，技术的方案和设计是不是好的，对的，不是看你用的技术，选的方案是不是够高精尖，够前沿。而是看TA是不是适合你当前的团队现状。
举个例子：
所以，架构和方向不应该朝着“高精尖”的方向走，那不应该是目标，“合适”的，才是最好的。
在适当的时候，用适当的方案去做对应适当的事情，
就好比，
在适当的时候，遇上对的人。
The text was updated successfully, but these errors were encountered: