版权归作者所有。商业转载请联系Scott获得授权，非商业转载请注明出处【务必保留全文，请勿删改】。一切都可以分为三个版本：v1.0进行中，v2.0正在规划中，正在预研调整中，v3.0正在构思和形成一个粗略的计划，可以看作是每一个之后的沉淀在稳定的技术栈下完成。所有的任务都可以分为主线和支线：主线是性能，支线是惊喜，技术栈的规划和执行也不例外。本文写于2019年3月，试图帮助大家梳理团队技术栈演进的一些实践。首先我们来看小菜前端团队。关于技术栈语言栈（包括框架）演进的结论，将有助于你在时间线上进行规划。上线时间：2017年7月：进行中：RN/React（PC）预研：NodeJS（Express/Koa/ThinkJS/Egg）/RN骨架设想：GraphQL/RN组件化/脚手架/自动化测试2018年7月：沉淀：RN/React(PC)/NodeJS(EggJS)进行中：RN骨架/脚手架/GraphQL预研：PC框架/NodeFramework/MPVue/RN组件化概念：Python/Rust/Go/RNFramework/Rust/多端获取和埋点/自动化部署/视频流处理/DockerMarch2019（当前）：沉淀：RN/React（PC）/NodeJS（EggJS）/GraphQL/RN组件化/RN骨架/视频流处理进行中：NodeFramework/PC框架（兼容H5）/MPVue/可视化/自动部署预研：Python/Go/多端采集埋点/Docker设想：Rust/AndroidSDK/小程序-H5统一框架/全链路服务监控/直播pushandforward我们直观地解释一下：沉淀：团队中一定数量的同学已经掌握了技能或者方案已经成熟，进入维护期；进行中：团队还没有掌握好，方案不稳定。改进还是需要大量的迭代，需要不断推进；预研：本地测试和尝鲜，主要是跑原型测试和接入小项目，没有正式的项目开发；设想：结合业务和技术痛点，跑demo，看文档，主要以脑洞思路和YY为主。所以对于小菜的前端团队来说，我们的方法论是从构思到预研，从预研到实现，最后落地。有时候想象的东西会失败或者很遥远，比如Rust的实现；有时想象的东西会很快实现，甚至跳过预研，比如可视化和GraphQL；有时候已经实现的东西并没有带来多大的价值，反而是在白白投入，比如我们早期的自动化测试，但是一般都是遵循这样一套流程来推动整个技术栈的演进。下面我们就结合这几个阶段，看看如何提前规划和调整技术栈。技术认知和业务理解是前提假设，通常基于技术的更新周期，必然有一定的工具链或语言栈升级。另外，更多是基于业务发展带来的与用户对话的新场景、新方式，预测未来业务可能需要的技术储备。但这个领域需要深入业务，基于对业务的长期理解，才能做出更准确的预测。除了业务，那就是对技术更加敏感。其实做这个敏感度有很多简单的方法，比如研究业务类型相似，规模比自己大的公司，看看他们的技术栈现状，他们要偿还的技术债，他们的a应用水平某些技术，以及他们比较领先的技术解决方案。这些信息可以通过参加技术会议或面对面交流获得。当然，你不能得到它就复制它。你需要结合你的团队和业务情况，看看是否匹配。成本高，价值高。小菜早期向其他公司学习，包括现在。很多。比如在大搜车的前端和无线架构团队，我了解到Node基础设施和ReactNative组件化带来的价值，所以我也将Node作为核心技术栈进行了推广，最终取得了不错的效果。除了研究这个非常实用的参考方法，其实就是关注社区开源方案的动向。尤其是大公司和重大项目大改版的背景，看社区反馈的方向，基于这些官方八卦，能引发很多猜测性的思考，比如Flutter的野心，ReactNative的设计大结局，这些担忧都会让你对技术越感兴趣，判断就越敏感。综上所述，本着不追风逐影的精神，尽可能定期关注技术动向，对技术方案有更强的敏感度和成本感知，寻找更多的参考模型公司进行差距比较，并进入自己公司的业务参与更多的讨论，对业务方向和规模化程度形成自己的判断，并以此为基础想象团队未来一年左右的技术前景。有了这个前提，就可以做预研了。技术预研需要以最小的成本进行实践。当你对设想的技术有了一定的判断后，就可以在合适的时候去做了。预先研究。预研选人时要注意两点：找学习最快的技术精英做预研，用最小的项目原型试，用第三方（有偿）替换部分这需要自我研究。三点非常重要。前者不仅可以最快、最简单地得到预研结果，还可以从过程中观察先行者的速度来评估普通工程师的入门成本。后者是侵入到现在的一些产品系统中，保证最小的副作用和成本。最低的成本并不意味着最少的思考。真正的过程和问题进来了，就变得透明了，而不只是储存在头脑里。2017年年底，我们想做一个RNAPP自动化测试的解决方案，集成到我们的打包系统中，让测试人员或者PM可以发起一个测试流程，自定义关键测试流程后，机器可以自动打包模拟测试流程，最后交付一份测试报告，我们看透一些程序角色和问题点：同时，我们也看穿角色之间的合作关系：然后放入实践。实现的时候可以中继只是借用了力，我们用了阿里的MQC来做模拟和输出报表的过程。最初的流程和技术栈图如下：可以发现我们也算上了第三方的成本，这样我们可以快速顺利的进行流程，即使预研失败了，影响也不大.如果预研成功，可以选择在合适的时间立项进行开发。在上面提到的这个项目中，我们其实发挥了很大的想象力，也取得了一些初步的成果，但是我们做的过于激进（稳定后端的日常环境还没有准备好），导致项目最终被搁置，但是这样一个最小成本实践的方法论可以给大家参考，我们其他的项目都是按照这个方法进行前期准备的。在实施过程中，需要坚定地判断一个技术方案能否实施。除了预测的准确性之外，还有一个非常关键的因素就是技术或方案的确定性。因为有时候一个计划看起来不错，但实际执行起来会遇到很多阻碍，甚至会走很多弯路。在这个过程中，会有很多负面的声音包括压力，一不小心就放弃了，之前的努力都会付之东流。因此，项目一旦获批启动，无论成功与否，都不能回头摸黑。最大的忌讳是：在项目立项的过程中，一遇到阻力就动摇，放慢推进的速度和力度，这是对整个团队的不负责任。不仅会影响同学们参与项目的工作积极性，还会大大降低项目的可行性和成功率。最重要的是，周期可能会因为波动而变得很长，从而失去最黄金的技术应用窗口期，从而失去为企业创造更大价值的机会。举个例子，我们在做小程序的时候，团队的经验是零。经过构思和预研，我们毅然把MPVue和测试项目结合起来，用两周的时间做出来，为商务玩测试打下了基础。在这个过程中我们承受了巨大的压力，但最终证明这样的坚持是非常正确的，整个公司的商业生态都因此受益。历史包袱必须适时重构。技术栈的更新必然会带来旧系统的不兼容。比如你有一个jQuery的老系统，如果三四年后你不重建，以后再招新的同学进来，就很难了。会受到旧技术栈的干扰。如果你只知道Vue/React，那你现在就得学jQuery，而且你必须逐渐对jQuery非常熟悉，才能维护原本基于jQuery开发的比较复杂的页面和组件。如果是老队员维护老系统，自然会占用老学长宝贵的时间去做这些难度相对较低的项目，成就感也会大大减弱，所以技术的循环堆栈替换可以加长。但是当整个团队的技术栈更新的时候，老系统肯定要靠人力重构，除非这个系统非常非常稳定，几乎没有基于它的额外开发，那你可以再拖几年.总结一下2019~2020年的技术栈规划，相信大家已经从之前的时间线上看到了。秘诀就是：技术感知/业务深度渗透/最低成本预研，尽可能打开思路。而明年我们押注的技术栈是：Python/Go/多端采集和埋点/Docker/Rust/AndroidSDK/小程序-H5统一框架/全链路服务监控/直播推送转发，也是这张图的具体反映：这两年不管是线下线上的面试还是技术分享，Scott认识了很多前端同学，因为团队原因，个人原因，职业成长，技术方向，甚至家庭等等。原因就在理想国与现实之间，在放弃与坚守之间。有不断的波动和辛酸。你可以和我谈谈南方和北方。可以了解更多工程师的缘分，多看看，多听，Scott微信：codingdream，也可以关注Scott语雀，跟进最新动态，本文未经允许不得转载，请联系Scott获得许可，否则直接在公众号转载，尤其是删减内容后，投诉一律直接处理。
