問題描述

$scope.del = function () { var delItemId = getDelId(); // 要刪除的項目的身份標(biāo)識 // 如果沒選擇刪除項 if (!delItemId.length) {$promptLayer.show({ str: $message.delItemIsEmpty});return; } delTarArr = delItemId; $weuiAndroidDialog2.show($message.store.delConfirm, $message.store.delCloseBtn, $message.store.delOkBtn);};// 確認(rèn)刪除$rootScope.$on(’androidDialog2Btn1’, function () { del( delTarArr.join(’,’) ); $weuiAndroidDialog2.hide();});// 取消刪除$rootScope.$on(’androidDialog2Btn0’, function () { $weuiAndroidDialog2.hide();});var delTarArr;// 獲取要刪除項標(biāo)識function getDelId() { var delTarArr = []; $angular.forEach($scope.selectAllItem, function (v, i) {if (v) { delTarArr.push($scope.storeList[i].Sid);} }); return delTarArr;}// 刪除function del(param) { // 請求刪除接口 $handler.store.del( param ).then(function () {delAllJumpPage(delTarArr.length, $scope.selectAllItem.length); // 刪空跳頁 });}// 刪空跳頁function delAllJumpPage(delNum, totalNum) { var curPage = $scope.pageControlCurNum; // 當(dāng)前所在頁數(shù) // 此頁刪空 跳上一頁 if (delNum === totalNum)curPage = curPage - 1; $scope.loadList(curPage); $scope.pageControlCurNum = curPage;}

or

var delTarArr;$scope.del = function () { // 看是否有選中項 $angular.forEach($scope.selectAllItem, function (v, i) {if (v) { delTarArr.push($scope.storeList[i].Sid); // 獲取選中項 Sid } }); // 如果沒有刪除項 if (!delTarArr.length) {$promptLayer.show({ str: $message.delItemIsEmpty});return; } // 再次確認(rèn)提示層 $weuiAndroidDialog2.show($message.store.delConfirm, $message.store.delCloseBtn, $message.store.delOkBtn);};// 確認(rèn)刪除$rootScope.$on(’androidDialog2Btn1’, function () { // 請求刪除接口 $handler.store.del( delTarArr.join(’,’) ).then(function () {// 刪空跳頁var curPage = $scope.pageControlCurNum; // 當(dāng)前所在頁數(shù)// 此頁刪空 跳上一頁if (delTarArr.length === $scope.selectAllItem.length) curPage = curPage - 1;$scope.loadList(curPage);$scope.pageControlCurNum = curPage; }); $weuiAndroidDialog2.hide();});// 取消刪除$rootScope.$on(’androidDialog2Btn0’, function () { $weuiAndroidDialog2.hide();});

這兩段代碼哪個相對較優(yōu)一點(diǎn)…… 雖然都挺渣的 大佬們對付看吧

一個函數(shù)只能干一件事這么做是為什么 可讀性？擴(kuò)展性？復(fù)用性？在我看來聲明函數(shù)也不是沒有成本的啊 一個函數(shù)就占內(nèi)存的一些空間呢 調(diào)用函數(shù)也沒有直接解析來的快吧~

如果是為了復(fù)用、擴(kuò)展的話 第一次寫的時候就這樣做的真的不是提前優(yōu)化嗎 以后的需求都確定不了呢 怎么知道提出的函數(shù)放在未來是通用的呢 這樣看絕對不是最佳性能的實(shí)踐啊~

提前 / 過渡優(yōu)化不是萬惡之源嗎？~

問題解答

就一個類而言，應(yīng)該僅有一個引起它變化的原因。在 JavaScript 中，需要用到類的場景并不太多，單一職責(zé)原則更多地是被運(yùn)用在對象或者方法級別上，因此本節(jié)我們的討論大多基于對象和方法。單一職責(zé)原則（SRP）的職責(zé)被定義為“引起變化的原因”。如果我們有兩個動機(jī)去改寫一個方法，那么這個方法就具有兩個職責(zé)。每個職責(zé)都是變化的一個軸線，如果一個方法承擔(dān)了過多的職責(zé)，那么在需求的變遷過程中，需要改寫這個方法的可能性就越大。此時，這個方法通常是一個不穩(wěn)定的方法，修改代碼總是一件危險的事情，特別是當(dāng)兩個職責(zé)耦合在一起的時候，一個職責(zé)發(fā)生變化可能會影響到其他職責(zé)的實(shí)現(xiàn)，造成意想不到的破壞，這種耦合性得到的是低內(nèi)聚和脆弱的設(shè)計。因此， SRP 原則體現(xiàn)為：一個對象（方法）只做一件事情。

談一下個人見解，程序是給人讀的，一個函數(shù)的復(fù)雜度越高，讀通的成本就越高。即使是你寫的程序，幾個月后，看懂其中的意思可能就需要一會兒，何況別人也可能接手你的代碼！

程序先讓人看懂了，再談運(yùn)行的性能優(yōu)化

如果你的代碼只需要用很短的時間，不需要以后迭代，不需要提供給其他同事用，也不需要單元測試，那么隨便寫吧，功能實(shí)現(xiàn)就行了。

如果你的代碼需要被其他同事調(diào)用，需要進(jìn)行迭代，需要擴(kuò)展，需要單元測試。那還是按照規(guī)范來做吧，性能從來就不是代碼的形式?jīng)Q定的。

最簡單的方法，如果你的代碼隔一個月以后自己來看，發(fā)現(xiàn)很難閱讀，很難維護(hù)，很難擴(kuò)展，那還是重構(gòu)吧。

我認(rèn)為一個函數(shù)只干一件事更好 .... 鬼知道這些陰險的函數(shù)會不會到處散播副作用 ... 還是只做一件事，最后把他們黏連起來使用比較好。

還有我不認(rèn)為性能上有很大差距 也許一個函數(shù)只干一件事性能還會更好。

第一段代碼相比第二段的一個明顯特點(diǎn)就是 每個函數(shù)的平均行數(shù)少了，第二個平均行數(shù)比較多。

維護(hù)編寫短小的代碼心智負(fù)擔(dān)比較小 從而維護(hù)編寫的效率高

只做一件事意味著 這個函數(shù)只要能做完這件事就可以了， 你可以輕而易舉地用別的算法實(shí)現(xiàn)的這個函數(shù)的副本直接替換。

由于編寫了眾多短小精悍的小函數(shù)，組裝的時候抽象層次會高一些，更符合思考。

如果是為了復(fù)用、擴(kuò)展的話 第一次寫的時候就這樣做的真的不是提前優(yōu)化嗎

為了復(fù)用、為了拓展從來都不是 提前優(yōu)化，相反，更應(yīng)該重視這兩個

你說得沒錯。就是為了可讀性、擴(kuò)展性、和復(fù)用。最主要還是可讀性/可維護(hù)性。干多件事情的函數(shù)你都沒法起名呢，更別說讓別人理解了。

過早優(yōu)化是這個：「一個函數(shù)就占內(nèi)存的一些空間呢」。