Scott这两年无论是面试还是线下线上的技术分享，都接触过很多前端同学。由于团队原因，个人原因，以及职业成长，技术方向，甚至家庭等原因，在理想国与现实之间，在放弃与坚守之间，摇摆不定，心碎与拼搏，可以谈谈向我介绍南北，对工程师的命运有了更多的感悟。更多理解，更多所见所闻，斯科特微信：codingdream。本系列共有15篇文章，这是第一篇。大家看完转发朋友圈后我就很满意了。写作开始计划、管理人员、管理资源和管理优先级。这就是TechTeamLeader的宿命。在这篇文章中，Scott以一个管理者的视角，跟大家分享了自2017年7月加入小菜以来，我是如何和前端同学一起规划团队的技术栈的，以及这个技术栈上的技能点在不同的地方有何不同童鞋。脱离商业。先来看一张图：这张图是我2018年8月给团队做的技术栈架构的分工，基本涵盖了团队2018-2020年需要的技术栈能力，还会进化随着业务和团队的不断微调和修正。我会在2019年8月重新整理一个新版本，在这里分享给大家。在带领这个团队的一年多时间里，我对团队的观念其实发生了很多变化。它是抽象的和笼统的。将有两个并行过程。一是从人和团队的角度来规划团队。而管理，一是将业务与团队具体的技术栈演进和架构路线调整相结合，这两个过程会交叉实施，相互影响。这些方法和结论也有其特殊的公司背景和局限性，不一定适用于您业务形式的团队。不要硬复制它们。大家可以关注一下这些过程和我的思维过程的变化。最后，我们再回来从上图，大家可以了解到一个团队的技术栈架构和演进背后的方法论。一、团队管理先说团队管理。这是前提。没有配套的团队管理方式的辅助，很难简单的在技术栈上做出持续的、好的改变，也很难将架构理念落地。团队管理这里我主要分为四个步骤。第一步是了解团队的优势和劣势。在加入一个团队的时候，尤其是成为高级工程师带队之后，除了努力工作之外，还有一件很重要的事情要尽快去做，那就是了解团队。方法很多，比如：主动去看看团队仓库里的历史代码，了解大家的编码水平、编程风格、项目维护方式、架构的成熟度。想想你自己和你所在的团队，请吃饭吃饭，听听大家谈什么，玩什么，注意什么，每个人的气场和表情，办公桌和餐桌有什么区别？服务器组和业务组的同学，问问他们对前端组的印象，对合作童鞋的看法，会上也提出一些问题，观察大家的参与热情和意见的深度。您还可以一起玩游戏和看电影。一起参加公司活动等等，这是一个比较粗略的理解。加入团队后，我也选择了以上两三种方式来粗略了解团队成员。我看到了很多好的特性，也看到了很多问题。优点：个个年轻聪明，学习能力好，可塑性强。他们没有资本，对技术有激情和热情，技术栈很新颖，每个人都有很大的潜力。基于这些，可以预见，这支队伍只要明确了每个阶段的重点，就能快速成长，大家也能不断突破天花板，所以大盘性质好，资质好也不错。看问题：问题：职场不够专业，比较情绪化，对业务变化有一定的抗拒，没有职业规划意识，判断好坏的标准狭隘封闭，不会想太多整体工具工程和基础设施方向。整个行业的判断还比较肤浅，属于比较原始和野蛮的阶段。团队成员能力参差不齐，补位意识和大局意识相对薄弱。具体的方法论，可以总结一下最近几周的问题，然后做标记和归类，比如：结合业务和开发流程，梳理出问题的共性。最终问题可以概括为：人不稳定，技能短，多职业没有规划，合作意识差，团队，没有标准化的工具，基础设施，业务薄弱，没有梯队意识。基于这些，可以预见球队将需要一段较长的磨合期。大家经常讲很多，就是通过在每个人的脑海里灌输一个做事正确的观念，然后根据每个学生的特点，通过不同的方式分配任务、驱动和辅导。另外，我们需要有一些事情大家一起去做，形成团队合作和凝聚力，我最终选择了技术分享作为一个共同去做的事情，让团队在这件事情上达成唯一的共识——改进技术团队的影响力和个人总结能力的提升。第二步，督促团队改进内部短板。所谓内部短板，就是发布系统不完善、代码不规范、工具不健全等完全是我们自己造成的问题。有了第一步的总结，就可以在这些问题中，优先考虑与业务关系比较密切的问题，进行突破。我当时选择的是开发的在线流程，即开发团队从开发到发布必须具备的刚需能力。从这条线开始，各种工具和系统会被拆分，童鞋的反对声音会比较低。高效和稳定可以带来更多的资源释放，也可以带来参与学员的大成长。因此，通过规范和工程来弥补内部的不足，是一种非常可取的团队管理方式。见下图，是2017年下半年到2018年开发上线过程的变化：这条路的基础设施建设过程进行了半年多，最人、最脏、最累的工作基础团队中已经由机器完成，虽然与业务没有直接关系，但间接保证了业务的持续性和稳定性。同时一路升级打怪，也让参与开发的小伙伴在编程和工程能力上有了更大的提升，成为最早的一批技术骨干。第三步，推动团队走向无人区。如果团队内部的核心问题解决了，那么产品、运营、业务相关的环节就可以得到改善，比如App在线运行的异常监控，其实在初创公司，一般没有直接负责的部门。每个人都专注于业务。那么这个时候，前端团队发布的作品，就应该由前端自己去驱动去负责。这里我把线上运行的监控看成一条线，在内部问题的Mock阶段配合GPM（GraphQL数据聚合服务层），跨越了前端团队的职能，与其他团队，如下图所示：不仅针对业务，还针对人事、财务、行政等其他中台部门。只要有精力，就可以尽可能用成本最低的技术手段，为公司的无人区做一些协同工作。工具和系统，这会给团队带来很多正面的口碑，同时提升技术。最重要的是，一旦你成为发起者和推动者，你的角色和身份就会改变。发生了变化。你既是产品经理又是项目经理，既是需求方又是业务方。这样会大大提升你的综合能力，也有助于提升整个团队在公司内部的影响力。部门之间在工作上互相帮助也打下了一些基础，这对于不善于表达，比较沉闷的工程团队来说是非常有意义的。第四步，鼓励团队技术和业务创新。从前面的三个步骤，就可以看出我的套路了。更稳定的带领团队前进的方式是从内到外，从技术到跨团队事务再到业务，最后第四步，回归业务与技术的结合，用技术创新驱动业务，并利用商业可能性来推动技术突破。虽然这不是最终状态，但对于工程团队来说已经是一个非常可以接受的状态了。差不多从2018年5月开始，我开始推动前端团队步入业务。无论是技术预研还是业务场景挖掘，我们在做好业务支撑的同时绞尽脑汁思考。这么多很酷的前端技术，怎么和我的业务有关系，怎么找到产品经理做不到的地方，找到新的方法为业务创造可能性，所以在这一点上，因为会触及公司的核心商业机密，我会继续给大家一个早期脱敏的案例，供大家体验。当我们的移动生态全是APP的时候，微信生态也在蓬勃发展，那么如果产品延伸到小程序，我们怎么支持呢？要知道，此时公司内，包括产品在内，没有任何业务有类似的具体计划，但是每个人都会有一些非常想象的想法和概念被抛进去。这时候工程师和业务方一起去用户现场出差，评估小程序的落地可能性。回来后开始做小程序的技术预研。通过这个过程，我们在业务和产品上取得了领先，并进行了必要的技术储备，从而为快速打通微信生态，进入小程序新的载体阵营奠定了关键的技术基础。如果这时候工程师没有主动进入业务的意识，业务方是完全不可能有信息甚至不愿意进入一个新生态的，所以等到团队中的一些工程师能够培养出这种意识和能力。这个时候，我觉得是时候对技术栈做一个长远的规划了。2.技术栈规划是我带队前10个月。其实我也尝试过做零碎的技术栈规划，但效果并不理想。一是客观的基础设施基础不满足，很难做到相对可靠和可执行。一是团队成员的整体意识，包括个人能力没有上来。这个时候去做就有点适得其反了，甚至会引起团队成员的抵触情绪。总结来说，小而相对零散的技术方案是很有必要的，但不推荐。把大循环打垮，做大做全，大概1到1.5年可以搞定。ReactJS——技术栈归一化的第一次大规模应用无论是PC端的RN还是ReactJS，前三年小菜前端的React技术栈已经统一，只是归一化不规范，以及老应用还有原生架构的历史包袱，但总的来说到2017年下半年，React技术栈加Webpack是团队的标配。这个归一化的技术栈，结合背后的NodeJS能力，也孵化出了我们的两大核心前端框架：客户端RN框架BrickPCERP单页框架HighwayNodeJS——第二个大规模技术栈锁和归一化我们将回归到NodeJS，也就是2017年初的初步使用，到2017年底的深度使用。从2017年底开始，NodeJS成为了团队的核心能力。通过它，我们实现了RN的所有基础设施，如脚手架、组件化、代码验证、机器打包、白名单热更新发布、包安装成功失败和跟踪、终端用户访问行为数据可视化、终端操作异常监控和赋值等，所有App都重构为一个固定的RN版本，有最新的路由。除了支持客户端基础设施，NodeJS也为我们开发内部系统——服务端能力打开了一扇门。这扇门对前端和公司都有很大的用处。大的好处是站在前端的角度，可以掌握更多的技能，支持更多的业务，更多的玩技术6.站在公司的角度，不用大规模使用前后端的资源产品和运营，前端工程师可以独立完成与业务耦合度相对较低的业务，是非常划算的投入产出比，省钱又省时。然后在NodeJS技术栈上，我们成长了很多能力，为业务提供了很多帮助。对于团队来说，已经沉淀了一个核心服务器框架：Node服务器（基于Egg）框架Cross开发的Cross，因为我们这里一路使用ExpressJS/KoaJS/ThinkJS，对框架和功能进行自定义升级整合我们想要复用还不够规范和严谨，直到我们使用了EggJS，基于它强大的契约和插件机制，可以很容易的集成过来，定制我们自己的框架。我们会在2018年下半年开始这个框架的定制，一直到年底。GraphQL——第三次小范围的技术栈尝试。GraphQL在2019年肯定会成为一个比较高频的词汇，我们从2017年开始使用，2018年4月直接开发了一个聚合数据服务系统，集成到我们的网关中，提供了为每个App定制数据的能力，我们已经尝到了甜蜜了许多，也遇到了很多阻力和调整。我们将在2019年继续培育它，至少在特定领域。使用的比例。还有一些数据采集、处理计算、可视化的组装层，我们都交给了Python、C#，甚至Rust的尝试。这些只能算是技术预研，不能称为我们的核心能力。不是核心技术栈的演进目标。MPVue/Vue——??第四次大规模小程序技术栈归一化如果说GraphQL是我们遇到的惊喜彩蛋，那么Vue就是让我们惊喜的彩蛋，我们原本的进化路线并没有包含它，只是限于复杂性我们的业务和当时市场上可选方案的局限性，最终选择了MPVue作为我们的小程序框架载体，自然没有考虑京东。对于生产环境，MPVue的使用虽然给我们带来了很多可能和效率，但是也给我们带来了困扰，就是技术栈在团队内部存在一定程度的碎片化，毕竟在语法上和React不同和生态到目前为止，基于小程序的生态，我们以MPVue为核心的小程序技术栈，基于这样一个终端领域实现了常态化。所以总体来说，整篇文章之后，我们会发现我们的技术栈的演进会随着团队能力基础设施的成熟而变化，也就是一定的团队管理和成长，也会和我们的业务强相关，生态，另外，技术栈规划确实是一个看起来很客观但实际上相当胜任的工作。里面夹杂着很多因素，不同时期这些因素的权重也不一样。团队强的时候可以做长远规划，硬核一些，团队弱的时候可以灵活一些。所以从2018年下半年开始，开始做比较硬核的技术栈和架构规划，也就是开头的图：一共十二个主题和方向：节点服务，配套工具，业务系统，运营维度、监控等前端基础框架支持未来几十个甚至上百个PC/H5ERP/Saas工具系统。/运营提供产品设计和业务调整决策端性能监控和跟踪，为端可靠性和稳定性提供保障端数据计算中心，提供可视化、图形、图像和视频多媒体的高性能计算服务构建和部署，提供多端整体开发测试，打包，发布，部署，提供客户端反向运维能力，为社区/CRM/人之间的新型链接关系，提供必要的技术底层安全防控，提供安全监控，告警、拦截等护航保护平台全终端组件化，为跨终端和未来智能组装交互研究提供低成本可复用的UI组件，用于交互体验、ABTest、用户行为价值、设计表达输出工具和方法论/数据报告透视和可视化，为整个公司提供了友好的报表可视化解决方案，可以快速生产和维护，并朝着这些主题的方向不断演进和升级。最后，确实很难在业务支持、技术价值、个人成长和组织升级之间达到理想的平衡。但是，基于创造更多商业价值的核心论点，我们也在不断地寻找场景，寻找突破点。行动是我们作为管理者和技术骨干必须坚持到底的。在任何时候，这都是优秀工程师和技术决策者的责任和宿命——对人负责，对结果负责，借患养人，借人成才。最后，作为一篇预热文章，本文旨在为大家输出以下主题：输出一个团队从0到1的成长过程总结，从野蛮到自动化运维到社区，帮助更多的小团队少走弯路量化的方式将困惑、沉淀和方法路径聚集在小菜前端，给团队带来更多的创作成就感。从更多的角度，进入团队管理/技术进化/个人成长的过程，探索工程师团队的价值最大化。如果大家感兴趣，我们小菜前端团队会集思广益，编写并出版一本关于前端职业、技术成长和团队成长的小册子，回馈给大家。记得在文章后面留言求需求。.
