1. Qu’est-ce que la reconstruction ?
Définition : Un ajustement de la structure interne d'un logiciel dans le but d'améliorer sa compréhensibilité et de réduire les coûts de modification sans modifier le comportement observable du logiciel.
Le but du refactoring est de rendre le logiciel plus facile à comprendre et à modifier. De nombreuses modifications peuvent être apportées au sein du logiciel, entraînant peu ou pas de changement dans le comportement externe observable du logiciel. Aucun utilisateur, ni aucun autre programme, ne se rend compte que quelque chose a changé.
Deux casquettes : refactoriser et ajouter de nouvelles fonctionnalités. Vous ne pouvez pas faire les deux en même temps.
2. Pourquoi refactoriser
La refactorisation améliore la conception des logiciels . Une refactorisation fréquente peut aider le code à conserver la forme qu'il devrait avoir. Les mauvais programmes nécessitent souvent la conception de plus de code, souvent parce que le code utilise exactement la même instruction à différents endroits pour faire la même chose. Une direction importante pour améliorer la conception est donc d' éliminer le code en double . Sinon, lors de la modification du code, vous risquez d'oublier de modifier un autre code et cela ne fonctionnera pas comme prévu.
La refactorisation rend les logiciels plus faciles à comprendre . Apporter les modifications appropriées au code peut permettre à la deuxième personne de comprendre votre code plus rapidement et de le rendre plus lisible. Je peux également utiliser le refactoring pour aider à comprendre un code inconnu.
La refactorisation aide à trouver les bugs . Comprendre le code peut aider à trouver des bugs. Lors de la refactorisation, vous pouvez comprendre en profondeur le comportement du code et renvoyer la nouvelle compréhension de manière appropriée.
La refactorisation améliore la vitesse de programmation . Une bonne conception est fondamentale pour un développement rapide. Sinon, vous passerez beaucoup de temps à déboguer, incapable d'ajouter de nouvelles fonctionnalités et devrez ajouter de nombreux correctifs au programme, et les nouvelles fonctionnalités nécessitent plus de code à implémenter.
3. Quand refactoriser
Soyez opposé à réserver du temps spécifiquement pour la refactorisation. Les choses ne peuvent se produire que trois fois, trois reconstructions.
Refactorisez à mesure que la fonctionnalité est ajoutée.
Refactoriser lors de la correction des erreurs. Si vous recevez un rapport d'erreur, cela signifie que le code n'est pas assez clair et que le bug n'est pas visible d'un seul coup d'œil, il doit donc être refactorisé.
Refactoriser lors de la révision du code . La refactorisation peut aider à réviser le code d'autres personnes.
4. Que dire au manager
Ne le dites pas au directeur. Une expérience basée sur un calendrier veut que je fasse les choses le plus rapidement possible. La façon dont je le fais dépend de moi, et la refactorisation me permet d'accélérer ma programmation.
La plupart des refactorisations introduisent davantage de couches d'indirection dans le programme . La refactorisation divise souvent les gros objets en plusieurs petits objets et les grandes fonctions en plusieurs petites fonctions. Trop de niveaux d’indirection peuvent rendre la compréhension difficile.
Cependant, la couche indirecte permet le partage logique , sépare l'interprétation de l'intention et de la mise en œuvre , isole les modifications ( si le même objet est utilisé à plusieurs endroits, la couche indirecte n'a besoin de modifier qu'un seul endroit ) et encapsule la logique conditionnelle.
5. Problèmes de refactorisation
base de données
Modifier l'interface. De nombreuses techniques de refactoring modifient l'interface. Si l'interface a été publiée, vous devez conserver à la fois l'ancienne et la nouvelle interface. La meilleure façon est de laisser l' ancienne interface appeler la nouvelle interface . Une autre approche consiste à ne pas publier l'interface prématurément .
Conception et modifications difficiles à réaliser grâce aux techniques de refactoring . Par exemple, il est difficile de reconstruire un système qui a été construit sans tenir compte des exigences de sécurité pour en faire un système offrant une bonne sécurité. À l’heure actuelle, imaginez d’abord la situation de la reconstruction et à quel point elle est difficile. Si cela semble simple, le design le plus simple sera choisi, même s'il ne couvre pas tous les besoins potentiels. Si vous ne voyez pas la solution de facilité dès le départ, vous consacrerez plus d’efforts à la conception.
Quand ne pas refactoriser . Le code est trop déroutant, il vaut donc mieux le réécrire . Un compromis consiste à reconditionner de gros logiciels en petits composants, puis à prendre des décisions concernant la refactorisation ou la réécriture des petits composants un par un . Le projet est proche de ddl .
6. Refactorisation et conception
La refactorisation et la conception se complètent.
7. Reconstruction et performance
Pour rendre le logiciel plus facile à comprendre, des modifications sont souvent apportées qui ralentissent le programme mais facilitent l'optimisation. Le secret pour écrire un logiciel rapide est donc le suivant : écrivez d’abord un logiciel réglable, puis réglez-le pour obtenir une vitesse suffisante .
Il existe trois façons d'écrire des logiciels rapides.
Méthode de budgétisation du temps . Convient aux systèmes temps réel avec des exigences de performances extrêmement élevées. Cette méthode pré-allouera certaines ressources à chaque composant, y compris le temps et les traces d'exécution, et chaque composant ne sera jamais autorisé à dépasser son propre budget.
Continuez à faire attention à la loi . Quoi que vous fassiez, essayez de maintenir le système performant. Cette approche est courante et attrayante, mais elle ne fera pas grand-chose. Étant donné que 90 % du travail d’optimisation est vain, la plupart du code optimisé est rarement exécuté.
Exploitez 90 % des statistiques . Lorsque vous écrivez un programme, ne prêtez pas une attention continue aux performances jusqu'à ce que vous entriez dans la phase d'optimisation des performances, généralement tard dans le développement. À ce stade, les performances du programme sont ajustées en fonction d'un programme spécifique.
Au cours de la phase d'optimisation des performances, vous devez trouver une petite section de code où se trouvent les points chauds de performances, puis vous concentrer sur ces points chauds de performances et utiliser les méthodes d'optimisation de la méthode d'attention continue pour les optimiser, afin que vous puissiez obtenir des résultats significatifs. des résultats avec moins de travail. . Cependant, de petites modifications doivent encore être apportées et chaque étape doit être compilée, testée et mesurée à nouveau. Si les performances ne s'améliorent pas, annulez cette modification.