改进你的（Web）Dev Foo

我从去年就开始写这篇文章了，但最后我犹豫着要不要把它发表出来，因为这篇文章主要只是吐槽而已。希望你们能从中有所收获，因为我分享了一些我学到的以及在实践中总结的经验，这些经验可以帮助我写出高效简洁的代码。

编辑器/IDE

如果您刚开始学习 Web 开发，那么选择任何代码编辑器并编写代码都不会错。

目前，对于 Web 开发来说，选择编辑器的选择有很多。我工作时使用 Webstorm/Xcode 组合，而我自己则使用 VS Code/Vim。根据我的经验，我建议初学者从简单的、没有太多插件的编辑器开始学习，例如 VS Code、Notepad++ 或 Sublime Text，手写输入所有关键字和语言方法对记忆/学习这些内容非常有帮助。一旦你熟悉了你正在使用的语言，就可以切换到功能齐全的 IDE，例如 Webstorm 或插件增强的 VS Code。

代码检查器和格式化程序

TLDR：使用 Eslint 和 Prettier

当您的代码库变得越来越大时，关注所有这些行也会变得更具挑战性，并且语法错误问题也会随之出现。通过突出显示有问题的代码、未声明的变量或缺少的导入，您的工作效率可以大大提高，并且可以节省大量时间和精力。

从一开始就使用Eslint对学习 JS 也大有裨益，因为它会迫使你养成良好的习惯，编写简洁的代码。多年来，我一直根据eslint-config-airbnb定制自己的 eslint 规则版本，但最近，我一直在研究Wes Bos 的 eslint 配置，可能会在未来的一些项目中尝试一下。

除了 Eslint 之外，我还使用Prettier进行代码格式化，并结合husky和​​lint-staged作为预提交钩子来自动进行 linting/格式化。

最佳目录结构

Dan Abramov 的解决方案

我对这个话题的感受很复杂。我唯一确定的是，没有绝对正确的解决方案。
每个应用程序都有其独特的特点，每个项目也有其独特的需求。我们构建应用程序的方式应该根据项目的需求而变化，就像我们选择的技术一样。

不要试图从项目一开始就优化项目结构，但请记住，由于历史重写，在项目后期更改项目结构可能会在 VCS 中出现问题。

话虽如此，不要想太多。选择一个适合你应用程序的文件夹结构。如果你花费大量时间来组织和重新组织组件、容器、样式、reducer 和 sagas，那你就做错了。

文件命名

咆哮来袭

关于文件命名，我发现一条非常有用的规则是：将文件命名为与要从该文件导出的内容相同的名称。当我在一个结构混乱的项目中拥有数百个 index.js 文件时，我感到多么愤怒，而查找某个逻辑块却要花费大量时间，感觉很浪费……

有些人乐意这样工作，这让我很惊讶。

即使你的 IDE 很聪明，会将目录信息添加到非唯一文件名的 tab 名称中，你仍然会面临大量的冗余，很快 tab 空间就会用完，而且你仍然无法直接输入文件名来打开它。话虽如此，我理解这背后的原因——这确实是一种权衡。更短的 import 语句 vs. 匹配 export 的文件名。

在我看来，这不是一个值得的权衡。

就我而言，在过去的两三年里，我主要使用 CRA 的项目结构，并做了一些修改，例如为状态管理逻辑添加redux/或sagas/目录并将所有jsx/tsx文件移动到components/。

调试

只要console.log您认为有代码“异味”的地方即可。

关于调试的文章可以单独写一篇文章，但是关于 Js 调试已经有很多优秀的文章和课程，所以我就长话短说吧。

许多开发者会说使用调试器看起来更专业，但console.log我最常用的快速调试工具是它。我最近在开发智能电视和流媒体设备的应用，这些应用对调试器不太友好，所以telnet有时只能在控制台中记录数据或查看设备日志来调试。除此之外，你应该学习如何使用调试器，因为它可以帮你避免更复杂的 bug。

最简单的调试方法，至少就工具而言，是阅读你写的代码。之后，使用console.logs，如果这样仍然无法找出问题所在，那就切换到调试器，祝你好运。

文档

不要为了写注释而写注释。只在需要解释的地方写注释。

我们都（希望如此）知道，完善的文档和参考资料对于一个成功的软件项目至关重要。如果没有好的文档，一个特定的库可能几乎无法使用。如果没有关于不同组件和方法如何独立工作的参考资料，更不用说项目各个部分如何相互配合的示例，我们只能通过阅读源代码来理解作者的初衷，或者如果幸运的话，去 StackOverflow 上搜索一些随机的错误信息。如果这是一个内部项目或小型项目，你可能完全搞砸了（我经历过这种情况）。

如果你和其他几位开发人员一起在项目中工作，这一点尤其重要；想想团队中的其他成员会怎么看待你写的 hack，因为他根本不知道为什么需要 hack。如果你一直不知道代码的工作原理以及为什么会有这么多 hack，或者故意把代码弄得比实际需要的更复杂，你只会让同一个项目上所有同事的工作更加困难。如果你这样做的唯一目的是为了确保自己的工作安全，那你就只是一个censored……

为了记录我的项目，我一直使用JSDoc语法。JSDoc 是一种在代码中编写注释的标准化方法，用于描述代码库中的函数、类、方法和变量。其理念是，我们用一些特殊的关键字和格式约定来描述代码的工作原理，之后我们可以使用解析器运行所有注释代码，并根据我们编写的注释生成美观易读的文档。

下面是一个简短的例子，展示其实际效果：

/**
 * @desc Represents a book.
 * @param {string} title - The title of the book.
 * @param {string} author - The author of the book.
 */
function Book(title, author) {
}

其中一些东西可以用 Typescript 类型替换，但即使如此，对于更复杂的功能，如果我们能很好地解释它在做什么以及为什么我们需要它这样做，那将会很有帮助。

此外，代码中的每个黑客行为都应该记录下来，相信我，将来你会感谢你的。

最后，如果你还没读过，请阅读Robert C. Martin 的《代码整洁之道》。编写干净易读的代码本身就是一门技能。

学习 Javascript

但说真的

由于不熟悉核心语言而使用 Js 框架或库来解决遇到的问题，很快就会给您带来麻烦。但不要绝望，我们大多数人都在某种程度上有过这种经历，Js 文档非常庞大，除非您记忆力超群，否则根本不可能记住其中的四分之一。但利用帕累托原则（也称为 80/20 规则）在很多情况下就足够了。了解它的this工作原理、可以对对象和数组执行的所有可能操作、在 Js 中一切都是对象、作用域规则、异步操作、原型（您很少会使用这些，但了解 Js 中的继承如何工作至关重要）和强制场景（这样您就可以嘲笑人们犯愚蠢的错误，他们将数字添加到字符串或将数组添加到数组，然后在 Reddit 上创建帖子抨击 Js）。

有一点是肯定的：如果你精通 JavaScript，那么所有基于 JavaScript 的框架和工具都会更容易学习。说到底，这些都只是 JavaScript 的底层原理。

如果你想深入了解 Js 的核心机制，我还推荐你阅读《你不懂 JS 》系列丛书。（我已经重读了第二遍了）。

使用最新标准

与时俱进

紧跟 Web 开发领域的所有动态并非易事，尤其是在 JavaScript 语言本身在过去几年中发生了巨大变化的情况下。2015 年，负责起草 ECMAScript 规范的委员会 TC39 决定采用每年制定新标准的模式，即新功能在获得批准后添加，而不是像以前那样制定完整的计划规范，等所有功能都准备就绪后再最终确定。因此，我们有了 ES6 - ES10 规范，它们极大地改进了 JavaScript 语言。每个规范都集成了一组 JavaScript 中的新功能/改进，从而无需繁琐的库或工具，让您可以更轻松地使用 JavaScript。

如果您想快速了解未来版本中正在考虑的功能，最好的去处是Github 上的 TC39 提案仓库。提案要经历四个阶段，其中第一阶段可以理解为一个很酷的“想法”，而第四阶段则“已确认将在下一个 ECMAScript 版本中实现”。ES10中有很多很酷的功能:)

如果你有兴趣了解新提案，但又想有人指导你，我推荐你订阅 Axel Rauschmayer 的2ality博客。但如果你更喜欢社交互动，那么跟上语言发展最简单的方法或许就是关注那些正在塑造和教授新语言特性的人：@TC39、Sebastian Markbåge、Mathias Bynens、Daniel Ehrenberg、Tierney Cyren、Axel Rauschmayer，以及可能还有很多我忘记的人。

Babel 几乎实现了 TC39 列表中所有处于较高阶段的提案，您可以在Babel REPL中尝试这些提案，或者创建一个安装相应插件并加载到 Babel 中的小型项目。此外，如果您还不熟悉 ES6，Babel对其最重要的功能进行了出色的总结。

打字稿

类型好，样板代码不好

JavaScript 是一种弱类型语言，也称为动态类型语言，这意味着它非常灵活，并且在运行时而不是编译时进行类型检查。这意味着您可以创建一个变量，一开始是字符串类型，但然后将其更改为数字类型等等。
对于许多刚开始使用 C 或 Java 编程的人来说，这是令人恐惧的（因此 Reddit 上出现了强制类型转换的梗），因为这些语言对类型的要求非常严格，并且需要对常量进行完整的数据类型或接口定义。无论如何，静态类型有很多优点：静态类型有助于帮助记录函数、阐明用法并减少认知开销。但在我看来，动态类型也有很多优点。

于是，Typescript 应运而生。Typescript 是 Javascript，但增加了一层，为 Javascript 代码添加了静态类型工具和功能。在开发应用程序时，您将编写 Typescript 代码，然后将其编译为纯 JavaScript，以供浏览器理解。它可以修复动态类型语言存在的一些问题，如果您使用 TS 支持的编辑器（VS Code、Atom、Webstorm），这将是一个很大的优势，它可以提供出色的开发体验并提高您的工作效率。除此之外，我讨厌 TS 附带的样板代码。我参与过的几个 TS 项目的代码行数至少增加了 30-40%，这仅仅是因为 TS 类型、接口和枚举。有时错误可能很难理解，调试类型问题很快就会让人抓狂。合并类型和一些高级类型定义有时读起来和理解起来很累。

如果你想了解更多，可以阅读 Eric Elliott 撰写的一篇关于 TypeScript 优缺点的优秀文章。不过，我对 TypeScript 的总体评价还是积极的，因为每当我回过头去阅读代码时，我都能（几乎总是！）立即且透彻地理解每个变量的类型、函数的返回值、数组在整个程序过程中是否被更改等等。这节省了大量时间，并最大限度地减少了检查数据类型和结构的冗余操作。

代码测试、集成和交付

给开发人员一个繁琐的任务，他们会找到一种方法来实现自动化

在座的各位可能大多数人都熟悉 Webpack、Gulp、Grunt、lint-staged 等工具。甚至 Prettier 和 Eslint 也是一种自动化工具。我们花在琐碎或重复任务上的时间越少，就越有时间专注于实际问题。

很少有开发人员会对为自己的代码编写测试感到兴奋。尤其是在面临尽快完成新功能的压力时，编写对项目进度没有直接贡献的测试代码可能会令人烦恼。当项目规模较小，您可以手动测试一些可用功能时，这样做可能还好，但一旦项目开始发展壮大，手动测试就会变得非常耗时且效率低下。

提前投入测试是项目最明智的投资之一。它能让你写完一个功能后，几周内都无需动手，等到回来看到它通过了所有测试，你就能对一切顺利充满信心。

我的测试主要用Jest ，不过我也听说Riteway不错。自从引入 hooks 之后，测试 React 组件变得越来越难，Enzyme 也遇到了麻烦，所以我不确定现在还能不能推荐它了。目前来说，react-testing-library或许是更好的选择。

持续集成是一种软件开发实践，将变更频繁地集成到共享代码库中。每次集成都应进行自动格式化和测试。这为开发人员提供了快速的反馈周期，以确定提交中的潜在冲突，同时还允许频繁地将新的更新合并到应用程序中。

持续交付与持续集成 (CI) 协同工作，将 CI 流程生成的经过测试和构建的应用程序部署（或交付）到​​目标基础架构。借助持续交付 (CD)，团队可以每天甚至每小时将新代码推送到生产环境，并快速获得用户关注点的反馈。

关于如何编写测试以及如何配置 CI/CD 流水线，有很多内容可以讲，但这些内容本身就足够写一篇完整的文章了。编写完美的测试并没有黄金法则，但确保至少编写测试，并尝试通过单元测试、集成测试和端到端测试的组合，达到约 80% 的覆盖率，应该能够写出干净可靠的代码。

概括

我总是写不完总结（前言也一样）。对我来说，写一篇文章通常很难开始，但写完之后，我就可以一直写下去，就像决定如何结束一样😄 我仍然觉得我还没有写够所有提到的主题，所以如果你有任何问题，请随时留言。

请记住，这篇文章一半是我自己在和 Js 共事几年后发表的吐槽，一半是我自己的评论。网上有很多评论，总结起来就是“我不同意，这让我很生气，我投了反对票”，这很可惜，因为当两个理性的人意见相左时，往往会发生一些有趣的事情。

感谢阅读！

照片由Adi Goldstein在Unsplash上拍摄