背景

之前从事了相关工作，相关产出，技术细节，达到效果

不同阶段关注的点

前期

预计规模 3~4 人

规范脚手架，技术栈。

中期

预计规模 5~10 人

提升协作效率，提高项目复用性、稳定性、可持续性。

后期

预计规模 10~20 人

孵化内部产品，探索前沿技术。

感受

何为工程化？

  • 具有一定量级的通用性解决方案

    前端工程化与常规应用开发有什么不同？

  • 除了实现功能，更加考验设计能力。要做到向前兼容，易于理解易于扩展。

    容易进入的误区

  • 不能为了技术而技术，不能强行推轮子。

    困难的点

    客服 + 运维

维护好文档，否则你会变为一个客服，为每一个人解释其中的细节。那么，你将没有自己的开发时间，不断被打扰。

关于目标制定

制定的目标，要看清楚它的价值到底是什么？为谁而服务？谁才是痛点？

  • 应避免政治性的任务，首当其冲为前端整个团队服务和解决问题。
  • 避免技术意淫，为了技术而技术。
  • 适当接一些业务需求，不要脱离一线业务，这样才能站在使用方的角度思考解决痛点。

    关于基础建设绩效考评的心理准备

    基础建设是一个长期才能见效的过程，一般来说绩效都没有 C 端开发那么见效快。而且，做的好会「润物细无声」，做得差出了问题会马上找到你。

价值

  • 提升扩展性，支持 web/mp/node 各类小程序，并统一接口。
  • 减少协作依赖，提高协作效率

    设计思想

    工程化的目的是标准化而非统一

    相信一句话大家也听过无数遍了“前端唯一不变的就是变化”，如果要做到统一那么一定要接受技术的落后。所以制定标准化的流程，各个模块解耦合，让每个流程提供标准化的接口可随时替换。使用者对工具不满意，按照标准化文档重新实现一个模块替换上去即可。

开放与易用

通常来讲做到配置「开发」一般不能保证「易用」，做到「易用」很难保证配置「开放」。要平衡其中的关系，设计好的接口，做到即「开放」又「易用」。

开发符合人类认知常理的软件

好的软件一般符合常理，在没有看使用文档的情况下也能快速上手。比如：拿到一个前端项目，我们会先查看 package.json 配置文件，一般执行 yarn start 就能启动。
如果做不到符合常理，那么只会徒增使用者的学习成本，降低使用体验。