[译] 前端编程中 10 条你需要了解的原则

原文：10 things you will eventually learn about javascript projects 翻译仅供学习

JavaScript 编程是一场冒险。在各个行业经历了近十年从业余到专业的发展之后，我相信每个人都愿意同意我的这一观点。

前端工程给了我们很多选择的自由，灵活性以及大量的创造性。但想要发挥这些特性需要我们同时具备一些专业知识（knowledge），规划（planning）和自我责任感（self-responsibility）。

一路走来我们经历 jQuery、require.js、Angulars、React、ExtJs 等等，还有很多其他的库我已不记得（或者说我选择不去回忆）——因为在今天（2018 年）的前端我已经看到了许多不可思议的事情，百家争鸣。而我们很可能已经接触过其中的某些方面。

总是存在一些通用的模式，使得一些即使不协调的项目也能获得一定的可管理性。接下来将要表述的是一份关于如何做到这点的列表，总共包含 10 条类目。这些主要来源我个人的开发经验，所以一定程度上是主观的，但我相信有经验的开发者都会认同我。这些模式能够为一个项目提供牢固的基础，适用于任一框架、方法、团队规模，并能够减少文档编写、代码重构的需求、以及开发者的眼泪（争吵）。

我希望今天你能都学到一些新的东西，并且是对你有帮助的，最后能够用上这些去创造很赞的事。💪

分而治之（Divide and conquer）

大多数人一定听过这个，但是有一些人看起来低估了这条原则。CommonJS，Webpack 和 Node 已经允许我们将代码分离、写在了多个文件，为什么我们还要来关心这一点?

一致性（Consistency）。将项目划分为一个个单导出（single-export）的文件，这使得搜索和依赖管理变得十分简单，即使是在代码库的规模持续增长的时候。为文件命名时遵循它唯一导出的内容，能让文件变得直观（intuitive），在遍历架构时这还有助于减少脑力的消耗、降低大脑负担。

管理性（Management）。将每个导出分离到各个文件，可以在必要的时候移动它的位置，还能促进解耦。当在应用程序的不同部分需要你的辅助函数时，你可以很容易地创建一个分享（Shared）目录，然后把文件拖进来，使其他部分的代码可以访问到它。

让事情变得直观、明显（Make things embarrassingly obvious）

要花时间给每一个变量、方法、文件命名，就像是给你刚出生的婴儿取名字一样用心。在今天，你可能节省了 0.3 秒来调用一个变量“x”，但是一个月以后你可能就要花两天时间来试图搞清楚它的含义，再花上四天时间去重构代码。提前思考，不要害怕太长的变量名。

避免使用高深的方式，即使这能让你考虑申请麻省理工（MIT）。你的方案也许是十分精巧而复杂的，但在未来的某一天，你和你的团队可能要话费大量时间去搞懂这段代码所做的事情。专注于把事情做得简单，甚至不需要文档和注释的说明。

处理魔幻数字和字符（Resolve magic numbers and strings）

与命名规则有点像似，不要在你的代码里使用魔幻数字和字符。不管一个值是的意义是多么小而简单，也要把它设置成一个变量、取一个有意义的名字，并把它放到当前作用域的顶端。

大多数时候，你代码中声明的变量会被其他地方重用。所以，马上把他们设置为变量，减少代码重复、增强可维护性。

消除多层嵌套（Fight nesting）

如果你的一段代码一行超多 120 字符，行数超过 500，或者你的 if 语句多余三层，那么你最好要将其分离。

你可以这样处理拥有复杂条件判断的代码，把多层嵌套的 if 语句分离到函数（functions）、Promises 或 Observables。如果你使用了大量的异步回调，async / await 能十分有效地帮助你简化代码。

解决难以配置（Configure hard）

如果你的应用使用了全局变量、API、功能开关或是一些第三方认证，应该把这些抽离到一个单独的配置文件。

有很多包能同时在 web 和 node 帮助进行配置管理，像是config。有些时候你的配置文件应该需要做到让应用在服务端运行或是本地进行开发。更早地创建配置文件比后期才进行要更好，提早开始能让你对比如环境区分、认证、功能开关等配置有机会做出调整。

框架可以提供帮助（Frameworks are there to help）

太多时候你可以看到一个框架被使用仅仅是因为有人知道它、或是框架很受欢迎。

花时间好好考虑下你的项目是否需要使用框架或是真正需要使用哪个框架。终端用户很少关心你的网站是否使用了一个在 Github 上超过 10 万星星的框架。根据经验，我将一些框架和库分开，如下：

React：当你需要完全控制架构并且使用组件去构建 web 应用时，你可以选择 React。但是在上手之前你需要话费不少时间去熟悉 React 的生态圈。当然在这之后，React 也会给予相应的回馈，如果你知道你正在做什么。
Angular / VueJS / Ember：当你需要快速构建一个可靠的 web 应用时，你可以选择这些。但作为交换，你得允许一个大的黑盒而不是一个架构。这些框架能为你做很多事情，但你得权衡这种方式带来的利弊。与 React 相比，他们的结构更加严格缺少自由，但可以让你少犯错误。
jQuery / lodash / 其他相似的库：当你需要快速开发网页并节约网页传输大小，这些库比较适合。这些能减少很多开发时间，但需要担忧的是，这些库会允许你写出难以维护的代码，所以你应该把这些作为辅助而不是基础。
Vanilla / 不适用框架：当你能花费大量时间来开发和规划，同时适用于 web 应用和网页开发。当你的项目涉及一些实验性的功能时，比如 WebGL，Workers、深度优化、浏览器动画等，纯 JavaScript 是一个不错的选择。以这种方式，最终你可能会创造出自己的框架。在转换器（transpilers）的帮助下，这可能是 jQuery 更好、更轻量级的替代。

把这一项作为建议，要经过深思熟虑决定框架的选择和使用。

为原型以外的内容编写测试（Unless it is a prototype — write tests）

单元测试、冒烟测试、端到端测试、完整性检验。除非你的项目只是一个即将被重写的原型，否则加上测试。随着复杂度的增加，代码将变得更加难以控制和维护，而测试能做到这些。

在未来的某一天，你遇到了一个 bug，抬头看着万里无云的蓝天，你会感谢过去的你自己所写的测试。因为你从未意识到究竟有多少代码在你添加新功能之后默默崩溃了。

使用版本控制（Use version control）

对于无论是原型，全面的企业 web 应用，还是一个小型的、娱乐的项目，从每一次的第一行代码开始，就使用 git 或是其他版本控制进行管理。保持日常的提交，使用分支，学习合并、解决冲突和版本回退。每次提交写上有意义的提交信息。

版本控制允许你进行时间旅行，保存破坏性改动（broken things），查看过去的改动。如果你在这篇文章中只记得一件事，那一定要是学习版本控制的基础知识并在每日的工作去使用它。为什么？因为即使你忽略了文章其他部分的内容而出错了，只要有版本控制在你就能修复。然而，如果没有它，那你注定只能从头开始。

负责地管理状态（Manage state responsibly）

为状态管理寻找一种方式或一些库，并坚持下去，就像你的生命要依赖它一样——因为，有时候，可能真的是这样。

作为前端开发者，我们经常面临两种挑战：展示数据和存储数据。随之时间的推移，后者会变得越来越难维护，因为我们太容易去忽略它了。也就是说，几个月后，你的项目将变得几乎无法维护。

数据存储（状态管理）是非常棘手的。我们的应用通常要在用户看到的数据和服务器的数据之间保持同步。我们的目标是不在中间层加入过多复杂的逻辑。组件应该使用一组相同的数据，同步用户做出的改变，同时也要反馈服务器做出的改变。该如何才能做到这样？

对于 React，有一个十分开放的生态圈，提供了大量的解决方案：基于 Flex 架构的 Redux；基于观察者模式（observable-based）的 Mobx。每一种方案都有它各自的利弊，在使用之前请一定要学习并理解这些库的基本知识。
Angular，Ember，和 VueJS 有他们内建的状态管理方案，基于 Observables。虽然不是很必要，也有一些额外的库可以使用，比如 ngRx，Akita 和 Vuex。
对于任何一种其他的框架或是 Vanilla JavaScript，你也可以使用 Redux，Mobx，或是你自己的状态管理方案。主要目标是要保证整个应用有一个相同的数据来源，保持数据的一致性。

保持质疑（Question trends）

在这最后说的是，要倾听和学习来自社区的内容，但是同时要保持思考和质疑的态度，包括你读到的每一条评论、Medium 上的长文（也许这是一只猫写的呢），最后在你的编码中有所反馈。对于新的想法要保持开放态度，因为前端的生态圈总是变化很快，但也不能为了追逐新事物而去追逐，这已经导致了不少的项目被遗忘。

用一个老的、成熟的框架写一个项目，比起另一个只是因为新鲜而使用了两个框架的项目总是更好、更稳健的。虽然趋势上来说，新的框架往往提高了一些程序的性能，但它几乎不会影响一致性。坚持你的选择以保持高的可维护性，仅仅只在必要的时候作出调整，强调一下，只在必要的时候。

完。🙂