前言
这篇文章的完整标题是：多人研发的前端工程团队如何做技术方案选型？
我当前所在的前端团队有 7 名 Android 开发、8 名 iOS 开发、16 名 H5 开发（其中 1/3 是内包）。除了 Android/iOS 客户端研发之外，团队成员需要具备全栈开发的能力，研发涉及的系统有 Chair、Needle、Cube、H5。
团队负责的业务场景众多，远超团队成员数量，再考虑人力资源、项目排期、风险等问题，不可能始终让一个人持续维护一个固定模块。
作为一个前端工程团队，需要思考如何降低多人研发的复杂度，降低理解成本、开发成本、维护成本。
一、方法论
写易于开发者理解的代码。
业务前端的工作是将产品需求转化为代码实现。在多人参与的持续迭代过程中，复杂度主要来自于开发者对既有代码的理解程度。
在这个条件下，好代码的特征应该是简单直白、易于理解的。
当技术方案需要在“高复用”、“框架新特性”、“算法巧妙”等与“易理解”之间做权衡时，应该优先选择易于理解的方案。
二、方法
高内聚、低耦合。控制抽象等级。
复用的迷思
日常研发大家都强调复用，甚至用复用的程度来判断方案的好坏。为什么要复用？
- 研发提效
- 业务要求保持一致性
- 包大小
- 架构合理性
反思
复用意味着需要做一定程度的抽象。在业务前端团队中，当某个相似的功能多次开发，应该考虑复用。不要在刚开始开发时，就想着如何复用。
业务需求里唯一不变的就是变化。（即使产品经理跟你说，两个场景的卡片完全一样，也不要相信。）
- 优先需要考虑的是将易变的部分与不易变的部分隔离开来。易变的部分：核心 UI；不易变的部分：非核心 UI（e.g. 下拉列表、免责声明）、框架代码、祖传代码。
- 面向变更可扩展是评价好的设计的重要标准。
总结
当需要实现一个业务功能，可能有一万种代码写法。但所处环境不同，最优解也不同。本文是给多人研发的前端工程团队如何做技术方案选型提供一些思路。
内包研发、AI 生成代码、数字化运营，随着技术的发展，编码的环境与以前大不相同，我们需要更多的思考如何在当下做技术方案设计。比如，D2C 生成的业务卡片用完即弃，如何不出问题的运行到页面里？
Write Stupid Code 是我推崇的编程理念。我之前在某个会议上提过，大部分人不置可否。
简单代码需要更多的深思熟虑，你应该考虑自己几个星期后或者其他人阅读代码时，是否能够立刻理解其含义。