外包公司
外包分两种，人力外包和项目外包：
- 人力外包上限是千亿级别企业。
- 项目外包上限是中型企业。
小型创业公司
- 前端人数： > 3 人
- 产品类型： 产品不是非常成熟，比较新颖。
- 项目流程：不完善，快、紧促，没有固定的时间排期。
- 技术栈： 没有历史包袱，技术栈较新、无前端架构师甚至无高级前端。
- 项目安全：几乎不会额外考虑安全性。
- 基础设施：几乎无。
- 系统可用性：几乎无具体标准。
- 前端工程化： 使用业界方案，怎么快怎么来。
- 学习氛围：自学。
中型创业
- 前端人数： > 20 人
- 产品类型： 公司有自己较成熟的产品，有一定的用户量。
- 项目周期：快、紧促，有大概固定的时间排期，时忙时闲。。
- 技术栈： 没有历史包袱，技术栈较新、有前端架构师或者 teach lead
- 项目安全：考虑一些简单的安全问题，例如 sql 注入、xss、csrf 等，依赖第三方库。
- 基础设施：错误监控、日志收集、代码回滚三件套。明显的体验就是有时候做新功能或者改 bug 的时候一不小心就把之前的代码改炸了。
- 系统可用性：几乎无具体标准。
- 前端工程化：使用业界方案，用文档来做规范化和沉淀，会有一些跟业务无关的技术需求的沉淀。
- 学习氛围：自学 + 讨论。
传统 500 强企业
- 前端人数： > 50 人
- 产品类型：产业转型，大多数是内部产品，例如一些 saas 产品、对内使用较多。
- 项目周期：处于行业转型，较快、较紧促，有大概固定的时间排期，时忙时闲，或者是都挺闲的。
- 技术栈： 有历史包袱，技术栈较老、技术栈多，会有前端架构师或者 teach lead。
- 项目安全：定期会请专门安全团队做安全检测。
- 基础设施： 会有 A/B test、数据埋点。会尽量去避免出现错误，流程还是没有达到规范化，明显的体验就是* 不敢重构，不敢升级依赖，不敢更换系统，不敢接锅，能跑起来就行。
- 系统可用性：没有或者 3 个 9
- 前端工程化：使用业界方案，用文档来做规范化和沉淀，缺少自己内部的前端定制化工具库、组件库等。
- 学习氛围：自学 + 讨论。
百亿级别公司
- 前端人数: > 50 人
- 产品类型：多个成熟的产品，且成为行业龙头或者独角兽
- 项目周期：两周一迭代，项目紧，较紧促，有大概固定的时间排期，时忙时闲，有项目间隔期。
- 技术栈： 有历史包袱，技术栈较新、技术栈多，会有前端架构师或者 teach lead。
- 项目安全：定期会请专门安全团队做安全检测。
- 基础设施：主要还是配置化、工具化、完善的基础设施，会考虑性能问题，能在客户发现问题之前，就发现部分问题，能快速定位问题，并解决，明显的体验就是有专门的团队去维护这些标准或者操作流程，原则还是人操作工具来提效，去约束人。
- 系统可用性：普遍 4 个 9 以上。
- 前端工程化： 用文档和工具结合做到规范化、例如代码规范、代码校验、代码测试覆盖等等，能沉淀出一些流程脚本，代码库、工具、经验、脚手架。
- 学习氛围：每周分享，了解各种前沿技术。
千亿级别公司
- 前端人数: > 50 人
- 产品类型： 多个成熟的产品，成为行业龙头或者独角兽，有垄断趋势。
- 项目周期：两周一迭代，项目紧，并且急促，无项目间隔期，压力大。
- 技术栈： 有历史包袱，技术栈新、技术栈多，会有前端架构师或者 teach lead。
- 项目安全：发布前会有自己的安全团队做检测。
- 基础设施： 沉淀已经成为系统化、平台化，中台化，能真正做到用平台来提效，来限制人的行为，明显的体验就是即使没了维护标准的团队，这个流程还是能存在且正常流转，例如，上游服务挂了，也不会导致下游服务挂。内部团队或者外界厂商能依赖某个服务的 api 直接构建一个完善的个性化应用。
系统可用性：普遍 4 个 9 以上。 - 前端工程化： 一些沉淀已经成为业界标杆。
- 学习氛围：每周分享，了解各种前沿技术。
总结
上面结论都是自己的一些体验或者和身边朋友的讨论得出，大家也可在评论区讨论
具体其实还能划分得更细，或者还有没覆盖到的地方，又或者每个公司都有特殊情况，结论大家也不用太认真。
公司没有好坏之分，适合自己的才是最好的。
最后
