javascript写字技巧_如何优雅地书写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

// ...

}

使用自解释的命名

// 不推荐

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澳大利亚演讲。

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

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