Dans cet article, je vais aborder la question du seuil d'entrée dans un projet avec une architecture établie et donner plusieurs options pour répondre à une question très souvent posée: pourquoi est-ce si difficile?
Cette question se pose souvent chez les nouveaux arrivants qui viennent au projet. Ou il y a des situations où le projet entre en support et développement entre de nouvelles mains, et le nouveau développeur a également cette question. Et rarement, l'un d'eux essaie de comprendre les vraies raisons pour lesquelles il en est ainsi ici et non autrement. Cela peut entraîner de tristes conséquences pour l'entreprise, par exemple, un nouveau développeur peut insister pour réécrire l'intégralité de l'application à partir de zéro.
Pour minimiser ces risques, au lieu de demander pourquoi c'est si difficile? poser de telles questions:
- Quelles exigences pour le processus de développement ont été définies par l'architecte?
- Quel est le résultat du processus de développement requis en sortie?
Exigences du processus de développement
Tout d'abord, le développeur doit se plonger dans le système du processus de développement, il doit poser la question suivante:
- Sur quel système s'appuie le processus?
Souvent dans le développement personnalisé, un projet avec des exigences sans ambiguïté et un ensemble fixe de fonctionnalités vient à l'entrée. À quel point ils peuvent être bien développés - c'est le sujet d'un autre article. Et le processus de développement dans de tels projets est le plus souvent construit selon un système en cascade, car il implique un retour direct des utilisateurs du produit - après le développement de toutes les fonctionnalités du produit , alors qu'avec un modèle itératif, le retour peut être obtenu après la première itération. Pour de tels projets, l'architecte a généralement déjà une architecture établie qui répond à certaines exigences de ce processus. Quelles sont les exigences d'un tel processus de développement posées par l'architecte?
1) Le processus de développement du pipeline doit être aussi complexe que possible pour le développeur. Et le rejet du code entrant dans le référentiel du projet devrait se produire au maximum automatiquement et, si possible, sans la participation de l'architecte lui-même.
C'est-à-dire un pipeline spécifique doit être configuré dans le processus. Le code qui a traversé tout ce pipeline est considéré comme satisfaisant. Ceci est très important car un bon architecte doit sauver ses développeurs du mal de tête et de la responsabilité de ne pas travailler l'assembly après que le code soit entré dans le référentiel. S'il n'y a pas un tel pipeline , vos développeurs souffriront d'un stress constant. Si le code est entré dans le référentiel et que le pipeline l'a accepté, et que ce code a cassé l'assembly ou endommagé des fonctionnalités déjà opérationnelles - c'est déjà un problème du pipeline lui-même.
Par conséquent, dans un tel pipeline, vous devez utiliser:
- De nombreux analyseurs de code statique
- Tests automatisés et tests de conformité pyramidaux
- Calcul automatique de la couverture du code par des tests
- La passerelle vers la qualité du code (Quality gates). Pour toutes sortes de métriques: pourcentage de couverture de code avec tests, pourcentage de duplication de code, odeurs de code, sécurité, bugs, etc.
- examen croisé des codes
- etc.
Tous ces points réunis conduisent à la question du développeur: pourquoi est-ce si difficile?
Par exemple, essayez d'écrire des tests pour ce code:
class SomeService( private val restApi: SomeApi
Vous devrez exécuter ces tests sur un véritable appareil Android ou sur un émulateur. Et cela entraînera immédiatement une réduction significative de la deuxième exigence du processus de développement:
2) Les éléments de pipeline automatisés et le processus de développement doivent être effectués aussi rapidement que possible
Si vos développeurs doivent attendre longtemps pour que les tests soient terminés - c'est le problème de votre pipeline et si l'architecture ne permet pas d'accélérer ce processus - c'est le problème de votre architecture
Réécrivons l'exemple:
interface SomeApi { fun loadSomething(): Single<NetworkResult> } class NetworkSomeApi : SomeApi { override fun loadSomething(): Single<NetworkResult> { } } class SomeService( private val restApi: SomeApi
Nous voyons que la complexité du code a augmenté, mais du point de vue du processus de développement - nous avons rendu l'architecture plus flexible, maintenant nous n'avons plus à exécuter des tests de logique métier pour le bloc de map dans l'émulateur ou sur l'appareil, il suffit de les exécuter dans des tests rapides. Cela réduira le nombre de tests d'intégration qui doivent être exécutés dans un environnement lent.
Le modèle de conception choisi par l'architecte peut réduire le nombre de tests d'intégration coûteux. Ne soyez pas paresseux et traitez avec les modèles qui sont populaires aujourd'hui: MVP , MVVM , MVI .
Parlons un peu plus de la navigation dans l'application. Nous voulons également pouvoir le tester et le tester dans des tests rapides. Encore une fois, nous obtenons une «complication» de l'architecture, car nous devons cacher le système de navigation dans l'application derrière l'abstraction.
Et nous voulons également pouvoir connecter les composants de notre système à l'aide de DI, construire des graphiques de dépendance et vérifier leur exactitude au stade de la compilation du projet, et non au moment de l'exécution. Puis Dagger 2 et ses composants et sous-composants monstrueux avec des modules apparaissent sur la scène, ce qui déroute déjà le pauvre débutant à la fin.
Et de tels moments non évidents de "complication" de l'architecture pour les débutants s'accumulent beaucoup. Naturellement, sans comprendre les processus de développement et les exigences de ces processus, ils ont la même question - pourquoi est-ce si difficile?
Résultat du processus de développement
Pour évaluer le succès du processus de développement intégré et, indirectement, l'architecture du projet, il est nécessaire d'analyser son résultat. En règle générale, le résultat est un produit (une application si nous parlons de développement mobile). Et les mesures de réussite du produit sont différentes pour chacun: le client a les mêmes mesures, le développeur a ses propres mesures, l'utilisateur du produit a les leurs.
Au minimum, vous, en tant qu'architecte qui crée le pipeline pour le processus de développement, devez prendre en compte lors de l'évaluation de l'efficacité du processus de développement des mesures de votre entreprise et des mesures commerciales.
Il s'agit d'un processus en cours: développement -> collecte de métriques -> analyse du résultat -> apport des modifications nécessaires au processus de développement.
Ainsi, le résultat affecte la formation du processus de développement et le processus de développement affecte déjà le changement dans l'architecture du projet. C'est-à-dire L'idée importante que je veux transmettre est que l' architecture est secondaire, le résultat principal et le processus de développement .
Conclusion
En conclusion, disons encore:
- sans comprendre les processus de développement et les exigences de ces processus, le développeur crée un sentiment sur l'architecture compliquée du projet;
- l'architecture est secondaire, résultat primaire et processus de développement;
Sans une compréhension de ces choses, un développeur peut vouloir tout prendre et réécrire à partir de zéro. À mon avis, cela n'est justifié que lorsque le processus de développement et le résultat ne satisfont pas complètement le client de ce développement.
Pour les débutants, je vous conseille de vous lancer dans un projet avec un pipeline de développement raffiné. Le seuil d'entrée dans de tels projets est élevé, mais en le franchissant, vous aborderez sérieusement la compréhension de la façon dont les processus de développement sont construits.