4

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

主要包括四个部分:

  • 基本原则
  • 保持整洁
  • 保持扩展性
  • 抽象化
本主题仅涉及原生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澳大利亚演讲。

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

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


lucifer
5.3k 声望4.6k 粉丝