如何透過錯誤的 await 來造成效能低落
常常有人說「await 可能會導致效能低落」，讓我們換個角度，先講講怎麼正確的把 Promise chain 轉化為 await ，再來說說如何把它的效能變差 😜
定義題目
以下有 3 條長長的 Promise chain 如下：
很明顯的，這 6 個 task 都是非同步且回傳 Promise 的函數：
- 1 與 11有 dependency
- 2 與 22 有 dependency
- 3 與 33 有 dependency。
當然這樣子有點多 {} 的 Promise chain 總會讓人想起被 callback hell 統治的時光。
曾經在 ES3 時代當過工程師的主管，這時在你耳邊用氣音問你：「能不能寫的再好看一點？」
於是你動動你的鬼腦袋：
由於箭頭函數沒有 {} 的話會隱式 return 箭頭後的函數結果。
而 Promise 內部 return 一個 Promise resolve 則外邊可以繼續 then 並且接到結果，所以你可以這樣寫。
聽說 ES7 的 await 不錯，你可以試著用 await 嗎？
主管突然提出了這個需求，因為他實在是不喜歡 Promise 一直 then then then 的寫法。
那麼我們都知道 await 嘛，需要有 async 宣告的函數才能用，所以我們可以把這三個具有 dependency 的三組東西封裝在三個 async 函數裡頭。
很好，至此你已經基本上把三條鏈式呼叫的 Promise 用 await 替代了。
我是為了寫爛 Code 才點進來的，哥，你教這些，是在哈囉？
很好，以上都是正確的寫法，唯一秘訣在於上面那一步分拆非同步函數。
但是往往，我們在處理同一個函數中具有多條 Promise chain 的時候會讓效能低落。
這兩個東西有什麼差別嗎？求證明
我們把這坨我稱之為導致效能低落的 await 代碼 reverse 回 Promise chain 會長這樣：
尾聲
文章是想用戲謔的方式講解如何將 await 寫的差勁，但是，其實從 Promise 的 dependency 整理好之後，這樣寫差的行為反而會變得如此刻意。
這告訴我們什麼呢？
往往差勁的代碼都是在不經思考時寫出來的，如果我們不去了解 async await 他背後的意義，只是一味的在 Promise 的函數瘋狂 await，才能夠行雲流水的寫出爛 Code 。
