无暇代码（js的整洁之道）

如果你关注代码本身和代码的编写方式，而不是只关心它是否能工作，那么你写代码是有一定的水准。专业开发人员将为未来的自己和“其他人”编写代码，而不仅仅只编写当前能工作就行的代码。在此基础上，简洁代码可以定义为自解释的、易于人理解的、易于更改或扩展的代码。

1. 强类型检查

用===代替 ==

// 如果处理不当，它会极大地影响程序逻辑。这就像，你想向左走，但由于某种原因，你向右走
0 == false // true
0 === false // false
2 == "2" // true
2 === "2" // false

// 例子
const value = "500";
if (value === 500) {
  console.log(value);
  // 条件不成立，不会进入
}

if (value === "500") {
  console.log(value);
  // 条件成立，会进入
}

2.变量

用知名其意的方式为变量命名，通过这种方式，当一个人看到它们时，易于搜索和理解。

不好的方式：

let daysSLV = 10;
let y = new Date().getFullYear();

let ok;
if (user.age > 30) {
  ok = true;
}

好的方式：

const MAX_AGE = 30;
let daysSinceLastVisit = 10;
let currentYear = new Date().getFullYear();

...

const isUserOlderThanAllowed = user.age > MAX_AGE;

不要在变量名中添加额外的不需要的单词。

不好的方式：

let nameValue;
let theProduct;

好的方式：

let name;
let product;

不要简写变量上下文。

不好的方式：

const users = ["John", "Marco", "Peter"];
users.forEach(u => {
  doSomething();
  doSomethingElse();
  // ...
  // ...
  // ...
  // ...
  // 当上面代码很多的时候 ，这 `u` 是什么鬼
  register(u);
});

好的方式：

const users = ["John", "Marco", "Peter"];
users.forEach(user => {
  doSomething();
  doSomethingElse();
  // ...
  // ...
  // ...
  // ...
  register(user);
});

不要添加不必要的上下文。

不好的方式：

const user = {
  userName: "John",
  userSurname: "Doe",
  userAge: "28"
};

...

user.userName;

好的方式：

const user = {
  name: "John",
  surname: "Doe",
  age: "28"
};

...

user.name

3. 函数

使用长而具有描述性的名称。考虑到函数表示某种行为，函数名称应该是动词或短语，用以说明其背后的意图以及参数的意图。函数的名字应该说明他们做了什么。

不好的方式：

function notif(user) {
  // implementation
}

好的方式：

function notifyUser(emailAddress) {
  // implementation
}

避免使用大量参数。理想情况下，函数应该指定两个或更少的参数。参数越少，测试函数就越容易，参数多的情况可以使用对象。

不好的方式：

function getUsers(fields, fromDate, toDate) {
  // implementation
}

好的方式：

function getUsers({ fields, fromDate, toDate }) {
  // implementation
}

getUsers({
  fields: ['name', 'surname', 'email'],
  fromDate: '2019-01-01',
  toDate: '2019-01-18'
});

使用默认参数替代 || 操作

不好的方式：

function createShape(type) {
  const shapeType = type || "cube";
  // ...
}

好的方式：

function createShape(type = "cube") {
  // ...
}

一个函数应该只做一件事，不要在一个函数中执行多个操作。

不好的方式：

function notifyUsers(users) {
  users.forEach(user => {
    const userRecord = database.lookup(user);
    if (userRecord.isVerified()) {
      notify(user);
    }
  });
}

好的方式：

function notifyVerifiedUsers(users) {
  users.filter(isUserVerified).forEach(notify);
}

function isUserVerified(user) {
  const userRecord = database.lookup(user);
  return userRecord.isVerified();
}

使用Object.assign设置对象默认值。

不好的方式：

const shapeConfig = {
  type: "cube",
   200,
  height: null
};

function createShape(config) {
  config.type = config.type || "cube";
  config.width = config.width || 250;
  config.height = config.height|| 250;
}


createShape(shapeConfig);

好的方式：

const shapeConfig = {
  type: "cube",
   200
  // Exclude the 'height' key
};

function createShape(config) {
  config = Object.assign(
    {
      type: "cube",
       250,
      height: 250
    },
    config
  );

  ...
}

createShape(shapeConfig);

不要使用标志作为参数，因为它们告诉函数做的比它应该做的多。

不好的方式：

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

好的方式：

function createFile(name) {
  fs.create(name);
}

function createPublicFile(name) {
  createFile(`./public/${name}`);
}

不要污染全局变量。如果需要扩展现有对象，请使用ES类和继承，而不是在原生对象的原型链上创建函数。

不好的方式：

Array.prototype.myFunc = function myFunc() {
  // implementation
};

好的方式：

class SuperArray extends Array {
  myFunc() {
    // implementation
  }
}

4. 条件

避免使用反面条件。

不好的方式：

function isUserNotBlocked(user) {
  // implementation
}

if (!isUserNotBlocked(user)) {
  // implementation
}

好的方式：

function isUserBlocked(user) {
  // implementation
}

if (isUserBlocked(user)) {
  // implementation
}

使用条件简写。这可能微不足道，但值得一提。仅对布尔值使用此方法，并且如果你确信该值不会是undefined 或null的，则使用此方法。

不好的方式：

if (isValid === true) {
  // do something...
}

if (isValid === false) {
  // do something...
}

好的方式：

if (isValid) {
  // do something...
}

if (!isValid) {
  // do something...
}

尽可能避免条件句，而是使用多态性和继承。

不好的方式：

class Car {
  // ...
  getMaximumSpeed() {
    switch (this.type) {
      case "Ford":
        return this.someFactor() + this.anotherFactor();
      case "Mazda":
        return this.someFactor();
      case "McLaren":
        return this.someFactor() - this.anotherFactor();
    }
  }
}

好的方式：

class Car {
  // ...
}

class Ford extends Car {
  // ...
  getMaximumSpeed() {
    return this.someFactor() + this.anotherFactor();
  }
}

class Mazda extends Car {
  // ...
  getMaximumSpeed() {
    return this.someFactor();
  }
}

class McLaren extends Car {
  // ...
  getMaximumSpeed() {
    return this.someFactor() - this.anotherFactor();
  }
}

5. 类

class 是JavaScript中新的语法糖。一切工作就像以前的原型，只是它现在看起来不同，你应该更喜欢他们比ES5普通功能。

不好的方式：

const Person = function(name) {
  if (!(this instanceof Person)) {
    throw new Error("Instantiate Person with `new` keyword");
  }

  this.name = name;
};

Person.prototype.sayHello = function sayHello() { /**/ };

const Student = function(name, school) {
  if (!(this instanceof Student)) {
    throw new Error("Instantiate Student with `new` keyword");
  }

  Person.call(this, name);
  this.school = school;
};

Student.prototype = Object.create(Person.prototype);
Student.prototype.constructor = Student;
Student.prototype.printSchoolName = function printSchoolName() { /**/ };

好的方式：

class Person {
  constructor(name) {
    this.name = name;
  }

  sayHello() {
    /* ... */
  }
}

class Student extends Person {
  constructor(name, school) {
    super(name);
    this.school = school;
  }

  printSchoolName() {
    /* ... */
  }
}

使用链接。许多库(如jQuery和Lodash)都使用这种模式。在类中，只需在每个函数的末尾返回this就可以将更多的该类方法链接到它上。

不好的方式：

class Person {
  constructor(name) {
    this.name = name;
  }

  setSurname(surname) {
    this.surname = surname;
  }

  setAge(age) {
    this.age = age;
  }

  save() {
    console.log(this.name, this.surname, this.age);
  }
}

const person = new Person("John");
person.setSurname("Doe");
person.setAge(29);
person.save();

好的方式：

class Person {
  constructor(name) {
    this.name = name;
  }

  setSurname(surname) {
    this.surname = surname;
    // Return this for chaining
    return this;
  }

  setAge(age) {
    this.age = age;
    // Return this for chaining
    return this;
  }

  save() {
    console.log(this.name, this.surname, this.age);
    // Return this for chaining
    return this;
  }
}

const person = new Person("John")
    .setSurname("Doe")
    .setAge(29)
    .save();

这只是改进代码的一小部分。一般生活入，这里所说的原则是人们通常不遵守的原则。他们尝试着去做，但出于各种原因，就没有坚持下去。也许在项目开始时，代码是简洁的，但是当要在截止日期前完成时，这些原则常常被忽略，并被转移到“TODO”或“REFACTOR”部分。在这一点上，你的客户更希望您在最后期限之前完成任务，而不是编写简洁的代码。

扩展：

有意義的命名讓名稱代表意圖，使之名符其實
避免误导 (命名) • 小写的 L 或是⼤大写的 O • ⼀一群帳⼾戶：accountList ❌ • 三⾓角形斜邊 (hypotenuse) : hp ❌ int a = 1; if (O == l) a = O1; else l = 01;
有意義的區別 • 別⽤用序列列命名 (a1, a2, … , aN) • 无意义的字詞是多餘的 ProductInfo vs ProductData • 参数名改⽤用 source, destination 會更更好理理解 public static void copyCharts(char a1[], char a2[]) { for (int i = 0; i < a1.length; i++) { a2[i] = a1[i]; } }
能念念出來來可以幫助記憶 genymdhms() 字⾯面上看起來來是⼀一個產⽣生 timestamp 的⽅方法，但無法藉由發⾳音幫助記憶，不是個良好的命名。
可被搜寻的名字 • 長命名勝過短命名，常数作為命名，搜尋時更更準確，不易易造成 bug 比 5 還來來的容易易被找到WORK_DAYS_PER_WEEK
不要⽤用匈牙利利命名法 https://zh.wikipedia.org/wiki/匈牙利利命名法 • 变数前加上型別 lAccountNum：變數是⼀一個長整數（"l"） arru8NumberList：變數是⼀一個無符號8位元整型陣列列（"arru8"） szName：變數是⼀一個零結束字串串（”sz") 成員的字⾸首 • 不要額外加上字⾸首 m_dsc = name;
類別的命名 • ⽤用名詞 Customer • 避免使⽤用含糊不清的字 Data, Info, Manager, Processor
⽅方法的命名 • ⽤用動詞 postPayment • Javabean ❖ 取出器(accessors): get ❖ 修改器(mutators): set ❖ 判定器(predicates): is
不要裝可愛 • 清楚闡述比娛樂還來來的重要多了了。 DeleteItems 命名成 HolyHandGrenade (神聖⼿手榴彈) EatMyShort(來來吃我褲襠) 來來表達 abort
別加無理理由的上下⽂文資訊 • 在同⼀一個應⽤用中，不需要在所有類別加上共同的字⾸首，如此反⽽而造成各 IDE 中⾃自動補⿑齊功能無法於第⼀一時間補⿑齊。 • 較少的名稱若若可以清楚表達，勝過於長名稱。
遵循上⾯面所說的規則，然後觀察你的程式碼可讀性是否獲得了了改善
函式函式是所有程式組成的⾸首要基礎
簡短 • 函式的⾸首要準則就是要簡短。 • 第⼆二項準則，就是要比第⼀一項還要簡短。
只做⼀一件事情 • 函式應該做⼀一件事，它們應該把這件事做好，⽽而且只做這件事。
Switch 敘述 • 太過冗長 • 做超過⼀一件事 • 違反單⼀一職責原則 (SRP) • 當加入新形態時，違反開放封閉原則 (OCP) 1 public Money caluculatePay(Employee e) throws InvalidEmployeeType { 2 switch (e.type) { 3 case COMMISSIONED: 4 return calculateCommissionedPay(e); 5 case HOURLY: 6 return calculateHourlyPay(e); 7 default: 8 throw new InvalidEmployeeType(e.type); 9 } 10 }
Switch 敘述 • 把 Switch 埋在抽象⼯工廠 (Abstract Factory) 底下 1 public Money caluculatePay(Employee e) throws InvalidEmployeeType { 2 switch (e.type) { 3 case COMMISSIONED: 4 return calculateCommissionedPay(e); 5 case HOURLY: 6 return calculateHourlyPay(e); 7 default: 8 throw new InvalidEmployeeType(e.type); 9 } 10 }
使⽤用具描述能⼒力力的名稱 • 『當每個你看到的程式，執⾏行行結果都與你想的差不多，你會察覺到你正⼯工作在 Clean Code 之上』
函式的參參數 • 最理理想的是 (零參參數函式:niladic) • 其次是 (單函式參參數:monadic) • 再者才是兩兩個(雙參參數函式:dyadic)。 • 非必要使⽤用 (三參參數函式:triadic)，(多參參數函式:polyadic)
旗標參參數 • 將布林林傳給函式，是⼀一種很恐怖的習慣 • 這會造成該函式不只做⼀一件事情 True: doSomething, False: SaySomething
兩兩個參參數的函式的命名 • writeField(name) vs writeField(outputStream, name) 雖然兩兩個都很清楚，但第⼆二個要做短暫的停留留思考，容易易令⼈人忽略略進⽽而有機會產⽣生 bug。 • assertEquals(expected, actual) 你是否曾經搞錯 expected, actual 這兩兩者的位置？
三個參參數的函式 • assertEquals(message, expected, actual) 看到 message 卻以為他是 expected？ • 使⽤用者容易易被三個參參數絆住或頓住，需要反覆查看參參數。
要無副作⽤用 • 保證只做⼀一件事！ • 不要在暗地裡偷偷做了了其他事情 ‣ 轉換成其他傳參參數傳給其他函式 ‣ 變成全域變數
使⽤用”例例外處理理” 取代 “回傳錯誤碼” • try/catch 會混淆結構，將函式從 try 和 catch 中提取出來來 1 public void delete(Page page) { 2 try { 3 deletePageAndAllReferences(pages); 4 } catch (Exception e) { 5 logError(e); 6 } 7 }
不要重複⾃自⼰己 • DRY (Don’t Repeat Yourself.) • 重複的程式碼是軟體裡所有邪惡惡的根源
結構化程式設計 • 每個函式，以及每個函式理理的區塊，都應該只有⼀一個進入點及⼀一個離開點。 • 我們現在都⽤用 Guard Clause 原則了了
如何寫出這種函式 • 將函式分開，重新命名，減少重複 • 我不會⼀一開始就這樣寫，我也不認為有⼈人可以辦得到
函式是這個語⾔言的動詞類別是這個語⾔言的名詞如果你遵循這章的準則：你的函式會簡短，有良好的命名，以及漂亮的結構
註解真相永遠只存在⼀一個地⽅方：程式碼
註解無法彌補糟糕的程式碼 • 整潔具有表達⼒力力⼜又極少使⽤用註解的程式碼，遠優於雜亂⼜又滿是註解的程式碼。
⽤用程式碼表達你的本意 • 多想幾秒鐘，在⼤大部分情況下的註解，都可以簡單地融入到建立的函式名稱中。
有益的註解 • 真正有益的註解，是你想辦法不寫它的註解
法律律型的註解 • 有些需要撰寫標準規範，或者著作權聲明、作者資訊等，就是必須且合理理的註解。比較好的做法是讓註解去參參考⼀一個外部註解 // Copyright (c) 2003, 2004, 2005 by Object Mentor, Inc. All rights reserved. // Released under the terms of GNU General Public License version 2 or late.
對於後果的告誡 • ⽤用於警告其他⼯工程師會出現某種特殊後果的註解，也是有⽤用的。
TODO (代辦事項) 註解 • TODO 是⼯工程師認為應該要完成的事情，但基於某些原因無法在此時做到。 ‣ 提醒移除過時的功能 ‣ 請某⼈人注意這個問題 ‣ 請某⼈人尋找更更好的命名 ‣ 依賴於某個未來來計畫⽽而提醒所需要的修改 • 最後不管如何，都不應該成為讓糟糕程式碼留留在系統裡的藉⼝口。
糟糕的註解 • 喃喃⾃自語 • 多餘的註解 • 規定型註解 • ⼲干擾型註解
糟糕的註解 - 喃喃⾃自語 • 如果你決定要寫註解，你就應該要花上必要的時間，確保你寫出的是最好的註解
糟糕的註解 - 多餘的註解 • 含有開頭註解的簡單函式，讀這段註解可能比讀這段程式更更花時間 1 // Utility method that returns when this.closed is true. Throws an exception 2 // if the timeout is reached. 3 public synchronized void waitForClose(final long timeoutMillis) 4 throws Exception 5 { 6 if (!closed) { 7 wait(timeoutMillis); 8 if(!closed) 9 throw new Exception ("MockResponseSender could not be closed"); 10 } 11 }
糟糕的註解 - 規定型註解 • 含有開頭註解的簡單函式，讀這段註解可能比讀這段程式更更花時間 1 /** 2 * 3 * @param title The title of the CD 4 * @param author The author of the CD 5 * @param tracks The number of tracks on the CD 6 * @param durationInMinutes The duration of the CD in munutes 7 */ 8 public void addCD(String title, String author, int tracks, int durationInMinutes) 9 { 10 CD cd = new CD(); 11 cd.title = title; 12 cd.author = author; 13 cd.tracks = tracks; 14 cd.duration = durationInMinutes; 15 cdList.add(cd); 16 }
糟糕的註解 - ⼲干擾型註解 • 沒有被⼲干擾到，真的嗎？ 1 /* 2 * Default constructor. 3 */ 4 protected AnnualDateRule() {} 5 6 /* The day of the month. */ 7 private int dayOfMonth; 8 9 /* 10 * Return the day of the month. 11 * 12 * @return the day of the month. 13 */ 14 public int getDatofMonth() 15 { 16 return dayOfMonth; 17 }
當你可以使⽤用函式或者變數時就別⽤用註解 1 // does the module from the global list<mod> depend on the 2 // subsystem we are part of? 3 if (semodule.getDependSubSystems().contains(subSysMod.getSubSystem()) 4 5 ArrayList moduleDpendees = smodule.getDependSubSystems(); 6 String outSubSystem = subSysMod.getSubSystem(); 7 if (moduleDpendees.contains(ourSubSystem))
出處及署名 • 想要儲存該類的訊息，原始碼版本控制系統(e.g. GIT, SVN)是⼀一個比較好的選擇。 /* Added by Rick */
被註解起來來的程式碼 • 把程式碼註解掉的⾏行行為，這是很討⼈人厭的，不要這樣做!! • 我可以刪掉嗎？還是要繼續留留著？
不要替糟糕的程式碼寫註解，你應該重寫程式碼
編排良好的編排有助於閱讀，也是專業
編排的⽬目的 • 程式的編排實在是太重要了了。 • 程式碼的風格與可讀性，會影響程式的可維護性及可擴充性。
垂直的編排 • 報紙的啟發 • 最重要的概念念會最先出現，希望⽤用最少的細節來來表達他們。
垂直的編排 • 概念念間的垂直空⽩白區隔 • 空⽩白⾏行行代表⼀一個視覺上的提⽰示，提⽰示著空⽩白⾏行行的後⽅方將接續⼀一個新⽽而不同的概念念。 1 private static final Pattern pattern = Pattern.compile("'''(.+?)'''", Pattern.MULTILINE); 2 3 public BoldWidget(ParentWidge parent, String text) throws Exception { 4 super(parent); 5 6 Matcher match = pattern.matcher(text); 7 match.find(); 8 9 addChildWidgets(match.group(1)); 10 }
垂直的密度 • 如果垂直空⽩白區分開個個概念念，那垂直密度則意味著密切相關的程度 • ⼀一看就知道有兩兩個變數，⼀一個⽅方法的類別。 1 public class ReporterConfig { 2 private String m_className; 3 private List<Property> m_properties = new ArrayList<Property>(); 4 5 public void addProperty($Property property) { 6 m_properties.add(property); 7 } 8 }
垂直的距離 • 相近的概念念，在垂直編排上，要盡可能的靠近 • 相近的概念念不該被分散在不同的檔案裡 • 垂直的距離⽤用來來衡量量他們對彼此的了了解有多重要
垂直的距離 - 變數宣告 • 盡可能靠近變數被使⽤用的地⽅方，因為我們的函⽰示非常簡短。 1 public int countTestCase() { 2 int count = 0; 3 for (Test each: tests) 4 count += each.countTestCased(); 5 return count; 6 }
垂直的距離 - 實體變數 • 實體變數都應該被宣告在⼀一個⼤大家都熟悉的地⽅方，通常放在類別的最上⽅方。
垂直的距離 - 相依的函式 • 如果函式呼叫了了另⼀一個函式，那兩兩個函式在垂直編排上要盡可能靠近。由上⽽而下，增加模組的可讀性。
垂直的距離 - 概念念相似性 • 函式的概念念上有⾼高度相似性時，垂直距離應該愈短愈好。 • 概念念上的⾼高度相似性 • 類似的命名規則 • 就算沒有互相呼叫，也應該盡可能放在⼀一起
水平的編排 - 空⽩白間格和密度 • 運算⼦子(assignment operators) 的左右都加入空⽩白，使其更更為突出 • 函式名稱和⼩小左括號之間不空⽩白 • 空⽩白的另⼀一種⽤用途是強調運算⼦子的優先權
水平的對⿑齊 • 沒有幫助，我傾向不再為宣告與設定敘述作特別的對⿑齊 1 public int FitNesseExpediter(Scoket s, 2 FitNesseContext context) throws Exception 3 { 4 this.context = context; 5 scocket = s; 6 input = s.getInputStream(); 7 output = s.getOutputStream(); 8 reguestParsingTimeLimit = 1000, 9 10 }
縮排 • ⼀一個原始檔是個階層結構，⽽而非⼤大綱結構。 • 讓視野的層次結構更更顯⽽而易易⾒見見 ‣ 檔案 ‣ 類別 ‣ ⽅方法 ‣ 程式區塊 ‣ ⺟母程式 ‣ ⼦子程式
你們團隊的共同準則？
錯誤處理理錯誤處理理很重要，但不該模糊原本程式碼邏輯
使⽤用例例外事件⽽而非回傳錯誤碼 • 比較好的做法是，在你遇到⼀一個錯誤的時候，拋出⼀一個例例外事件。如此，呼叫程式碼就會變得乾淨許多。
在開頭寫下你的 Try-Catch-Finally 敘述 • 如果你寫的程式可能會拋出例例外事件，請養成 try-catch- ﬁnally 成為開頭敘述的好習慣。
提供發⽣生例例外的相關資訊 • 請傳遞⾜足夠的資訊給 catch 區，使例例外能夠被記錄下來來。
不要回傳 null (空值) • 不要回傳 null ，因為只要有⼀一處忘記檢查 null，就會導致程式進入混亂無法控制的狀狀態。 • 如果你想讓⽅方法回傳 null ，那不如試著拋出⼀一個例例外事件，或回傳⼀一個 SPECIAL CASE 物件。
不要傳遞 null • ⽅方法回傳 null 是糟糕的⾏行行為。然⽽而傳遞 null 到⽅方法裡是更更糟糕的⾏行行為。 • 當你養成這樣的習慣之後你在寫程式碼時，就會避免傳遞 null 給函式，因為你知道如果 null 出現在參參數裡，代表了了潛在問題的預兆。最終能⼤大幅降低出錯的可能。
Clean Code 是易易讀的，但也是耐⽤用的，這兩兩者不是互相衝突的⽬目標。當我們將錯誤處理理獨立於主要邏輯的可讀程式，我們就能獨立地處理理它，並且在維護性上也向前邁進⼀一⼤大步。
類別更更⾼高層次：《程式碼敘述和程式碼所構成的函式》
類別的結構 • 公⽤用函式(Public function) 應該接在⼀一連串串變數宣告的後⽅方 • 我們喜歡將私有⼯工具函式(Private function) 緊接在呼叫的公⽤用函⽰示後⽅方 • 以上兩兩點遵循『降層法則(Stepdown rule)』，也有助於『讓程式閱讀』
封裝 • 先想辦法保持變數以及⼯工具函式的私有性 (private) ，放鬆封裝限制是最後不得已的⼿手段 • 優先順序：1. protected(⽅方便便進⾏行行測試) 2. public
類別要夠簡短 • 在函式裡，計算真正的程式⾏行行數，來來衡量量函式的⼤大⼩小在類別裡，計算職責的數量量，來來衡量量類別的⼤大⼩小
單⼀一職責原則 (SRP) • 主張⼀一個類別或⼀一個模組只能有⼀一個修改的理理由。 • 我們強調的主張：系統是由許多⼩小型類別左組成，⽽而不是由少數幾個⼤大型類別組成 • 每個⼩小類別『封裝單⼀一的職責』、『只有⼀一個修改的裡由』以及『與其他少數幾個類別合作來來完成系統要求的⾏行行為』
凝聚性 • 保持凝聚性會得到許多⼩小型的類別 • 在⽅方法裡操縱愈多的變數，代表這個⽅方法更更凝聚於該類別。 • 若若有某個類別的每個變數都被使⽤用在每個⽅方法中，那麼這個類別就是具有最⼤大凝聚性的類別
凝聚性 • 當凝聚性⾼高，代表類別裡的⽅方法和變數是相互依賴的，並且相互結和為邏輯上的整體。 • 當類別失去凝聚性的時候，就把他們拆開來來吧！
羽化透過⽻化設計來來達到整潔
一個簡單的設計 ① 執⾏行行完所有的測試 ② 沒有重複的部分 ③ 表達程式設計師的本意 ④ 最⼩小化類別和⽅方法的數量量這些守則，根據重要性來來排序。
簡單設計守則 1: 執⾏行行完所有的測試 • 類別若若遵守單⼀一職責原則 (SRP)，那麼測試就說⼀一件很簡單的事。 • 系統以物件導向的主要⽬目標，讓程式有低耦合度和⾼高凝聚度。所以撰寫測試程式，最終帶來來了了更更佳的設計。
簡單設計守則 2~4: 程式重構 • ⼀一旦有了了測試，就能保持程式和類別的整潔，利利⽤用逐步增加的⽅方式來來進⾏行行重構。 • 重構的過程中，我們可以應⽤用與良好軟體設計有關的所有知識。 ➡ 增加凝聚性 ➡ 降低耦合度 ➡ 分離關注點 ‣ 模組化系統關注點 ‣ 替函式和類別瘦⾝身 ‣ 良好的命名
禁⽌止重複 • 重複程式碼是『良好設計系統』的主要敵⼈人。他代表額外的⼯工作、額外的風險及額外不必要的複雜性。
具表達⼒力力 • 『選擇⼀一個良好的名稱』 • 『讓函式和類別簡短』 • 『標準命名法』 • 『良好的單元測試』也具良好的表達⼒力力，主要⽬目的『⽤用範例例學』 • 多花點時間在你的函式和類別上，選擇較好的名稱，將⼤大型函式拆解成⼩小型函式 • ⽤用⼼心是⼀一項珍貴的資源
最⼩小化類別及⽅方法的數量量 • ⼩小⼼心『消除重複程式碼』，『單⼀一職責原則』這類的基本觀念念會做過頭，⽽而產⽣生太多微型的類別和⽅方法。所以該守則建議我們，必須讓類別及⽅方法的數量量保持少少的。 • 但這條守則卻是簡單設計四守則裡優先最低的。所以測試、消除重複及表達⼒力力等其他三條守則，才是最重要的。
簡單的設計 ① 執⾏行行完所有的測試 ② 沒有重複的部分 ③ 表達程式設計師的本意 ④ 最⼩小化類別和⽅方法的數量量