做技术方案，都需要考虑哪些方面，有没有一些范式约束?

Question

目前我的前端团队所做的需求是模仿其他产品提出来的，这种情况下，需求会在目标产品和自己的具体业务结合时发生变化，且现在的技术团队在做方案时，只会考虑到当前需求下的实现，对于方案的扩展性和合理性都无暇顾及。
比如，稳定性、扩展性、实现难易程度(有跨团队实现可能)、可识别性(自己隔周回看代码时是否容易理解，团队成员在理解代码时是否会出现偏差)，易维护性(排查问题是否方便)等。

Answer 1

1. 有钱上商业支持（特别是基础设施）
2. 开源项目需要考察社区活跃度、更新频率、金主爸爸是哪些、国内是否有比较成熟的案例（稍微不成熟的也可以跟进，但只能作为边缘项目，刷经验），还有就是 法律风险，点名 Facebook
3. 稳定性需要制定指标，用 Prometheus 之类的工具做线上资源消耗监测，用 Sonarqube 之类的工具做代码质量检测，集成到 CI 流程，力求技术债务不要一直堆积
4. 扩展性这个比较模糊，只能靠团队里有经验的人来做，因为这个跟业务有关系，唯一比较通用的是基础设施和业务代码尽可能做到能横向缩放，对于前端项目的话，我接触不深，能想到的可能就是私有组件库的积累、CLI 工具的二次增强等等
5. 实现难易度这个，考虑到你说的跨团队实现这种场景，我个人觉得更多的应该是文档这类知识留存管理，再一个就是技术选型在你所在的城市好不好招人、能不能招到质量过关的人
6. 可识别性，特定于前端方面的书可能比较少，《重构》、《代码整洁之道》、《程序员修炼之道 2》部分章节，都有对代码编写提供了一些范式，这个主要靠团队成员自觉，你们有时间的话也可以做 review
7. 易维护性这个算在第六点里，特别于你提到的排查问题，日志格式统一，日志信息详实，但做好开发环境（直接输出控制台）和线上环境（上传日志到服务端、弱网环境暂存本地稍后上传）的区分处理.