De nombreux développeurs de notre équipe évitent le refactoring. La discussion de cette situation a révélé les raisons suivantes.
Pourquoi beaucoup ne refactorisent pas
effrayant de briser les fonctionnalités existantes
prend du temps: si le code que vous refactorisez change, la fusion (plusieurs fois) à partir de la branche principale devient une douleur
il y a un risque de ne pas être à temps pour l'échéance de la tâche
Dans le même temps, la refactorisation fait presque partie intégrante du processus de développement. Son besoin est associé aux prérequis suivants:
les exigences initiales ne sont presque jamais complètes et le développement est effectué conformément à certaines hypothèses, dont certaines s'avèrent par la suite incorrectes ou inexactes
vous avez souvent besoin de faire des modifications rapides pour le faire fonctionner ici et maintenant, sans envisager une assistance supplémentaire
Lorsque le refactoring est justifié (nécessaire)
Je vois les raisons suivantes pour changer la structure du code:
code en double
Il y a peu de raisons d'avoir du code en double, le plus souvent, vous devez vous en débarrasser
universalisation
Pour faciliter la compréhension de votre code et réduire les problèmes opérationnels, vous pouvez souvent créer une abstraction qui combine un code similaire. Il est important d'avoir au moins 3 prototypes pour cette abstraction, sinon elle risque de ne pas être exacte.
, GooglePay. , ApplePay SamsungPay . VendorPay
,
/
, 50 500 ,
: , , .
, . , , , , . , () , .
?
, , :
(unit )
-
, -
feature- master' .
, , , . , , , . , , .
- (- + ) , , ( master'), - - .
, master rebase - master.
Cette approche entraîne des frais généraux, mais atténue les principales difficultés de refactoring:
revoir et fusionner le refactoring n'est pas si effrayant, car il n'apporte fondamentalement pas de changements fonctionnels, ou ces changements fonctionnels sont clairement visibles dans une petite demande d'extraction
il n'est pas nécessaire de prendre en charge les modifications des autres développeurs car les modifications sont fusionnées dans la branche principale presque immédiatement
dans le cas où les délais sont maintenus, vous pouvez arrêter de refactoriser après le cycle de deux à trois jours suivant