↪️ 😱 ♍️ Nous vendons le Refactoring d'Architecture à un client ou quel est le problème des développeurs 😫 🧖 🥦

Le refactoring architectural ou design est toujours un problème douloureux sur un projet. Les avantages du refactoring sont évidents pour nous, spécialistes techniques, mais il est souvent difficile pour le client de vendre et de justifier cette idée. La raison principale est que nous, les spécialistes techniques, ne savons pas comment parler avec les entreprises.

Le principal problème est la communication entre les techniciens et les gens qui font de l'argent. Ils parlent des langues différentes, bien qu'ils essaient de résoudre les mêmes problèmes.

Cet article est une traduction de l'original de l'anglais: Refactoring d'architecture et Refactoring de conception Comment le vendre client . Si vous avez des collègues qui ne parlent pas russe, ils peuvent lire l'original sur mon bulg.

Les avantages du refactoring sont évidents pour tous les professionnels techniques, mais souvent nous ne pouvons pas transmettre cette idée à l'entreprise. Pourquoi cela arrive-t-il? Nous sautons quelques étapes mineures mais très importantes pour l'entreprise.

Nous divisons l'ensemble du processus en 6 étapes simples mais nécessaires:

Déterminez la cause du problème.
Décidez quels changements doivent être apportés.
Justification de la décision
Faire un plan de refactoring
Créer une feuille de route
Présentez votre décision

Trouvez la cause du problème

Cette étape nous est assez familière en tant que spécialistes techniques. Considérez-le avec de vrais exemples.

La build se bloque après presque chaque commit.

Plusieurs raisons peuvent expliquer cela:

Les composants d'application sont étroitement liés et dépendent les uns des autres
Les composants d'application ne sont pas correctement isolés
Absence de tests unitaires
Manque de processus SDLC et CI / CD

Un autre exemple. Le déploiement d'applications prend beaucoup de temps et des problèmes de performances sont également observés.

Les raisons principales peuvent être:

Une application monolithique se développe rapidement et est devenue trop volumineuse pour une application
L'application est volumineuse et consomme beaucoup de RAM et de puissance processeur.
La demande est complexe et mal écrite

Décidez quels changements doivent être apportés.

La prochaine étape est un peu plus compliquée, mais toujours familière et simple pour les développeurs seniors +. Nous sommes tous de bons experts techniques et savons toujours ce qui doit être amélioré. Et en ce moment, nous faisons une erreur et courons vers le client avec les mots, faisons-le .

Mais nous sommes des architectes intelligents et nous suivrons pas à pas notre plan de 6 étapes.

Sur la base de l'exemple précédent avec une application monolithique, les solutions sont évidentes. Divisez une grande application complexe en modules plus petits et indépendants. Ce sont les premières étapes d'une architecture orientée services ou microservices.

Justification de la décision

Nous diviserons cette étape en deux phases: justification technique et justification commerciale .

La logique technique nous semble logique. Divisez le monolithe en services plus petits, ce qui nous permet d'obtenir:

Composants plus disparates
Les problèmes de construction ne seront pas si fréquents
Les petits services consomment moins de RAM et de puissance de processeur, par conséquent - de meilleures performances
Des services séparés peuvent être déployés plus rapidement et indépendamment les uns des autres

La justification d'un point de vue commercial est une étape très importante que les experts techniques oublient souvent. Vous devez vous rappeler ce qui est important pour les affaires. C'est vrai - c'est de l'argent .

En bref: si le refactoring ne profite pas à l'entreprise - cela n'a aucun sens de le faire.

Sur la base de notre exemple, vous pouvez offrir au client les avantages suivants:

De nouvelles fonctionnalités seront développées plus rapidement
La qualité de l'application sera meilleure, en raison de la baisse des coûts de correction de bogues et de la satisfaction de l'utilisateur de l'application, ce qui affecte également positivement l'entreprise.
Coûts de développement et de déploiement réduits
Il est plus facile de trouver des professionnels motivés et expérimentés qui sont prêts à travailler avec le projet.

Plan de refactoring

Le plan doit être clair et détaillé. Chaque itération doit être clairement décrite et toutes les modifications architecturales et de conception doivent être documentées.

Créez votre plan, vous devez répondre aux questions suivantes:

Quel est le but de cette itération?
Quelle est la valeur technique et commerciale de cette itération?
Comment raccourcir le temps d'itération?

Feuille de route

Une étape très importante . Prenez le temps de le faire si vous voulez vraiment vendre du refactoring à une entreprise.

Chaque manager et homme d'affaires veut connaître les réponses à deux questions:

Combien ça coûte?
Combien de temps cela prendra-t-il?

Essayez de diviser le refactoring en petites itérations. Chaque itération doit apporter une valeur technique et commerciale. Il est assez difficile de vendre du refactoring pendant des années et de coûter des millions de dollars sans résultats intermédiaires.

Chaque itération doit contenir des informations sur la durée et le nombre de spécialistes nécessaires pour cela. Ces informations aideront le gestionnaire à répondre à deux questions fondamentales posées un peu plus haut.

Collectez les métriques du projet avant et après refactoring à chaque itération. Cela vous aidera à montrer la valeur technique et commerciale apportée par cette itération.

Je présente ma décision

Avant de rendre votre décision à l'entreprise, vérifiez-la avec votre supérieur immédiat. Une vue latérale est toujours bonne, surtout si c'est une vue latérale commerciale. Peut-être que votre gestionnaire a plus de contexte et vous aidera à modifier le plan en fonction des attentes de l'entreprise.

Vous devez savoir comment répondre à la question classique.

Habituellement, lorsque vous présentez une refactorisation architecturale, une entreprise peut demander. Pourquoi avons-nous besoin de refactoring? L'année dernière, nous avons dépensé assez d'argent pour l'architecture et nous avons à nouveau des problèmes.

Il existe une réponse classique à la question classique. Cette solution architecturale était bonne il y a un an, mais les affaires grandissent et changent, et l'architecture doit évoluer avec elle.

Astuce numéro 2. Ne paniquez pas votre client. Fournissez des informations comme urgentes, mais pas comme une catastrophe. Disons que vous avez six mois pour refactoriser, mais vous devez commencer dès aujourd'hui.

Enfin . Lorsque vous présentez votre décision, essayez d'éduquer les gens, pas de blâmer. N'oubliez pas qu'en blâmant les gens, vous rencontrerez une résistance de leur part. Vous devriez chercher des moyens de résoudre les problèmes, pas les coupables.

finalement

Le refactoring est coûteux et difficile à vendre aux entreprises
Le refactoring architectural n'est pas seulement un problème technique, il doit encore être vendu à une entreprise
N'oubliez pas les avantages de la refactorisation de votre entreprise.
Il est toujours plus facile de vendre un petit refactoring, mais souvent plus grand, mais une fois

Vous pouvez trouver plus d'articles sur l'architecture et les compétences générales en architecture sur la ressource d'origine.

Bon refactoring à tout le monde!

Nous vendons le Refactoring d'Architecture à un client ou quel est le problème des développeurs