$scope.del = function () { var delItemId = getDelId(); // 要删除的项目的身份标识 // 如果没选择删除项 if (!delItemId.length) { $promptLayer.show({ str: $message.delItemIsEmpty }); return; } delTarArr = delItemId; $weuiAndroidDialog2.show($message.store.delConfirm, $message.store.delCloseBtn, $message.store.delOkBtn); }; // 确认删除 $rootScope.$on('androidDialog2Btn1', function () { del( delTarArr.join(',') ); $weuiAndroidDialog2.hide(); }); // 取消删除 $rootScope.$on('androidDialog2Btn0', function () { $weuiAndroidDialog2.hide(); }); var delTarArr; // 获取要删除项标识 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; // 当前所在页数 // 此页删空 跳上一页 if (delNum === totalNum) curPage = curPage - 1; $scope.loadList(curPage); $scope.pageControlCurNum = curPage; }ou
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; } // 再次确认提示层 $weuiAndroidDialog2.show($message.store.delConfirm, $message.store.delCloseBtn, $message.store.delOkBtn); }; // 确认删除 $rootScope.$on('androidDialog2Btn1', function () { // 请求删除接口 $handler.store.del( delTarArr.join(',') ).then(function () { // 删空跳页 var curPage = $scope.pageControlCurNum; // 当前所在页数 // 此页删空 跳上一页 if (delTarArr.length === $scope.selectAllItem.length) curPage = curPage - 1; $scope.loadList(curPage); $scope.pageControlCurNum = curPage; }); $weuiAndroidDialog2.hide(); }); // 取消删除 $rootScope.$on('androidDialog2Btn0', function () { $weuiAndroidDialog2.hide(); });Lequel de ces deux morceaux de code est le meilleur... Bien que les deux soient plutôt salauds, voyons comment vous les gérez
Une fonction ne peut faire qu'une seule chose. Pourquoi est-elle si lisible ? Évolutivité ? Réutilisabilité ? À mon avis, déclarer une fonction n'est pas gratuit. Une fonction ne prend que de l'espace en mémoire. L'appel de la fonction est plus rapide sans analyse directe~
.S'il s'agit de réutilisation et d'expansion, n'est-ce pas vraiment une optimisation à l'avance de faire cela lors de la première écriture ? Les besoins futurs ne peuvent pas être déterminés de cette façon ? le regarder n'est certainement pas la meilleure pratique de performance ~
L’optimisation précoce/de transition n’est-elle pas la racine de tous les maux ? ~
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
En ce qui concerne une classe, il ne devrait y avoir qu'une seule raison pour son changement. En JavaScript, il n'existe pas beaucoup de scénarios nécessitant l'utilisation de classes. Le principe de responsabilité unique est plus souvent appliqué au niveau de l'objet ou de la méthode, notre discussion dans cette section est donc principalement basée sur les objets et les méthodes.
La responsabilité dans le principe de responsabilité unique (SRP) est définie comme « la cause du changement ». Si nous avons deux motivations pour remplacer une méthode, alors cette méthode a deux responsabilités. Chaque responsabilité est un axe de changement. Si une méthode assume trop de responsabilités, il est plus probable qu'elle doive être réécrite à mesure que les exigences évoluent.
À l'heure actuelle, cette méthode est généralement une méthode instable, et modifier le code est toujours une chose dangereuse, surtout lorsque deux responsabilités sont couplées, les changements dans une responsabilité peuvent affecter la mise en œuvre d'autres responsabilités, provoquant des dommages inattendus,
Ce couplage il en résulte une faible cohésion et une conception fragile.
Par conséquent, le principe SRP s'incarne comme suit : un objet (une méthode) ne fait qu'une seule chose.
Permettez-moi de parler de mon opinion personnelle. Les programmes sont destinés à être lus par les gens. Plus la complexité d'une fonction est élevée, plus le coût de sa lecture est élevé. Même si vous écrivez un programme, cela peut prendre un certain temps pour en comprendre le sens quelques mois plus tard, sans compter que d'autres pourraient reprendre votre code !
Laissez d'abord les gens comprendre le programme, puis parlez de l'optimisation des performances de course
Si votre code ne doit être utilisé que pendant une courte période, n'a pas besoin d'être itéré plus tard, n'a pas besoin d'être fourni à d'autres collègues et n'a pas besoin de tests unitaires, alors écrivez-le simplement avec désinvolture et implémentez la fonction.
Si votre code doit être appelé par d'autres collègues, il doit être itéré, étendu et testé unitairement. Ensuite, suivez simplement les spécifications. Les performances ne sont jamais déterminées par la forme du code.
Le moyen le plus simple est que si vous examinez votre code après un mois et que vous avez du mal à le lire, à le maintenir et à le développer, refactorisez-le.
Je pense qu'il vaut mieux qu'une fonction ne fasse qu'une seule chose... Qui sait si ces fonctions insidieuses propageront des effets secondaires partout...
Il vaut mieux ne faire qu'une seule chose et enfin les connecter ensemble pour les utiliser.
De plus, je ne pense pas qu'il y ait une grande différence de performances. Peut-être qu'une fonction qui ne fait qu'une seule chose fonctionnera mieux.
Une caractéristique évidente du premier morceau de code par rapport au deuxième morceau de code est que le nombre moyen de lignes par fonction est inférieur, tandis que le nombre moyen de lignes du deuxième morceau est supérieur.
La charge mentale liée à la maintenance et à l'écriture de codes courts est relativement faible, donc l'efficacité de la maintenance et de l'écriture est élevée
Ne faire qu'une chose signifie que cette fonction n'a besoin que de pouvoir accomplir cette tâche, et vous pouvez facilement la remplacer directement par une copie de cette fonction implémentée par un autre algorithme.
En raison de l'écriture de nombreuses petites fonctions courtes et concises, le niveau d'abstraction sera plus élevé lors de l'assemblage, ce qui est plus adapté à la réflexion.
Pour la réutilisation et l'expansion ne sont jamais
提前优化, au contraire, nous devrions prêter plus d'attention à ces deux-làVous avez raison. C’est pour la lisibilité, l’évolutivité et la réutilisation. La chose la plus importante est la lisibilité/maintenabilité. Vous ne pouvez même pas nommer une fonction qui fait plusieurs choses, encore moins la faire comprendre aux autres.
L'optimisation prématurée est la suivante : "Une fonction prend de la place dans la mémoire."