Cette fois, j'ai résumé mes réflexions sur la façon d'écrire un meilleur code. Puisqu'il est prévu d'être sérialisé, seule une petite partie sera introduite cette fois.
Il n'y a pas de réponse correcte à 100% dans le codage. Nous vous présenterons autant que possible les avantages / inconvénients, il vaut donc mieux les utiliser correctement en fonction de l'heure et du cas.
En outre, cet article suppose "un système qui continuera à être maintenu et maintenu à l'avenir". Il n'est pas recommandé pour les «systèmes qui mettent l'accent sur la quantité de code et la vitesse de codage, même si cela est un peu difficile à comprendre pour les autres».
Lorsqu'un nouvel ingénieur se présente, il a cette idée.
N'ayez pas peur de mal comprendre cela, vous devriez arrêter.
Je compléterai de ceux qui disent "Je vais vous montrer une méthode de traitement que les seniors et tout le monde ne connaissent pas". Nous vous invitons à intégrer les nouvelles technologies. Cependant, ce que j'aimerais que vous pensiez en tant qu'ensemble, c'est le partage d'informations et l'éducation pour les autres membres. Je suis heureux que la personne grandisse régulièrement, mais c'est mauvais pour l'organisation que personne ne puisse revoir le code. La personne qui s'ouvre et la personne qui éduque ne doivent pas nécessairement être la même personne, mais assurez-vous de le faire par paires.
Pour ceux qui veulent "surprendre avec un algorithme génial auquel je suis le seul à pouvoir penser", ne le faites pas si personne d'autre ne comprend votre code. "Hmm, je ne sais pas ce que c'est, mais M. ●● le fait, et le résultat est correct, n'est-ce pas?" Ce n'est pas bon en tant qu'organisation. Même s'il est un peu long ou un peu de gaspillage de ressources, «un code facile à maintenir» doit être priorisé. À titre indicatif, environ 80% des membres peuvent le comprendre en regardant le code et en réfléchissant un peu. Bien sûr, mettons l'éducation entre les 20% restants.
Avant correction
public class Item {
//ID d'article unique
private int id;
//Nom de l'article
private String name;
}
//Effacer l'article
public void deleteItem(Item item) {
//Supprimer le processus
}
Le code ci-dessus suppose le processus de réception de l'ID de clé du navigateur et de sa suppression car des données sont déjà enregistrées dans la base de données. De quoi avez-vous généralement besoin pour effectuer le processus de suppression? Oui, il suffit de n'avoir qu'un "id" qui indique de manière unique ce qu'il faut supprimer. Cependant, dans l'exemple ci-dessus, non seulement l'id est passé à la méthode, mais il est passé en tant qu'objet Item.
Si vous souhaitez utiliser ce deleteItem () ailleurs dans le futur, vous devez vous donner la peine de passer l'objet Item comme nouveau. À ce moment-là, dois-je entrer une valeur pour le nom? Si vous le passez comme nul parce que vous ne l'utilisez pas, utiliserez-vous accidentellement le nom nul dans les améliorations futures? Il y a beaucoup de choses à considérer.
modifié
public class Item {
//ID d'article unique
private int id;
//Nom de l'article
private String name;
}
//Effacer l'article
public void deleteItem(int id) {
//Supprimer le processus
}
En faisant cela, il est évident que "Oh, juste l'id suffit pour le processus de suppression", et il sera plus facile à réutiliser.
Cependant, supposons que dans une amélioration future, "je veux ajouter une fonction d'historique de suppression, donc j'ai besoin de la valeur de nom lors de la suppression pour que je puisse voir ce que j'ai supprimé!". Cela changera l'interface de deleteItem () et nécessitera une modification et un test de tous les appelants. Si vous saviez qu'il y avait de telles améliorations, il peut être judicieux de passer la classe Item.
De plus, si le nombre d'arguments est très grand, vous pouvez choisir de transmettre chaque objet Item en mettant l'accent sur la lisibilité, après l'avoir évalué par rapport à une réutilisation réduite.
Pièces faciles à réutiliser Facile à comprendre quels paramètres sont nécessaires pour le traitement
Si un correctif est prévu, tous les points d'utilisation devront être corrigés et retestés.
Avant correction
function jumpToEditPage() {
var urlStr = (isCreate) ? "Create" : "Edit"
var url = "https://www.hoge.com/item" + urlStr;
location.href = url;
}
Il s'agit du code javascript lors de la transition vers l'écran du formulaire de saisie. Supposons que vous vouliez voir certaines conditions et changer l'écran avec l'url "itemCreate" pour une nouvelle inscription et "itemEdit" pour l'édition. Dans ce code, afin de le rendre aussi commun que possible, la branche est générée uniquement par les différentes chaînes de caractères "Créer" et "Editer".
Au fait, dites-vous: "Parce que le service est terminé, supprimons le programme après avoir confirmé que cet écran n'apparaît de nulle part"? À ce moment-là, comment confirmez-vous que "cet écran n'apparaît pas"?
Souhaitez-vous rechercher du HTML avec les chaînes "itemCreate" et "itemEdit"?
Dans ce cas, cette façon d'écrire ne sera pas prise dans la recherche. Même si certaines personnes ont remarqué: "Oh, vous ne pouvez pas vous faire prendre ici tel quel, alors soyez prudent lorsque vous cherchez!" Ça pourrait être quelque chose comme ça.
modifié
function jumpToEditPage() {
var urlStr = (isCreate) ? "itemCreate" : "itemEdit"
var url = "https://www.hoge.com/" + urlStr;
location.href = url;
}
Même s'il se branche, il semble plus facile à maintenir s'il est organisé dans cette unité.
Facile à maintenir
Je pense que c'est presque inexistant
Avant correction
public boolean test(){
if(A == a){
if(B != b){
if(C == c){
return true;
}
}
}
return false;
}
Dans cet exemple, il y a 3 couches, mais si cela devient 10 couches et que l'expression conditionnelle devient longue, elle sera plus incontrôlable. De plus, s'il est en retrait vers la droite, des sauts de ligne se produiront, ce qui peut réduire la lisibilité.
modifié
public boolean test(){
if(A != a){
return false;
}
if(B == b){
return false;
}
if(C != c){
return false;
}
return true;
}
comment c'est? En japonais, avant la correction, il est lu comme suit: «C'est ça, et c'est vrai en ce moment». C'est une image à juger en stockant toutes les conditions dans le buffer. Après la correction, il est lu comme suit: "C'est le cas en ce moment. C'est le cas en ce moment. C'est le cas en ce moment. A part ça, c'est le cas." En traitant chaque condition dans l'ordre, cela ressemble à un code facile à comprendre. De plus, la hiérarchie n'est pas profonde et la lisibilité est peu susceptible de diminuer.
La détérioration de la lisibilité est supprimée
Cela peut être difficile pour ceux qui n'ont pas l'habitude de le lire.
Cette fois, c'est fini. Je vais également résumer dans une perspective similaire.
Recommended Posts