在过去的两三年里，我自学了一点前台的知识，也有幸在一个小团队里经历了从0搭建前台项目的全过程。 写一下我在这次经历中的一点点体会。 规范代码基础设施的第一点自然是代码风格。记得早些年我还在争论tab是两个空格还是四个空格。 虽然听起来有点匪夷所思，但是团队的代码规范就是细节到空间层面。 Linterlinter就是所谓的代码美化工具，最常用的有eslint——javascript美化工具和stylelint——CSS美化工具。 小团队安装lint后，基本不考虑规范，就用airbnb，google等大厂的标准配置(一般没心思指定括号和大括号中间隔几个空格，更美观) 这些lint工具带有fix功能，可以自动修复一些小缺陷，比如空格、换行符、分号、逗号等。结合vscode插件，可以在编码阶段显示错误或警告，将codeActionsOnSave设置为fixAll也可以帮助你修改或完成大部分lint问题。 Git HooksGit Hooks就是在提交代码之前再做一次检查，一般包括上面提到的lint检查、commit list(git消息格式检查)、单元测试、前台构建错误检查等等。 越匹配越慢。小团队至少应该包括lint和commitlint。 我用的是一个叫husky的工具。只需在package.json中添加一个钩子，就可以在git提交时检查它。 //package . JSON " husky ":{ " hooks ":{ " pre-commit ":" yarn lint "，" commit-msg ":" commit lint-ehusky _ git _ params " } }，CI验证的前两步发生在开发环境中，实际上可以手动跳过；经常发生在你身上，有的人在安装之前直接提交依赖(lint和husky)，有的人会强行注释掉hooky。 不要惊讶，这就是现实。 但是，他们无法绕过CI中的验证，因为它是在服务器端进行的。 所以CI要尽可能覆盖各种规则检测，包括上面提到的lint、单元测试、构建、e2e测试、代码分析等。，并在出现错误时立即恢复代码。 //package . JSON " scripts ":{ " lint ":" eslint & amp；& ampStylelint "，" unit ":"jest "，" build ":"nuxt build "}，CI的选择可以是Jenkins，gitlab或者少数云服务提供商的pipeline。 小团队还是尝试购买云服务，价格也不贵；有些小厂成本核算能力弱，以为自己建厂划算。 其实CI最基础的投入就是服务器，机房空调，电费，容灾需要投入人力，不划算！CI有很多功能。在这一节中，我们仍然关注lint。 如上所述，CI验证是绕不过去的，但也不要太依赖CI。频繁的错误不是一个健康项目的表现。 在项目管理中，前两个仍然是最重要的。 管理者需要经常介入:及时更新lint工具，覆盖更详细的验证；经常观察团队代码缺点，加强或修改一些特定的风格配置；过于牵强皮棉检验也应被忽略；及时；少量的lint规则会给开发环境带来不便，所以开发模式和生产模式可以分开解决；我得和一些开发商当面谈谈。有些人喜欢使用注释并禁用lint check。 编码IDE集成开发环境基本没什么好犹豫的，就是vscode。 我用过webstorm，先不说收费，真的太卡了；Sublime和atom也用过。都已经过时了，没必要再纠结了。 在开发阶段，您可以推动。vscode文件夹到git:launch . JSON中的调试命令要从一开始就准备好；Settings.json存储了常用的插件配置，新手可以开箱即用。 网络包& ampNodemonWebpack是生产环境中最主流的打包工具；在开发环境中也是不可或缺的，热加载真的很牛逼。 不过项目大了就有点卡壳了。 最近vue的作者尤雨溪同志正在实现一个叫vite的工具，可以在开发环境中根据需要进行热部署，希望尽快完成。 Nodemon是后台nodejs的热加载工具，结合vscode也可以完成调试功能。 尽快在团队中普及chrome和vscode的调试方法；真的，很多人一生都在console.log中度过 巴别塔& amp在老派开发的印象中，升级语言postCss就意味着骨折；但是现代的前台根本不是这样。 前台会有各种编译器帮你把新语法转换成旧语法，不用太担心兼容性问题。 Babel和postCss是最著名的编译工具，帮助你将JS和Css分别编译成较低版本浏览器支持的语法。 在开发阶段，功能一般在Chrome或Firefox等现代浏览器中完成，然后需要一点时间来确认IE功能。 当然，低版本浏览器的支持应该是自始至终的，一旦文件中途坏了，还是很难恢复的。 巴别塔:今天就使用下一代JavaScript。post CSS:用JavaScript转换CSS的工具。刻意保持低版本的语法是无知的。听说有些工厂为了支持IE11还在强制ES5语法。无论时代如何变化，从开发者的角度来看，这都是一场灾难:无论是个人的工作经验，还是技术的成长，都不会带来任何有益的帮助。 ES6之后的JS语法，比如Promise，class，arrow函数，optional chain等。，是开发效率的保证。 网格布局是CSS新特性中最耀眼的。可以说html语义标签和布局功能的分离是一个划时代的进步。 当然，跟上新语法是有成本的。首先，确保团队里写的是同一个时代的代码。 老实说，不是每个人都愿意学习新的语法。 我还能看到在我参与的一个项目中，callback和async/await共存于同一个文件中——es3和es7之间的代沟。 与JS相比，CSS开发的下线更低。很容易看出，一个极其简单的布局会遵循大量冗长的边距、填充、高度、宽度……没有多少人会写flex布局，更不用说Grid了。 所以基础建设很重要，学习不能停。你应该像学习java和C++一样学习JS和CSS 我尝试过每天早起“阅读”技术书籍。只需要两三个月，即使是我这样的后进生也能取得很大的进步。 UILibrary UI库请优先考虑大家熟知的开源框架，这是用脚投票的结果；不要太自信，也不要搞一些奇怪的风格。 众所周知的组件库并不存在，能提供可维护的基础控件的公司也非常有限，也是大家提到的无数问题的结果。 我的母公司曾经打造过具有我厂特色的材料设计“车轮”，耗费了无数的工时，现在已经荒废了。 但是很多人还是雄心勃勃，总想再来一次。 除了基本的UI控件，Storybook还需要进一步封装每个产品的业务组件。 如何管理这些组件将是一个难题:怎么说呢，这些UI组件至少可以独立显示和调控吗？有一个叫做Storybook的开源库提供了一个绝妙的解决方案。 它是一个沙盒工具，可以隔离构建块的UI组件。 当我在开发的时候，我花了很多时间写故事书。一般步骤如下:创建一个具体的业务组件(如Button.vue)，创建一个对应的story book next story book——button . stories . js编写组件函数。在story book-支持热加载-调试风格、参与和事件响应git commit & amp After的所有业务组件完成后，放入页面进行排版、api集成等。最后，前三步工作都应用在沙盒上，不用担心到处污染。之后的bugfix大多在沙盒中完成，高效简洁。 推荐的文件结构如下，组件与storybook一一对应。 button |-button . vue |-button . stories . js我用storybook的初衷很简单:项目大，webpack热加载太慢；在沙箱中调试组件比在页面上调试要高效得多。 多写还能发现更多的好处:组件一目了然，减少组织内部的重复之轮；由于依赖全局魔变的几个组件很难放入storybook，我又对它们进行了重构，使得功能组件和布局组件的划分更加清晰，项目更容易维护。 Storybook几乎支持所有主流的前台框架，建议一开始就安装。 Test刚入职的时候，领导让我写单元测试。当时我就觉得很奇怪。我为什么要判断少量的合理投入和产出？过了很久才感受到测试的意义:防止别人修改你的代码；当代码被修改，甚至不能保证输入和输出的正确性时，会发出警报。 测试覆盖率低，我觉得几乎所有的软件公司都是这样。 早些年，人们认为前台写测试很难，但Jest、Cypress等框架出现后，前台测试并不比后台写测试难。 但大家的印象依然是这不是态度的问题，而是认知和成本的问题。 我看过一篇关于外包公司不写测试的文章。 我所在部门的测试主要依靠印度外包软件公司“点点” 不知道领导有没有比较过这个成本。我们外包赛普拉斯的e2e测试更便宜，还是反复“逐点”更划算？也听人说过前台自动化测试。后来有个领导做了重要讲话，然后就没前途了...虽然存在许多问题，但基础设施测试不容忽视。 这里，Jest被推荐用于单元测试，Cypress被推荐用于e2e测试。文件结构是在组件旁边添加另一个spec.js文件。 当然，难点不在于框架，而在于如何推广TDD。 button |-button . vue |-button . stories . js |-button . spec . jsapigraphql v . s . RESTAPI架构风格是REST风格的主流，翻译过来就是实现层的状态转换。 休息是划时代的。要知道现在方兴未艾的前台框架(react，vue)都是因为Restful api把前台和后台解耦了。 然而，REST也有缺点。 当你打开一个页面，往往会发现屏幕上所有的组件都在发送api到后台；单个浏览器最大并发请求数一般小于6，api请求太多会导致卡慢。 主要原因是REST在设计上过于碎片化:比如一个名为/user/{id}的api只能包含客户信息。在实践中，你可以返回REST无关的信息，比如Job和task，而不用遵循REST的套路，但这样一来REST语义就没有了实用价值，积累了技术债。 后来为了减少请求的数量，有人想到了所谓的Redux风——也就是增加一个叫做store的中间层，让组件不再直接发送API，由全局store来解决，可以提高API的复用性；Store还可以在前台对不同来源的api数据进行重组和剪切，这也一定程度上减少了过于碎片化的功能API。 然而，API的数量仍在不可逆转地上升。 有人提出了只请求一个api，后台直接聚合所有需要的数据，前台按需查找的想法。这是后来的graphql。 大部分初创企业没有历史包袱，前台团队能力也相对较强，所以一般会直接去找graphql。 就写单个api而言，graphql比rest麻烦多了；当然麻烦的好处是不想写太多api方法，这也符合graphql的设计初衷。 我自己实现的时候，喜欢一个graphql请求一个页面，数据不放在存储里，只传递父子组件；当然，实现需要一个扁平的DOM结构，所以UI/UX应该尽可能简单。 API DocsGraphql API一般使用apollo自己的文档系统——Playground；是强类型语言，下线高，这里就不多说了。 有很多Restful API文档，其中最经典的是Swagger。我也用过类似的产品，比如OpenAPI，annotated apidoc，国内的YApi也强烈推荐。 文档产品的功能是其次，维护是难点。 个人认为99%的API文档都会烂掉。 还是上面提到的话题，认知和成本。 编写文档几乎是一劳永逸的，不像linter工具。它需要迭代代码。只有那些执行力强，文件文化根深蒂固的企业才能落实到位。 曾经听说某领导为了提高霸气，每天做重要讲话；；但是直到他离任，API的信息还是口口相传。 这里没有讽刺这位领导人的意思。他发表了重要讲话，但他没有增加下层人员的开发成本。这是一个错误。 反正文档和测试是一样的。工具不是最重要的，执行力才是最重要的。 Mock我一直有个梦想:即使后台宕机，打开前台也能完成所有操作。 这需要模拟服务，但实际上，大多数模拟服务很快就会腐烂。 Graphql有强类型，auto-mock数据可能持续的时间长一点；不要妄想休息。API太多了，很少有人会一直跟进。 所以个人不主张在模拟服务上浪费太多时间。在开发阶段，反向代理一个特定的api就足够了。之后，如果很烂，那就很烂。不要难过。 模拟api在测试环境中意义重大。有些组件需要异步请求数据才能完全加载(但是这样的组件越少越好)。模拟api可以帮助在隔离的沙箱中进行单元测试。 这里有一个神器——Mirage JS，一个最小的模拟服务，它可以在客户端和测试用例中阻塞api并返回模拟数据。 这期的名字很大，但主要是几个常用前台工具的细节。 这些工具基本都是大众的后期产品。如果你没听说过他们，他们可能有点停产了。 感兴趣的朋友最好尽快补上。 虽然每天大家都说学不下去了，但是到了面试的时候，还是会比对方强。