优质代码书写技巧

_Henry
228 阅读13分钟

优质代码书写技巧

变量

不添加不必要的上下文

如果你的类名/对象名有意义， 不要在变量名上再重复。

不好的：

const Car = {
  carMake: 'Honda',
  carModel: 'Accord',
  carColor: 'Blue'
};
​
function paintCar(car) {
  car.carColor = 'Red';
}

好的：

const Car = {
  make: 'Honda',
  model: 'Accord',
  color: 'Blue'
};
​
function paintCar(car) {
  car.color = 'Red';
}

函数

函数参数 (两个以下最理想)

限制函数参数的个数是非常重要的， 因为这样将使你的函数容易进行测试。 一旦超过三个参数将会导致组 合爆炸， 因为你不得不编写大量针对每个参数的测试用例。

没有参数是最理想的， 一个或者两个参数也是可以的， 三个参数应该避免， 超过三个应该被重构。 通常， 如果你有一个超过两个函数的参数， 那就意味着你的函数尝试做太多的事情。 如果不是， 多数情况下一个 更高级对象可能会满足需求。

由于 JavaScript 允许我们不定义类型/模板就可以创建对象， 当你发现你自己需要大量的参数时， 你 可以使用一个对象。

不好的：

function createMenu(title, body, buttonText, cancellable) {
  // ...
}

好的：

const menuConfig = {
  title: 'Foo',
  body: 'Bar',
  buttonText: 'Baz',
  cancellable: true
};
​
function createMenu(config) {
  // ...
}

移除冗余代码

竭尽你的全力去避免冗余代码。 冗余代码是不好的， 因为它意味着当你需要修改一些逻辑时会有多个地方 需要修改。

想象一下你在经营一家餐馆， 你需要记录所有的库存西红柿， 洋葱， 大蒜， 各种香料等等。 如果你有多 个记录列表， 当你用西红柿做一道菜时你得更新多个列表。 如果你只有一个列表， 就只有一个地方需要更 新！

你有冗余代码通常是因为你有两个或多个稍微不同的东西， 它们共享大部分， 但是它们的不同之处迫使你使 用两个或更多独立的函数来处理大部分相同的东西。 移除冗余代码意味着创建一个可以处理这些不同之处的 抽象的函数/模块/类。

让这个抽象正确是关键的， 这是为什么要你遵循 Classes 那一章的 SOLID 的原因。 不好的抽象比冗 余代码更差， 所以要谨慎行事。 既然已经这么说了， 如果你能够做出一个好的抽象， 才去做。 不要重复 你自己， 否则你会发现当你要修改一个东西时时刻需要修改多个地方。

不好的：

function showDeveloperList(developers) {
  developers.forEach((developer) => {
    const expectedSalary = developer.calculateExpectedSalary();
    const experience = developer.getExperience();
    const githubLink = developer.getGithubLink();
    const data = {
      expectedSalary,
      experience,
      githubLink
    };
​
    render(data);
  });
}
​
function showManagerList(managers) {
  managers.forEach((manager) => {
    const expectedSalary = manager.calculateExpectedSalary();
    const experience = manager.getExperience();
    const portfolio = manager.getMBAProjects();
    const data = {
      expectedSalary,
      experience,
      portfolio
    };
​
    render(data);
  });
}

好的：

function showList(employees) {
  employees.forEach((employee) => {
    const expectedSalary = employee.calculateExpectedSalary();
    const experience = employee.getExperience();
​
    let portfolio = employee.getGithubLink();
​
    if (employee.type === 'manager') {
      portfolio = employee.getMBAProjects();
    }
​
    const data = {
      expectedSalary,
      experience,
      portfolio
    };
​
    render(data);
  });
}

不要使用标记位做为函数参数

标记位是告诉你的用户这个函数做了不只一件事情。 函数应该只做一件事情。 如果你的函数因为一个布尔值 出现不同的代码路径， 请拆分它们。

不好的：

function createFile(name, temp) {
  if (temp) {
    fs.create(`./temp/${name}`);
  } else {
    fs.create(name);
  }
}

好的：

function createFile(name) {
  fs.create(name);
}
​
function createTempFile(name) {
  createFile(`./temp/${name}`);
}

避免副作用

如果一个函数做了除接受一个值然后返回一个值或多个值之外的任何事情， 它将会产生副作用， 它可能是 写入一个文件， 修改一个全局变量， 或者意外的把你所有的钱连接到一个陌生人那里。

现在在你的程序中确实偶尔需要副作用， 就像上面的代码， 你也许需要写入到一个文件， 你需要做的是集 中化你要做的事情， 不要让多个函数或者类写入一个特定的文件， 用一个服务来实现它， 一个并且只有一 个。

重点是避免这些常见的易犯的错误， 比如在对象之间共享状态而不使用任何结构， 使用任何地方都可以写入 的可变的数据类型， 没有集中化导致副作用。 如果你能做到这些， 那么你将会比其它的码农大军更加幸福。

不好的：

// Global variable referenced by following function.
// 全局变量被下面的函数引用
// If we had another function that used this name, now it'd be an array and it
// could break it.
// 如果我们有另一个函数使用这个 name ， 现在它应该是一个数组， 这可能会出现错误。
let name = 'Ryan McDermott';
​
function splitIntoFirstAndLastName() {
  name = name.split(' ');
}
​
splitIntoFirstAndLastName();
​
console.log(name); // ['Ryan', 'McDermott'];

好的：

function splitIntoFirstAndLastName(name) {
  return name.split(' ');
}
​
const name = 'Ryan McDermott';
const newName = splitIntoFirstAndLastName(name);
​
console.log(name); // 'Ryan McDermott';
console.log(newName); // ['Ryan', 'McDermott'];

不要写入全局函数

污染全局在 JavaScript 中是一个不好的做法， 因为你可能会和另外一个类库冲突， 你的 API 的用户 可能不够聪明， 直到他们得到在生产环境得到一个异常。 让我们来考虑这样一个例子： 假设你要扩展 JavaScript 的 原生 Array ， 添加一个可以显示两个数组的不同之处的 diff 方法， 你可以在 Array.prototype 中写一个新的方法， 但是它可能会和尝试做相同事情的其它类库发生冲突。 如果有 另外一个类库仅仅使用 diff 方法来查找数组的第一个元素和最后一个元素之间的不同之处呢？ 这就是 为什么使用 ES2015/ES6 的类是一个更好的做法的原因， 只要简单的扩展全局的 Array 即可。

不好的：

Array.prototype.diff = function diff(comparisonArray) {
  const hash = new Set(comparisonArray);
  return this.filter(elem => !hash.has(elem));
};

好的：

class SuperArray extends Array {
  diff(comparisonArray) {
    const hash = new Set(comparisonArray);
    return this.filter(elem => !hash.has(elem));
  }
}

函数式编程优于指令式编程

JavaScript 不是 Haskell 那种方式的函数式语言， 但是它有它的函数式风格。 函数式语言更加简洁 并且更容易进行测试， 当你可以使用函数式编程风格时请尽情使用。

不好的：

const programmerOutput = [
  {
    name: 'Uncle Bobby',
    linesOfCode: 500
  }, {
    name: 'Suzie Q',
    linesOfCode: 1500
  }, {
    name: 'Jimmy Gosling',
    linesOfCode: 150
  }, {
    name: 'Gracie Hopper',
    linesOfCode: 1000
  }
];
​
let totalOutput = 0;
​
for (let i = 0; i < programmerOutput.length; i++) {
  totalOutput += programmerOutput[i].linesOfCode;
}

好的：

const programmerOutput = [
  {
    name: 'Uncle Bobby',
    linesOfCode: 500
  }, {
    name: 'Suzie Q',
    linesOfCode: 1500
  }, {
    name: 'Jimmy Gosling',
    linesOfCode: 150
  }, {
    name: 'Gracie Hopper',
    linesOfCode: 1000
  }
];
​
const totalOutput = programmerOutput
  .map((programmer) => programmer.linesOfCode)
  .reduce((acc, linesOfCode) => acc + linesOfCode, 0);

避免条件语句

这看起来似乎是一个不可能的任务。 第一次听到这个时， 多数人会说： “没有 if 语句还能期望我干 啥呢”， 答案是多数情况下你可以使用多态来完成同样的任务。 第二个问题通常是 “好了， 那么做很棒， 但是我为什么想要那样做呢”， 答案是我们学到的上一条代码整洁之道的理念： 一个函数应当只做一件事情。 当你有使用 if 语句的类/函数是， 你在告诉你的用户你的函数做了不止一件事情。 记住： 只做一件 事情。

不好的：

class Airplane {
  // ...
  getCruisingAltitude() {
    switch (this.type) {
      case '777':
        return this.getMaxAltitude() - this.getPassengerCount();
      case 'Air Force One':
        return this.getMaxAltitude();
      case 'Cessna':
        return this.getMaxAltitude() - this.getFuelExpenditure();
    }
  }
}

好的：

class Airplane {
  // ...
}
​
class Boeing777 extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getPassengerCount();
  }
}
​
class AirForceOne extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude();
  }
}
​
class Cessna extends Airplane {
  // ...
  getCruisingAltitude() {
    return this.getMaxAltitude() - this.getFuelExpenditure();
  }
}

对象和数据结构

使用 getters 和 setters

JavaScript 没有接口或类型， 所以坚持这个模式是非常困难的， 因为我们没有 public 和 private 关键字。 正因为如此， 使用 getters 和 setters 来访问对象上的数据比简单的在一个对象上查找属性 要好得多。 “为什么？” 你可能会问， 好吧， 原因请看下面的列表：

  • 当你想在获取一个对象属性的背后做更多的事情时， 你不需要在代码库中查找和修改每一处访问；
  • 使用 set 可以让添加验证变得容易；
  • 封装内部实现；
  • 使用 getting 和 setting 时， 容易添加日志和错误处理；
  • 继承这个类， 你可以重写默认功能；
  • 你可以延迟加载对象的属性， 比如说从服务器获取。

不好的：

class BankAccount {
  constructor() {
    this.balance = 1000;
  }
}
​
const bankAccount = new BankAccount();
​
// Buy shoes...
bankAccount.balance -= 100;

好的：

class BankAccount {
  constructor(balance = 1000) {
    this._balance = balance;
  }
​
  // It doesn't have to be prefixed with `get` or `set` to be a getter/setter
  set balance(amount) {
    if (verifyIfAmountCanBeSetted(amount)) {
      this._balance = amount;
    }
  }
​
  get balance() {
    return this._balance;
  }
​
  verifyIfAmountCanBeSetted(val) {
    // ...
  }
}
​
const bankAccount = new BankAccount();
​
// Buy shoes...
bankAccount.balance -= shoesPrice;
​
// Get balance
let balance = bankAccount.balance;

类

使用方法链

这个模式在 JavaScript 中是非常有用的， 并且你可以在许多类库比如 jQuery 和 Lodash 中见到。 它使你的代码变得富有表现力， 并减少啰嗦。 因为这个原因， 我说， 使用方法链然后再看看你的代码 会变得多么简洁。 在你的类／方法中， 简单的在每个方法的最后返回 this ， 然后你就能把这个类的 其它方法链在一起。

不好的：

class Car {
  constructor() {
    this.make = 'Honda';
    this.model = 'Accord';
    this.color = 'white';
  }
​
  setMake(make) {
    this.make = make;
  }
​
  setModel(model) {
    this.model = model;
  }
​
  setColor(color) {
    this.color = color;
  }
​
  save() {
    console.log(this.make, this.model, this.color);
  }
}
​
const car = new Car();
car.setColor('pink');
car.setMake('Ford');
car.setModel('F-150');
car.save();

好的：

class Car {
  constructor() {
    this.make = 'Honda';
    this.model = 'Accord';
    this.color = 'white';
  }
​
  setMake(make) {
    this.make = make;
    // NOTE: Returning this for chaining
    return this;
  }
​
  setModel(model) {
    this.model = model;
    // NOTE: Returning this for chaining
    return this;
  }
​
  setColor(color) {
    this.color = color;
    // NOTE: Returning this for chaining
    return this;
  }
​
  save() {
    console.log(this.make, this.model, this.color);
    // NOTE: Returning this for chaining
    return this;
  }
}
​
const car = new Car()
  .setColor('pink')
  .setMake('Ford')
  .setModel('F-150')
  .save();

SOLID

单一职责原则 (SRP)

正如代码整洁之道所述， “永远不要有超过一个理由来修改一个类”。 给一个类塞满许多功能， 就像你在航 班上只能带一个行李箱一样， 这样做的问题你的类不会有理想的内聚性， 将会有太多的理由来对它进行修改。 最小化需要修改一个类的次数时很重要的， 因为如果一个类拥有太多的功能， 一旦你修改它的一小部分， 将会很难弄清楚会对代码库中的其它模块造成什么影响。

不好的：

class UserSettings {
  constructor(user) {
    this.user = user;
  }
​
  changeSettings(settings) {
    if (this.verifyCredentials()) {
      // ...
    }
  }
​
  verifyCredentials() {
    // ...
  }
}

好的：

class UserAuth {
  constructor(user) {
    this.user = user;
  }
​
  verifyCredentials() {
    // ...
  }
}
​
​
class UserSettings {
  constructor(user) {
    this.user = user;
    this.auth = new UserAuth(user);
  }
​
  changeSettings(settings) {
    if (this.auth.verifyCredentials()) {
      // ...
    }
  }
}

开闭原则 (OCP)

Bertrand Meyer 说过， “软件实体 (类， 模块， 函数等) 应该为扩展开放， 但是为修改关闭。” 这 是什么意思呢？ 这个原则基本上说明了你应该允许用户添加功能而不必修改现有的代码。

不好的：

class AjaxAdapter extends Adapter {
  constructor() {
    super();
    this.name = 'ajaxAdapter';
  }
}
​
class NodeAdapter extends Adapter {
  constructor() {
    super();
    this.name = 'nodeAdapter';
  }
}
​
class HttpRequester {
  constructor(adapter) {
    this.adapter = adapter;
  }
​
  fetch(url) {
    if (this.adapter.name === 'ajaxAdapter') {
      return makeAjaxCall(url).then((response) => {
        // transform response and return
      });
    } else if (this.adapter.name === 'httpNodeAdapter') {
      return makeHttpCall(url).then((response) => {
        // transform response and return
      });
    }
  }
}
​
function makeAjaxCall(url) {
  // request and return promise
}
​
function makeHttpCall(url) {
  // request and return promise
}

好的：

class AjaxAdapter extends Adapter {
  constructor() {
    super();
    this.name = 'ajaxAdapter';
  }
​
  request(url) {
    // request and return promise
  }
}
​
class NodeAdapter extends Adapter {
  constructor() {
    super();
    this.name = 'nodeAdapter';
  }
​
  request(url) {
    // request and return promise
  }
}
​
class HttpRequester {
  constructor(adapter) {
    this.adapter = adapter;
  }
​
  fetch(url) {
    return this.adapter.request(url).then((response) => {
      // transform response and return
    });
  }
}

里氏代换原则 (LSP)

这是针对一个非常简单的里面的一个恐怖意图， 它的正式定义是： “如果 S 是 T 的一个子类型， 那么类 型为 T 的对象可以被类型为 S 的对象替换（例如， 类型为 S 的对象可作为类型为 T 的替代品）而不需 要修改目标程序的期望性质 （正确性、 任务执行性等）。” 这甚至是个恐怖的定义。

最好的解释是， 如果你有一个基类和一个子类， 那个基类和字类可以互换而不会产生不正确的结果。 这可 能还有有些疑惑， 让我们来看一下这个经典的正方形与矩形的例子。 从数学上说， 一个正方形是一个矩形， 但是你用 "is-a" 的关系用继承来实现， 你将很快遇到麻烦。

不好的：

class Rectangle {
  constructor() {
    this.width = 0;
    this.height = 0;
  }
​
  setColor(color) {
    // ...
  }
​
  render(area) {
    // ...
  }
​
  setWidth(width) {
    this.width = width;
  }
​
  setHeight(height) {
    this.height = height;
  }
​
  getArea() {
    return this.width * this.height;
  }
}
​
class Square extends Rectangle {
  setWidth(width) {
    this.width = width;
    this.height = width;
  }
​
  setHeight(height) {
    this.width = height;
    this.height = height;
  }
}
​
function renderLargeRectangles(rectangles) {
  rectangles.forEach((rectangle) => {
    rectangle.setWidth(4);
    rectangle.setHeight(5);
    const area = rectangle.getArea(); // BAD: Will return 25 for Square. Should be 20.
    rectangle.render(area);
  });
}
​
const rectangles = [new Rectangle(), new Rectangle(), new Square()];
renderLargeRectangles(rectangles);

好的：

class Shape {
  setColor(color) {
    // ...
  }
​
  render(area) {
    // ...
  }
}
​
class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }
​
  getArea() {
    return this.width * this.height;
  }
}
​
class Square extends Shape {
  constructor(length) {
    super();
    this.length = length;
  }
​
  getArea() {
    return this.length * this.length;
  }
}
​
function renderLargeShapes(shapes) {
  shapes.forEach((shape) => {
    const area = shape.getArea();
    shape.render(area);
  });
}
​
const shapes = [new Rectangle(4, 5), new Rectangle(4, 5), new Square(5)];
renderLargeShapes(shapes);

接口隔离原则 (ISP)

JavaScript 没有接口， 所以这个原则不像其它语言那么严格。 不过， 对于 JavaScript 这种缺少类 型的语言来说， 它依然是重要并且有意义的。

接口隔离原则说的是 “客户端不应该强制依赖他们不需要的接口。” 在 JavaScript 这种弱类型语言中， 接口是隐式的契约。

在 JavaScript 中能比较好的说明这个原则的是一个类需要一个巨大的配置对象。 不需要客户端去设置大 量的选项是有益的， 因为多数情况下他们不需要全部的设置。 让它们变成可选的有助于防止出现一个“胖接 口”。

不好的：

class DOMTraverser {
  constructor(settings) {
    this.settings = settings;
    this.setup();
  }
​
  setup() {
    this.rootNode = this.settings.rootNode;
    this.animationModule.setup();
  }
​
  traverse() {
    // ...
  }
}
​
const $ = new DOMTraverser({
  rootNode: document.getElementsByTagName('body'),
  animationModule() {} // Most of the time, we won't need to animate when traversing.
  // ...
});

好的：

class DOMTraverser {
  constructor(settings) {
    this.settings = settings;
    this.options = settings.options;
    this.setup();
  }
​
  setup() {
    this.rootNode = this.settings.rootNode;
    this.setupOptions();
  }
​
  setupOptions() {
    if (this.options.animationModule) {
      // ...
    }
  }
​
  traverse() {
    // ...
  }
}
​
const $ = new DOMTraverser({
  rootNode: document.getElementsByTagName('body'),
  options: {
    animationModule() {}
  }
});

依赖反转原则 (DIP)

这个原则阐述了两个重要的事情：

  1. 高级模块不应该依赖于低级模块， 两者都应该依赖与抽象；
  2. 抽象不应当依赖于具体实现， 具体实现应当依赖于抽象。

这个一开始会很难理解， 但是如果你使用过 Angular.js ， 你应该已经看到过通过依赖注入来实现的这 个原则， 虽然他们不是相同的概念， 依赖反转原则让高级模块远离低级模块的细节和创建， 可以通过 DI 来实现。 这样做的巨大益处是降低模块间的耦合。 耦合是一个非常糟糕的开发模式， 因为会导致代码难于 重构。

如上所述， JavaScript 没有接口， 所以被依赖的抽象是隐式契约。 也就是说， 一个对象/类的方法和 属性直接暴露给另外一个对象/类。 在下面的例子中， 任何一个 Request 模块的隐式契约 InventoryTracker 将有一个 requestItems 方法。

不好的：

class InventoryRequester {
  constructor() {
    this.REQ_METHODS = ['HTTP'];
  }
​
  requestItem(item) {
    // ...
  }
}
​
class InventoryTracker {
  constructor(items) {
    this.items = items;
​
    // 不好的： 我们已经创建了一个对请求的具体实现的依赖， 我们只有一个 requestItems 方法依
    // 赖一个请求方法 'request'
    this.requester = new InventoryRequester();
  }
​
  requestItems() {
    this.items.forEach((item) => {
      this.requester.requestItem(item);
    });
  }
}
​
const inventoryTracker = new InventoryTracker(['apples', 'bananas']);
inventoryTracker.requestItems();

好的：

class InventoryTracker {
  constructor(items, requester) {
    this.items = items;
    this.requester = requester;
  }
​
  requestItems() {
    this.items.forEach((item) => {
      this.requester.requestItem(item);
    });
  }
}
​
class InventoryRequesterV1 {
  constructor() {
    this.REQ_METHODS = ['HTTP'];
  }
​
  requestItem(item) {
    // ...
  }
}
​
class InventoryRequesterV2 {
  constructor() {
    this.REQ_METHODS = ['WS'];
  }
​
  requestItem(item) {
    // ...
  }
}
​
// 通过外部创建依赖项并将它们注入， 我们可以轻松的用一个崭新的使用 WebSockets 的请求模块进行
// 替换。
const inventoryTracker = new InventoryTracker(['apples', 'bananas'], new InventoryRequesterV2());
inventoryTracker.requestItems();

并发

Async/Await 比 Promises 更加简洁

Promises 是回调的一个非常简洁的替代品， 但是 ES2017/ES8 带来的 async 和 await 提供了一个 更加简洁的解决方案。 你需要的只是一个前缀为 async 关键字的函数， 接下来就可以不需要 then 函数链来编写逻辑了。 如果你能使用 ES2017/ES8 的高级功能的话， 今天就使用它吧！

不好的：

require('request-promise').get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin')
  .then((response) => {
    return require('fs-promise').writeFile('article.html', response);
  })
  .then(() => {
    console.log('File written');
  })
  .catch((err) => {
    console.error(err);js
  });

好的：

async function getCleanCodeArticle() {
  try {
    const response = await require('request-promise').get('https://en.wikipedia.org/wiki/Robert_Cecil_Martin');
    await require('fs-promise').writeFile('article.html', response);
    console.log('File written');
  } catch(err) {
    console.error(err);
  }
}

错误处理

抛出错误是一件好事情！ 他们意味着当你的程序有错时运行时可以成功确认， 并且通过停止执行当前堆栈 上的函数来让你知道， 结束当前进程（在 Node 中）， 在控制台中用一个堆栈跟踪提示你。

不要忽略被拒绝的 promise

与你不应忽略来自 try/catch 的错误的原因相同，封装好错误处理的方案。

不好的：

getdata()
.then((data) => {
  functionThatMightThrow(data);
})
.catch((error) => {
  console.log(error);
});

好的：

getdata()
.then((data) => {
  functionThatMightThrow(data);
})
.catch((error) => {
  // One option (more noisy than console.log):
  console.error(error);
  // Another option:
  notifyUserOfError(error);
  // Another option:
  reportErrorToService(error);
  // OR do all three!
});

注释

仅仅对包含复杂业务逻辑的东西进行注释

注释是代码的辩解， 不是要求。 多数情况下， 好的代码就是文档。

avatar
文章
阅读
粉丝