基建的搭建，不仅是对前端团队内部提效，也是对外影响的一种较快的方式，投入产出比较高。
中小团队由于其资源限制，对于基建的态度，我都是推荐尽可能采用业内成熟方案，避免完全自研。
其一是，投入成本较高，
第二是，烂尾率高，中小公司无法确保有资源，在这个上面的长期投入。一旦烂尾，对于公司已接入项目，则是个灾难。
但我们可以，站在巨人的肩膀上，做事情。集成公司认证体系或其他基建，进行二次开发。
当然，这个成本，也是需要慎重评估。
接下来，我将结合我自身的生产实践，和大家分享，基建常见几个领域上，中小团队可以用极低成本尝试的方案。
每个领域，在这篇文章中，我只大概讲述下。有感兴趣的话，后续会有针对每个部分的详细文章。
脚手架
在没有太多要求下，无论你处于哪个技术栈，都推荐直接用官方脚手架。
但这种简单的方式，会存在一个问题。
很多团队，都会有自身定制的一套构建与项目配置，这时候就不可避免地出现封装的情况。
此时对于中小团队，就需要谨慎了。因为中小团队无法确定，公司能够在基建方向上的持续投入。
因此，就要提前给自己一个假设，如果明天脚手架不维护了，已接入项目，该如何能够低成本进退。
这个在封装的设计方式与尺度上，是值得深思的。
低代码搭建
业内方案较多，各有侧重。基于我个人实践来谈，在中后台场景下，还是首推百度的 amis 。主要是如下几个方面：
- 至今已发展多年，覆盖大多数中后台场景，成熟度高
- 设计方向偏零代码，可视化程度高，对于非前端人员很友好
- 维护频率较高，至今几乎一个月发一个正式版本
- 它主要分为「编辑器」与「渲染引擎」两部分，中间基于一份 JSON 协议做桥接。模块关系较为简单，后续平台化发展，围绕这份 JSON 即可。
- 自由度高，几乎无配置不出的中后台场景。只是看配置的复杂度。
这个方向，最终还是要平台化。虽然有一定的实现成本，但如果只实现核心流程，成本是较低的。
无非就是「编辑器生成 JSON」-> 「保存 JSON」-> 「渲染引擎渲染 JSON」。
移动端方面，由于其场景更偏向展示，视觉变化较多。基于 amis 虽然也可以完成，但要从细粒度开始搭建，成本还是过高，手动编码可能更高效。
同时，amis 协议是基于 JSON ，再加上 amis 本身设计的一些限制，组件的 Treeshaking 实现成本较高（我们有实现，但不推荐，效果提升有限），但如果全量打入组件库，其包体积与性能，也不太符合要求。
业内的其他方案，有做得很好的，但投入的资源，可能也是中小团队较难承担的。
**错误监控
**
推荐私有部署 Sentry 。申请一台硬盘较大的机器就行，如果还有压力，就只保存近一周数据。
错误监控方面难点，并不是把服务搭起来，而是，真正的使用阶段。
见过太多被海量生产错误淹没的情况，有用的没用的杂在一起，这时有监控和没监控，没太大区别了。
所以，错误监控要想取得实效，与其说是个技术问题，不如说是个管理与实施问题，强硬的制度，或许是必不可少的。
NPM 私服
推荐私有部署 Verdaccio。这个较为简单，只是有几点建议：
- 私有包只允许发布到公司域下，避免与上游官方源相撞，引起污染。如 @xxx/packageA
- 私有包发布只允许用固定账号与密码。
上述均可在 Verdaccio 的配置文件中完成。
组件库
基础组件库推荐直接用社区成熟组件库，主题不同，可通过定制主题或直接覆盖样式的方式解决。
业务组件库，可考虑使用阿里飞冰的方案，较为成熟，也有相关插件支持。
方法库
基础方法库建议直接用社区成熟方案，列出各场景下的推荐依赖，如时间处理，URL 处理，缓存处理等。
如更加严谨与安全，可规定版本。不建议再包一层。
业务方法库，可酌情封装。
接口协作平台
接口平台推荐 YAPI。个人认为，应该没有其他方案，从全面性上，能够与 YAPI 齐平的，真正的一站式。
同时，其独特支持的「期望」能力，在实际实践中，具有较高价值。能够在 mock 的场景下，轻松切换与模拟，各种返回值场景。
好了，先简单聊这么多了。上述都是基于自身实践经验，以及站在中小团队视角，聊的一些想法。
有错误的，望包涵与指正。
欢迎关注公众号：feniubi
