有時候，我們會陷入一種很不好的習慣中虫啥，那就是蔚约，總是去嘗試寫出永遠不會報錯的函數(shù)。我們會給參數(shù)配上默認值涂籽，在很多地方使用 || 或者 && 來避免代碼運行出錯苹祟，仿佛如果你的函數(shù)報錯會成為某種恥辱似的。而且评雌，當我們嘗試去修復一個運行時報錯的函數(shù)時苔咪，我們往往傾向于在報錯的那一行添加一些兼容邏輯來避免報錯。

舉個例子柳骄，假設我們需要編寫一個獲取用戶詳情的函數(shù)团赏，它要返回一個完整的用戶信息對象：不僅包含ID，名字等基本信息耐薯，也包含諸如「收藏的書籍」等通過額外接口返回的信息舔清。這些額外的接口也許不太穩(wěn)定：

    async function getUserDetail(id) {
  const user = await fetchSingleUser(id);
  user.favoriteBooks = (await fetchUserFavorits(id)).books;
  // 上面這一行報錯了：Can not read property 'books' of undefined.
  // ...
}

假設 fetchUserFavorites 會時不時地返回 undefined，那么讀取其 books 屬性自然就會報錯曲初。為了修復該問題体谒，我們很可能會這樣做：

    const favorites = await fetchUserFavorits(id);
user.favoriteBooks = favorites && favorites.books;
// 這下不會報錯了

這樣做看似解決了問題：的確，getUserDetail 不會再報錯了臼婆，但同時埋下了更深的隱患抒痒。

當 fetchUserFavorites 返回 undefined 時，程序已經(jīng)處于一種異常狀態(tài)了颁褂，我們沒有任何理由放任程序繼續(xù)運行下去故响。試想，如果后面的某個時刻（比如用戶點擊「我收藏的書」選項卡）颁独，程序試圖遍歷 user.favoriteBooks 屬性（它被賦值成了undefined）彩届，那時也會報錯，而且那時排查起來會更加困難誓酒。

如何處理上述的情況呢樟蠕？我認為，如果被我們依賴的 fetchUserFavorits 屬于當前的項目，那么 getUserDetail 對此報錯真的沒什么責任寨辩，因為 fetchUserFavorits 就不應該返回 undefined吓懈，我們應該去修復 fetchUserFavorits，任務失敗時顯式地告知出來靡狞，或者直接拋出異常耻警。同時，getUserDetail 稍作修改：

    // 情況1：顯式告知耍攘，此時應認為獲取不到收藏數(shù)據(jù)不算致命的錯誤
const result = await fetchUserFavorits(id);
if(result.success) {
  user.favoriteBooks = result.data.books;
} else {
  user.favoriteBooks = []
}

// 情況2：直接拋出異常
user.favoriteBooks = (await fetchUserFavorits(id)).books;
// 這時 `getUserDetail` 不需要改動，任由異常沿著調(diào)用棧向上冒泡

那么如果 fetchUserFavorits 不在當前項目中畔勤，而是依賴的外部模塊呢蕾各？我認為，這時你就該為選擇了這樣一個不可靠的模塊負責庆揪，在 getUserDetail 中增加一些「擦屁股」代碼式曲，來避免你的項目的其他部分受到侵害。

    const favorites = await fetchUserFavorits(id);
if(favorites) {
  user.favoriteBooks = favorites.books;
} else {
  throw new Error('獲取用戶收藏失敗');
}

控制函數(shù)的副作用

無副作用的函數(shù)缸榛，是不依賴上下文吝羞，也不改變上下文的函數(shù)。長久依賴内颗，我們已經(jīng)習慣了去寫「有副作用的函數(shù)」钧排，畢竟 JavaScript 需要通過副作用去操作環(huán)境的 API 完成任務。這就導致了均澳，很多原本可以用純粹的恨溜、無副作用的函數(shù)完成任務的場合，我們也會不自覺地采取有副作用的方式找前。

雖然看上去有點可笑糟袁，但我們有時候就是會寫出下面這樣的代碼！

async function getUserDetail(id) {
  const user = await fetchSingleUserInfo(id);
  await addFavoritesToUser(user);
  ...
}
async function addFavoritesToUser(user) {
  const result = await fetchUserFavorits(user.id);
  user.favoriteBooks = result.books;
  user.favoriteSongs = result.songs;
  user.isMusicFan = result.songs.length > 100;
}

上面躺盛，addFavoritesToUser 函數(shù)就是一個「有副作用」的函數(shù)项戴，它改變了 users，給它新增了幾個個字段槽惫。問題在于周叮，僅僅閱讀 getUserData 函數(shù)的代碼完全無法知道，user 會發(fā)生怎樣的改變界斜。

一個無副作用的函數(shù)應該是這樣的：

    async function getUserDetail(id) {
  const user = await fetchSingleUserInfo(id);
  const {books, songs, isMusicFan} = await getUserFavorites(id);
  return Object.assign(user, {books, songs, isMusicFan})
}
async function getUserFavorites(id) {
  const {books, songs} = await fetchUserFavorits(user.id);
  return {
    books, songs, isMusicFan: result.songs.length > 100
  }
}

非侵入性地改造函數(shù)

函數(shù)是一段獨立和內(nèi)聚的邏輯则吟。在產(chǎn)品迭代的過程中，我們有時候不得不去修改函數(shù)的邏輯锄蹂，為其添加一些新特性氓仲。之前我們也說過，一個函數(shù)只應做一件事，如果我們需要添加的新特性敬扛，與原先函數(shù)中的邏輯沒有什么聯(lián)系晰洒，那么決定是否通過改造這個函數(shù)來添加新功能，應當格外謹慎啥箭。

仍然用「向服務器查詢用戶數(shù)據(jù)」為例谍珊，假設我們有如下這樣一個函數(shù)（為了讓它看上去復雜一些，假設我們使用了一個更基本的 request 庫）：

    const fetchUserInfo = (userId, callback) => {
  const param = {
    url: '/api/user',
    method: 'post',
    payload: {id: userId}
  };
  request(param, callback);
}

現(xiàn)在有了一個新需求：為 fetchUserInfo 函數(shù)增加一道本地緩存急侥，如果第二次請求同一個 userId 的用戶信息砌滞，就不再重新向服務器發(fā)起請求，而直接以第一次請求得到的數(shù)據(jù)返回坏怪。

按照如下快捷簡單的解決方案贝润，改造這個函數(shù)只需要五分鐘時間：

    const userInfoMap = {};
const fetchUserInfo = (userId, callback) => {
  if (userInfoMap[userId]) {            // 新增代碼
    callback(userInfoMap[userId]);    // 新增代碼
  } else {                              // 新增代碼
    const param = {
      // ... 參數(shù)
    };
    request(param, (result) => {
      userInfoMap[userId] = result;   // 新增代碼
      callback(result);
    });
  }
}

不知你有沒有發(fā)現(xiàn)，經(jīng)此改造铝宵，這個函數(shù)的可讀性已經(jīng)明顯降低了打掘。沒有緩存機制前，函數(shù)很清晰鹏秋，一眼就能明白尊蚁，加上新增的幾行代碼，已經(jīng)不能一眼就看明白了侣夷。

實際上横朋，「緩存」和「獲取用戶數(shù)據(jù)」完全是獨立的兩件事。我提出的方案是百拓，編寫一個通用的緩存包裝函數(shù)（類似裝飾器）memorizeThunk叶撒，對 fetchUserInfo 進行包裝，產(chǎn)出一個新的具有緩存功能的 fetchUserInfoCache耐版，在不破壞原有函數(shù)可讀性的基礎上祠够，提供緩存功能。

    const memorizeThunk = (func, reducer) => {
  const cache = {};
  return (...args, callback) => {
    const key = reducer(...args);
    if (cache[key]) {
      callback(...cache[key]);
    } else {
      func(...args, (...result) => {
        cache[key] = result;
        callback(...result);
      });
    }
  }
}
const fetchUserInfo = (userInfo, callback) => {
  // 原來的邏輯
}
const fetchUserInfoCache = memorize(fetchUserInfo, (userId) => userId);

也許實現(xiàn)這個方案需要十五分鐘粪牲，但是試想一下古瓤，如果將來的某個時候，我們又不需要緩存功能了（或者需要提供一個開關來打開/關閉緩存功能）腺阳，修改代碼的負擔是怎樣的落君？第一種簡單方案，我們需要精準（提心吊膽地）地刪掉新增的若干行代碼亭引，而我提出的這種方案绎速，是以函數(shù)為單位增刪的，負擔要輕很多焙蚓，不是嗎纹冤？

類的結構

避免濫用成員函數(shù)

總結

偉大的文學作品都是建立在廢紙堆上的洒宝，不斷刪改作品的過程有助于寫作者培養(yǎng)良好的「語感」。當然萌京，代碼畢竟不是藝術品雁歌，程序員沒有精力也不一定有必要像作家一樣反復打磨自己的代碼/作品。但是知残，如果我們能夠在編寫代碼時稍稍多考慮一下實現(xiàn)的合理性靠瞎，或者在添加新功能的時候稍稍回顧一下之前的實現(xiàn)，我們就能夠培養(yǎng)出一些「代碼語感」求妹。這種「代碼語感」會非常有助于我們寫出高質(zhì)量的可讀的代碼乏盐。