Au lieu de parler d'une technologie spécifique ou d'un projet spécifique, dans cet article je parlerai de architecture logicielle et des erreurs évitables.
Il serait beaucoup plus facile de parler des réussites et d'en faire l'éloge, mais je trouve que les erreurs constituent néanmoins un sujet intéressant, principalement parce qu'elles sont très utiles pour améliorer le processus d'apprentissage.
Je vais commencer par fournir un peu de contexte, puis partager mon point de vue sur l'architecture logicielle, qui est selon moi la partie la plus importante du développement logiciel et sur la manière d'éviter de tomber dans les pièges les plus courants.
Quand on pose la question à un programmeur : »Que préférez-vous : démarrer un projet à partir de zéro ou en maintenir un existant ?«
Ils répondent : »Commencer quelque chose à partir de zéro !«
Cela peut sembler évident, car le sentiment d'accomplissement est généralement plus grand si l'on peut dire : »C'est de mon fait (du moins en grande partie). Cela n'existait pas auparavant, et maintenant c'est le cas !«
Mais il y a bien plus que cela. Le cerveau humain aime l'ordre, il aime déduire des modèles à partir du chaos et d'informations apparemment aléatoires. En ce qui concerne le développement de logiciels, c'est également vrai.
Mais que se passe-t-il dans un projet existant ? Il est probable que le projet comporte déjà un certain niveau de chaos perçu et il en contient certainement plus qu'un chaos inexistant.
Par conséquent, la réponse immédiate est de préférer démarrer un projet à partir de zéro, où vous pourrez contrôler complètement ce chaos en fonction de votre expérience.
Bien sûr, dans Software Utopia, nous ne ferions jamais quelque chose qui introduirait le chaos par notre propre négligence. Hélas, nous ne vivons pas dans ce monde, mais nous avons des outils et des principes pour nous guider.
Le meilleur outil dont nous disposons pour faire face aux tâches embêtantes de la régression, de la correction des bogues, etc., est la planification prévisionnelle. Une bonne architecture est notre amie.
Une solution bien conçue vaut des milliers d'heures car elle nous fera vraiment gagner beaucoup de temps à l'avenir.
La plupart d'entre nous ont lu les livres, nous connaissons choses à faire. Nous devons également faire des tests et appliquer les modèles de conception de manière religieuse. »Concentrons-nous vraiment sur le maintien de ce MVC ; appliquons le BDD pour cela ; concevons les tests de fonctionnalités avant d'écrire le code de production.»
Parfois, nous oublions l'importance de ce que devrait être la première étape, même avant tout cela.
L'architecture.
Bien sûr, avant d'écrire du code de production, oui, veuillez écrire vos premiers tests.
Mais avant même d'écrire vos premiers tests, l'équipe de conception a probablement déjà rassemblé toutes les exigences, des négociations ont été menées avec le client et les autres parties prenantes, elle a peut-être même produit quelques versions du design du produit que vous êtes sur le point de créer et elles ont été pré-approuvées, vous pourriez donc penser que vous devriez bientôt commencer à coder.
Sauf que tu ne devrais pas.
Toute l'équipe devrait s'asseoir et parler du produit qu'elle s'apprête à créer. Ils devraient prendre une feuille de papier ou aller sur un tableau blanc et commencer à énumérer toutes les fonctionnalités du produit.
Identifiez clairement toutes les exigences techniques et la faisabilité de la solution proposée. Remettez en question chaque étape et imaginez vraiment une solution utilisant une approche différente, peut-être des frameworks différents, voire un langage différent.
En fin de compte, il n'y a rien de tel que de consacrer trop de temps à l'architecture.
Pour moi, l'une des meilleures façons d'apprendre est de faire des erreurs.
Comme faire des erreurs peut être embarrassant ou frustrant, lorsque nous les commettons, nous avons tendance à prêter attention à ce qui s'est passé et à nous efforcer de trouver la solution et de trouver le meilleur moyen de ne pas refaire la même erreur.
Cela équivaut à de l'expérience.
« L'expérience est simplement le nom que nous donnons à nos erreurs. »
— Oscar Wilde
J'ai récemment travaillé sur un projet iOS assez complexe. Dès le début du projet, certaines choses n'allaient pas. Les exigences n'étaient pas définies à 100 %, les prérequis n'étaient pas remplis à 100 %, les API n'étaient pas encore prêtes...
Mais le plus important était probablement le suivant : nous n'avions pas défini l'architecture du projet aussi bien que nous l'aurions dû.
Je n'en ai pris conscience que lorsque le mal a été fait, bien entendu. Il y a eu beaucoup de régressions, de réécritures de fonctionnalités et je me suis dit à plusieurs reprises : »Pourquoi ne l'ai-je pas fait de la bonne façon ?»
L'un de ces écueils était qu'aucun cadre de test n'était utilisé. Pas du tout. Les tests et la validation ont été effectués à l'aide de tests utilisateurs et de rares revues de code par les pairs. Puis, lorsqu'un cadre de test a effectivement été intégré au projet, il était trop tard.
L'un des frameworks les plus connus et les plus acceptés pour le développement iOS ne fonctionnait tout simplement pas bien avec toutes les subtilités, les multiples langages et les mauvaises décisions prises lors de la conception de l'architecture du produit (d'un point de vue technique).
Revenons à la table à dessin. Vous recevez un nouveau projet et vous avez peut-être même participé à la phase de collecte des exigences. Même si j'ai déjà une idée de la solution technique globale pour ce projet, je recommanderais :
1. Écrivez tout. Créez des schémas, des diagrammes de composants, des diagrammes de classes, des organigrammes, tout ce que vous jugez nécessaire pour vous aider, ainsi que l'équipe, à comprendre l'ensemble du problème en un coup d'œil.
Reportez-vous à ce document aussi souvent que nécessaire. Cela sera probablement révisé plusieurs fois avant que la première ligne de code ne soit écrite.
2. Lorsque tous les composants/modules sont identifiés, essayez de trouver des solutions solides existantes pour eux. Les frameworks open source sont la voie à suivre, car ils sont déjà utilisés par plusieurs personnes et, par conséquent, testés et beaucoup plus exempts de bogues que ne le deviendrait votre propre solution personnalisée.
3. Lorsque vous choisissez des frameworks externes ou tiers, assurez-vous qu'ils »joue gentiment» avec le reste des frameworks. Essayez de trouver suffisamment de preuves qui confirment la compatibilité entre tous les frameworks que vous allez utiliser.
Le fait de devoir changer de framework pendant le développement parce que vous avez découvert que quelque chose ne fonctionne pas comme prévu en présence d'un autre framework, vous oblige à passer du temps à chercher une solution différente de toute façon et vous fera perdre encore plus de temps à effectuer ces régressions indésirables.
4. Choisissez un bon framework de test. Comme à l'étape précédente, assurez-vous que le framework de test fonctionnera sans effort avec tous les autres frameworks que vous allez utiliser.
La qualité d'un framework de test dépend de la couverture qu'il peut vous apporter sur un projet particulier. S'il n'est pas bien adapté ou s'il ne prend pas en charge une technologie ou un module spécifique que vous envisagez d'utiliser, ne vous y fiez pas.
Tester 8 fonctionnalités sur 10 n'est pas suffisant.
Pour le prochain projet auquel je participerai, je ferai de mon mieux pour suivre ces principes et les mettre à jour si nécessaire. Peut-être qu'une ou plusieurs de ces hypothèses seront remises en question et affinées.
Si votre propre expérience vous a enseigné le contraire, n'hésitez pas à partager vos points de vue et vos recommandations sur les premières étapes à suivre lors du démarrage d'un nouveau projet.
Analyste des systèmes informatiques, programmeur informatique et développeur d'applications. Particulièrement intéressé par le développement d'applications pour les plateformes mobiles.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
