如何优雅地书写JavaScript

这篇文章包含了几乎所有关于提高代码质量的内容，尤其是在构建大型应用程序时。

主要包括四个部分:

• 基本原则
• 保持整洁
• 保持扩展性
• 抽象化

本主题仅涉及原生js，关于框架（比如react和vue）的内容会在以后的文章中展现。

基本原则

我想你们大多数人之前都听说过SOLID，也就是面向对象设计里的SOLID原则。

这些原则基于面向对象设计，所以可能不适合其他编程范式。即便如此，它也涵盖了大多数情况。

例如，SOD既可以应用于面向对象编程，也可以应用于函数式编程。

单一责任原则（SRP）

开放封闭原则（OCP）

里氏替换原则（LSP）

接口分离原则（ISP）

依赖倒置原则（DIP）

保持整洁

变量

变量或许是在开发过程中最常见的术语。

命名

• 使用语义明确的命名

// 不推荐
// 我不知道这个变量代表什么意义
const flag = true;

// 推荐
const downloaded = true;
const enabled = true;

• 使用可读的命名

// 不推荐
// 也是没有意义
const yyyyMMdd;

// 推荐
const today;

• 使用语义一致的词汇

// 不推荐

// file1
function getUserData()
// file2
function fetchUserData()
// file3
function getUserRecord()
// file4
function getUserInfo()

// 推荐

// file1
function getUserInfo()
// file2
function getUserInfo()
// file3
function getUserInfo()
// file4
function getUserInfo()

• 使用可搜索的命名

// 不推荐
for(let i=0;i<5;i++) {
 // ...
}

// 推荐
const COUNT = 5;
for(let i=0;i<COUNT;i++) {
 // ...
}

• 使用自解释的命名

// 不推荐
if (!group) {
  return pictureCollect.list;
}
return getListByGroup(group, pictureCollect.list);

// 推荐
const getAllList = list => list;
// const getAllList = R.identity(list)
if (!group) {
  return getAllList(pictureCollect.list);
}
return getListByGroup(group, pictureCollect.list);

• 避免冗余的命名

// 不推荐
const phone = {
 phoneOwner: 'lucifer',
 phoneSize: ''
}

// 推荐
const phone = {
 owner: 'lucifer',
 size: ''
}

• 好代码，不撒谎

程序从不说谎，但注释（也包括名称）可能会。

类型

• 推荐使用 const

控制流

• 使用promise方法而不是callback（回调函数）

异步/等待也是非常强大的。

分支

• 使用短路表达式或默认值

// 不推荐
function downloadFile({_filename, _encoding}) {
   let filename = 'untitled.txt';
   let encoding = 'utf-8'
   if (filename) {
    filename = _filename;
   }
   if (encoding) {
    encoding = _encoding;
   }
   // ....
}

// 推荐
function downloadFile({filename = 'untitled.txt', _encoding}) {
   const encoding = _encoding || 'utf-8';
   // ....
}

• 使用策略或多态性（开放封闭原则）
• 使用责任链（开放封闭原则）
• 将其分解成不同的功能（单一责任原则）
• 封装条件

// 不推荐
if (number === 0 && (1 / number) === -Infinity)
// 推荐
function isNegativeZero(number) {
   return number === 0 && (1 / number) === -Infinity
}

if (isNegativeZero(number))

• 避免不必要的条件

表达

• 使用迭代器而不是循环

在特定环境下递归表现的更好。

函数

参数尽量要少

使用纯函数

相比于命令式，函数式更好

小心在全局作用域中的函数（包括在他们原型对象上的方法）

one level of abstraction

只做一件事情（单一责任原则）

write less

调用者和被调用者位置应该尽量接近

报错

• 永远不要对报错不做处理

// 不推荐
const logger = console.log.bind(console)
fetch('http://www.test.com')
 .then(notifyUser)
 .catch(logger)
 
// 推荐

fetch('http://www.test.com')
 .then(notifyUser)
 .catch(err => {
  // 你可以全做，也可以选一个
  console.error(err)
  notifyUser(err)
  sendErrToServer(err)
 })

打印、存储、通知用户或将其发送到远程服务器

测试

• 一步一测试

格式

• 美观
• 一致

注释

• 注释让人难以理解的关键部分
• 删除注释代码
• 注释必要的信息

create, ltime etc

• 避免绘图注释
• 根据代码意义注释，不要说谎
• 注释应与相关代码位置一致
• 相比于注释，一个语义明确的命名更好

// 不推荐
// means the date of the today
const yyyyMMdd;

// 推荐
const today;

保持扩展性

增强

好莱坞原则

我一直很欣赏好莱坞原则这个名称的巧妙。这个原则的本质是“不要给我打电话，我会打给你”。如你所知，这是你在面试好莱坞电影里的一个角色后可能听到的答复。而软件世界里的好莱坞原则也是一样的观念。其目的是注意要聪明的构造和实现你的依赖关系。

例如:

import a from '../../a.js'
import b from '../../../b.js'
import a from '../c.js'

function app() {
   return {
    start() {
     a.start();
     b.start();
     c.start();
     console.log('app stared~')
    }
   }
}

我们编写的代码直接依赖于a、b和c。当它们中的任何一个改变它的api或位置时，你必须跟着变动代码。

var { decorator } = require("./decorator.public.js");

function app({a, b, c}) {
   return {
    start() {
     console.log('app stared~')
    }
   }
}

// enhance
// = IOC + decorator
decorator(app);

if we use enhance, which implemented by IoC and decorator.
如果我们使用通过Ioc和装饰器实现的增强技术，
可以使得应用程序易于测试和扩展。.

装饰器可能就像这样：

// 为了简单的目的
import a from '../../a.js'
import b from '../../../b.js'
import a from '../c.js'

function decorator(app) {
 return app({a, b, c})
}

这很简单，但完全不同。

• app的参数道出了真相
• 从依赖项中解耦

而且我们可以改变app的行为.

function a() {console.log('a')}
var _a = a;
a = function() {
 _a();
 console.log('hello decorator')
}
a();
// a
// hello decorator

更优雅的方式：

function a() {console.log('a')}
function dec() {onsole.log('hello decorator')}

compose(dec, a)

抽象化

软件开发的关键是找出变量和变量。

然后对不变部分进行编程，使变量的影响在它的控制之下。

也称为抽象编程.

对比传统的面向对象编程（OOP）来说,函数式编程（FP）更优越。
借助“无数据样式”（即“pointfree”）的帮助，您可以将细节与逻辑分离开来。
所以你可以单独留下细节，让逻辑变得纯粹。

我想再强调一点，那就是人们有时会说，没有抽象概念总比错误的抽象好。这实际上意味着错误抽象的代价非常高，所以要小心。我认为这有时会被误解。这并不意味着您应该没有抽象概念。 这只意味着你必须非常小心。 -- Malte Ubl在JSConf澳大利亚演讲。

我们必须善于发现正确的抽象。

只有这样，您才能编写可重用的、可管理的和可扩展的代码。