Refactoring du code et de l'historique Git !

Pour l'atelier de cette semaine, nous sommes censés refactoriser et améliorer AU MOINS 3 éléments de mon code pour améliorer la structure, la lisibilité, la modularité et la maintenabilité du code. Et on nous présente git rebase pour modifier l'historique des commits git (reformulation, écrasement, suppression, etc.).

Code de refactorisation

J'ai été assez diligent pour garder la base de code propre. Ce que j'ai appris au cours de mon travail dans divers groupes, projets personnels et ma dernière coopérative, c'est que la dette technologique est une chose réelle et elle continue de s'accumuler encore et encore jusqu'à un certain point où votre seul choix est soit de consacrer un sprint à refactoriser la base de code entière ou simplement l'ignorer. Ainsi, depuis le début, j'ai extrait des fonctionnalités dans des fonctions distinctes de mon répertoire util pour n'avoir AUCUNE duplication de code. Utiliser un appel de méthode en ligne au lieu de déclarer des variables si je n'en ai pas besoin plus d'une fois et utiliser des noms de variables très descriptifs (personne n'aime les noms de variables à une seule lettre). Donc, je n’avais pas grand-chose à refactoriser à première vue. En plus de cela, c'était mon dernier PR avec le titre Major Refactoring pour plus de cohérence la semaine dernière, où j'ai corrigé de nombreuses erreurs syntaxiques et quelques mises à jour Lisez-moi. Donc j'ai fait en quelque sorte une chose sur trois avant l'annonce du laboratoire mdr. Mais une chose que je n’aimais pas, c’était à quel point mon index.js devenait gonflé. Je l'ai examiné et j'ai pensé que je pourrais extraire une partie de la logique de ses méthodes dédiées pour que le fichier reste léger. J'ai donc créé deux nouvelles méthodes utilitaires. ExtractOptions.js pour extraire toutes les options des options ou de la configuration toml et ResponsePresenter.js avec la seule responsabilité d'imprimer sur la console et d'écrire dans le fichier en fonction des options. C'est donc ce que j'ai fait. conduisant à index.js ayant 46 lignes remplacées par sept.

Refactoriser l'historique de Git

Après avoir travaillé sur une branche distincte et rebasé pour avoir un seul commit, je l'ai fusionné sur main. Mais je n’ai pas aimé la façon dont était mon historique sur le dépôt principal. Comme vous pouvez le voir ci-dessous, les commits du 26 septembre ne sont pas ce que je souhaite.

Donc, en utilisant rebase, j'ai écrasé et renommé le commit pour avoir un historique plus linéaire. Depuis que j'ai de l'expérience avec rebase interactive, c'était assez simple. Ayant commis le péché capital de changer l'historique de git sur main, j'ai dû faire un push forcé vers distant pour mettre à jour le dépôt principal avec toutes les modifications. Maintenant, ça ressemble exactement à ce que je veux.

J'aurais préféré avoir tous les commits sur la branche principale uniquement au fur et à mesure que PR squash fusionne, ce qui garde les choses simples et propres. Personnellement, je ne suis PAS fan de travailler localement sur le dépôt principal.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!