前端工程化其一：小公司有必要实施吗？

你有没有经历过“shi山”代码？有没有经历过明明因为代码完全没有做任何封装，使得自己在做业务需求时疲于奔命反复“CV“？又或者，一套高度封装的组件，像巨龙守护的财宝一样，除了它的主人，拒绝任何人接近它？如果你有碰到过上述的情况，甚至有过之无不及，那么我们今天可以聊一下，关于工程化的问题。

工程化概念

你好，我是应怜。我长期的从事软件开发的工作，尤其是最近和前几年，在三四线城市和小公司工作了大概有四五年时间，我几乎长期都在中小型企业中工作，可以说，我们绝大部分人经历过在中小型企业里待过；我最近主要从事的岗位是web前端，今天我从软件工程化这个切点，再拓展到前端的工程化。

首先，我们来看看AI关于软件工程化的定义

软件工程化是一种使用工程原则来设计、开发和维护软件的方法。这种方法注重系统化、规范化和量化，以提高软件的质量和开发效率。
软件工程化的主要目标是：
管理复杂性：软件系统往往非常复杂，需要有效的管理才能确保其正确性和可维护性。
提高质量：应用工程原则可以帮助开发团队避免错误，提高软件的可靠性和性能。
提高生产效率：通过采用标准化的开发流程和工具，可以提高开发速度，减少错误，使软件开发更加高效。
软件工程化包括许多不同的方面，如需求分析、系统设计、编程、测试、维护等。每个阶段都有其自己的方法和工具，以帮助开发团队有效地完成任务。

AI说的，我来简单总结一下，工程化是用来设计、开发、交付软件的一套方法论。ok，既然是方法论，那么它总是有边界的，同时也有它的适用范围。任何事物，都是如此。

挖坑的原因和切入点#

需求评估的不足

我们使用工程化方法论的最主要目的，就是为了交付，并且为了少加班，在三四线城市我所经历的加班情况，大多数都是由从项目需求分析开始，到测试交付这个过程中，把控的不力；它可能有多种原因，其中显著的原因是，需求的突击式改动 ，需求的突击式改动是由于其在立项阶段需求立的太满或者太少，换言之，要么一步做完，最后发现和用户想要的完全不一样，要么几乎是没做到点上，临近交付时缺斤少两，《代码大全》一书中告诉我们，软件工程就像盖房子，什么样的房子的构形在一开始都是要做好的，别墅的户型不能用来做公寓，反之亦然。

需求规划的坑，影响了后续所有的开发流程

开发工具链上的问题

直到现在，我们才正儿八经的进入关于技术、工具的探讨。这是因为软工本身就是一个开放型的学科，能达成目的的方式很多，重要的是开发者的道心。按照正常的流程来说，开发、技术上的因素理应最小，起码在boss、项目经理的眼里，是这样；并且市场上还有大量的从业人员，各类培训机构和网课层出不穷，什么样的技术工具都能教都能学，但是事实真的是如此吗？

ok，根据我的三线城市坐班体验来看，实则是不然的。这种差异主要是体现在开发人员对软件项目的误判，当核心开发对项目整体的概念知之甚少的时候，就容易产生错误估计（也有可能是boss本身也对项目整体不大了解）。

我就曾经做过一件很蠢的事情。我16年左右就到昆明了，17年正式参加工作，在18年的时候，入职了一家公司，这家公司要求我们做一个仿拉钩招聘的网站。boss的构想是将求学和求职两个模块融合在一起，而当时初出茅庐的我，误以为仅是一个课程软件。而没有考虑到boss想要的是一个整体的系统方案。

那么我犯的其中一个错误就是：官网型的首页，我没有使用生成工具或者 SSR 去做，而是自己用前端框架挨个写了一次，从样式、到设计稿、再到接口。

这个错误带来几个问题：现成的工具不用，后续的 SEO 怎么办，SPA 应用天然的吃亏；既费时又费力，所有接口都要和后端一个一个的对，即便有很多的商品的内容和一些静态内容。

当然，最后这个项目并没有上线，包括需求，公司运营的方针等等，我甚至都没做到需要改进 SEO 的时候，就已经被通知裁员了，这是后话。

还碰到过另一些情况，接手的代码放飞自我，中英文拼音混用，依赖包管理混乱，文件路径没个说法，想放哪里就放哪里，命名上的不规范，环境变量写在代码里等等。前端不同于一些 IOC 框架，它的自由度很高，在 Spring 等框架的支持下，文件的位置写错，编译都产生问题，前端能 run dev，但是也只是run dev，在没有工具和工程化思维的约束下，成功 run 事小，满屏的 类型错误 、undefined 事大，这些空类型的坑，在小公司带上线上环境是常有的事。

我见过最逆天的当属于：使用了 Element-ui 的组件，但却没有一个类型是正确传的。

诚然，最大的问题还是因为前端领域本身的特殊、规范多（cjs、ESM标准现在还没统一）、平台多样化、弱类型语言等等各种各样的因素，从而带来了各种各样的问题。不过我们需要记住，弱类型语言在实际开发过程中并没有减少太多的坑。

工具链、工程化理念关乎于人#

我分析了两个点，一个是需求，一个是开发，在大多数小型企业中，这两个往往就是业务的生命线，同时也是产品的生命线。

工具链解决的是人的问题，规范化、集中、分散、沟通、协调，工具链的应用得当，可以极大的影响交付效率和返工率；在开发过程中，无非就是两种情况，“要么就是我坑，要么就是别人坑”，而坑这个东西，会带来严重的负反馈的复利。在一个项目最开始构建的时候，给他的定性、定调，极有可能会影响这个项目最后成型的样子。一开始工具上的多或者上的少，要么就是拖后腿，要么就是完全不规范，最后自己也不知道自己在做什么，一旦项目的开发周期启动，人一多，班一忙，ESLint一开再一关，哪管它洪水滔天，最后就产生了垃圾代码。

工程化最终解决的是人的问题

要知道，软件工程是人在做，而软件工程化是人的问题，所有的工具链，它的性质是帮助人来兜底，所有人都会犯错，而没有人能一直写出牛逼的代码，大家一开始都是从菜鸟过来的。

结语#

我们讨论了很多关于概念上的、实际经验上的内容。后续的章节再聊一下分享一点具体工具。通过我的逐步分析，实际上开头的问题也能得到答案：“ 小公司有必要实施前端工程化吗？有必要。”，现在做的工程化合适与否，极大的影响后续的工作情况，为了不给自己挖坑，要根据自身实际的情况因地制宜。

稳扎稳打，向风生长，我是应怜，如果这篇文章对你有帮助，请点个关注，今天挖的坑，下次一定补上。