每日 30 秒 ⏱ 該不應優雅

簡介

可讀性、性能、Spread、Reduce

在 優雅三連擊 中有同窗提到了 可讀性 這個關鍵詞，就小二我的的觀點 在某個範圍內使用比較經常使用到的小技巧，能夠提高必定的可讀性，文中提到的短路運算在初始化變量是提高可讀性的，而且在不少提倡優化if 語句的時候，短路運算符也能夠起到對簡單條件語句的優雅。

// 優雅前
if (name == '') {
    name = 'anonymous'
}

// 優雅後
name = name || 'anonymous'
複製代碼

畢竟可讀性能使得代碼方便理解，甚至作到不須要註釋，也包括讓人能閱讀愉快。但不能濫用這些方法來把代碼全都揉成一團，這個度怎麼把握就是一門學問，不少時候與我的習慣和經驗都有必定的關係。

優雅不是一蹴而就，而是在醜化的代碼中慢慢優雅。-- 魯迅

Spread

ES6的新語法糖 spread 甜得不得了，可是你知道它並不比Object.assign() 快嗎？

const user = { name: 'xiaoer', height: '183' }; 

// ES6 - spread
const useSpread = { age: 18, ...params };

// Object.assign()
const useAssign = Object.assign({}, { age: 18 }, params);
複製代碼

這兩種方法 spread 語法顯然更優雅，可是在 性能基準測試 中 Object.assign() 肉眼可見的快了50%-60%。

Reduce

Array.reduce() 能夠和大程度上提高代碼的可讀性，可是你知道 loop 其實更快嘛？

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

// Array.reduce
numbers.reduce((count, i) => count + i, 0);

// loop
function sum(arr) {
    let count = 0;
    for (let i = 0; i < arr.length; i++) {
        count += arr[i]
    }
    return count;
}

sum(numbers);
複製代碼

很顯然 Array.reduce() 的寫法更優雅，可是在 性能基準測試 中 for 循環 肉眼可見的快了90%。

怎麼辦

上面兩個關於優雅的例子性能對比之下，不知道該不應繼續使用優雅方法？是否是本身以前寫的代碼都糟糕極了？

其實沒必要於太過糾結該不應，新的 ES6 語法糖很大程度上是爲了提高開發體驗和功能， 而且一些小技巧能夠提高可讀性和愉悅感，當遇到海量數據須要考慮優化時選擇 性能，當其餘較爲繁瑣的代碼選擇可讀性，若是你真的很在乎這個能夠看看這幾個建議：

何時可讀性優先

• 其實如今的硬件性能已經很是快了，處理數據很少不少時候犧牲一點性能換取可讀性是應該的，畢竟開發和維護在不少時候並非一我的的事情，而是一整個團隊幾百號人。
• 有的時候項目開發中上級給你分配了好幾個新人，出於開發進度和新人的不熟練，能夠選擇可讀性優先，並在後期維護時對性能分析並選取優化性能。
• 編寫實例代碼或者教程、類庫時，考慮到讀者的水平不必定都同樣時，也能夠優先可讀性在後續文章或者迭代中補充說明。小二在寫文章的時候，就是這樣把不少概念拆開來，使得閱讀時只須要聚焦一個知識點，並經過不斷更新來完善其餘知識。
• 我的項目那確定是怎麼舒服怎麼來，畢竟是要愉悅本身。

何時性能優先

• 其實性能優先和可讀性優先都是相對的。
• 當項目在運行時發現了特別明顯的卡頓等性能問題時，就須要優先考慮性能了。
• 在處理大量數據時就須要考慮性能了。有的同窗會說項目哪裏有這麼多數據，還真別說小二作過一個很是蛋疼的項目，後端直接返回幾萬條數據讓前端來處理。別說話吻我，我不想回憶這段過去了。
• 更多的取捨應該要出於項目實際狀況進行選擇，有些性能問題是能夠提早預知的，必定程度的分析需求能夠節省不少代碼時間。

其餘

• 關於 基準測試 更多操做能夠查看 誰敢與我一戰 。
• 關於 spread 更多操做能夠查看 函數參數騷操做。
• 關於基準測試中快速初始化測試數組能夠查看 優雅初始化數組。
• 關於大量數據優化能夠查看 海量數據切割。

一塊兒成長

在困惑的城市裏總少不了並肩同行的 夥伴 讓咱們一塊兒成長。

• 若是您想讓更多人看到文章能夠點個 點贊。
• 若是您想激勵小二能夠到 Github 給個 小星星。
• 若是您想與小二更多交流添加微信 m353839115。

本文原稿來自 PushMeTop