paint-brush
Décisions d'architecture logicielle : concentrez-vous sur les faits et ne faites pas de suppositionspar@inovak
408 lectures
408 lectures

Décisions d'architecture logicielle : concentrez-vous sur les faits et ne faites pas de suppositions

par Ivan Novak4m2023/07/28
Read on Terminal Reader

Trop long; Pour lire

YAGNI est un principe né de l'Extreme Programming. Il s'agit essentiellement d'un rappel amical de ne pas ajouter de fonctionnalités tant que cela n'est pas jugé nécessaire. Ne soyez pas comme Smitty. Construisez ce dont vous avez besoin quand vous en avez besoin. Soyez comme Slack ; laissez les besoins de vos utilisateurs guider vos décisions d'architecture logicielle.
featured image - Décisions d'architecture logicielle : concentrez-vous sur les faits et ne faites pas de suppositions
Ivan Novak HackerNoon profile picture
0-item

Vous êtes probablement dans ce jeu parce que vous voulez créer un logiciel qui non seulement fonctionne mais qui ravit également les utilisateurs, n'est-ce pas ?


Bonnes nouvelles! Ce n'est pas un jeu de devinettes. Il s'agit de décisions éclairées basées sur une compréhension approfondie. Il s'agit de faits plutôt que de suppositions.


"Dans l'architecture logicielle, les faits sont des alliés de confiance, mais devinez ? Ils pourraient simplement vous construire un château de cartes numérique."


Le chemin peut être truffé de choix difficiles, mais équipez-vous des bonnes connaissances et vous construirez en toute confiance la bonne prochaine chose plutôt qu'une douzaine (ou plus) de suppositions !

La puissance de YAGNI

YAGNI ? V ous n'en aurez pas besoin . C'est un principe né de l'Extreme Programming. YAGNI est essentiellement un rappel amical de ne pas ajouter de fonctionnalités tant que cela n'est pas jugé nécessaire. Et croyez-moi, c'est indispensable.


La suringénierie est aussi courante que les séances de codage de fin de soirée alimentées au café. Ni l'un ni l'autre ne devrait arriver, mais vous savez comment ça se passe...


Permettez-moi de partager une histoire. Une fois, j'ai travaillé avec un gars, appelons-le Smitty. Maintenant, Smitty était un développeur extraordinairement enthousiaste. Il était du genre à concevoir un vaisseau spatial entier alors que le client ne demandait qu'un vélo. C'était impressionnant, mais souvent, c'était tout simplement inutile.


Un jour, Smitty a passé des semaines à développer une fonctionnalité compliquée que, devinez quoi, les clients n'ont jamais utilisée ! Tout ce temps, cette énergie et ce café - gaspillés.


C'est l'écueil que YAGNI vous aide à éviter. Ne soyez pas comme Smitty. Construisez ce dont vous avez besoin quand vous en avez besoin.

Votre étoile directrice : les besoins des utilisateurs

Mais comment savez-vous ce qui est nécessaire ? Votre logiciel ne consiste pas à montrer vos prouesses technologiques. Il s'agit de résoudre les problèmes de vos utilisateurs. Votre étoile guide ? Les besoins de vos utilisateurs, pas vos caprices et vos désirs ou ceux de votre équipe.


Il s'agit de concevoir une solution si transparente qu'elle s'intègre dans la vie des utilisateurs comme la pièce manquante d'un puzzle.


L'architecture logicielle doit être considérée délibérément, et avec l'ensemble du produit à l'esprit, et non quelque chose hérité accidentellement d'une séquence de projets. Évitons la "conception par accident".


Considérez Slack, la plate-forme de messagerie très appréciée. Ce qui distingue Slack, c'est sa focalisation laser sur les désirs des clients. Ce n'était pas destiné à être simplement une autre application de messagerie ; il a été conçu pour être un centre de collaboration où le travail se déroule de manière transparente.


Ils ont observé, interrogé, rassemblé des données et intégré ces informations dans l'application dont nous ne pouvons pas nous passer. Soyez comme Slack ; laissez les besoins de vos utilisateurs guider vos décisions d'architecture logicielle.

L'essence des décisions basées sur les données

Maintenant, pour prendre des décisions éclairées, vous avez besoin de données - des faits froids et concrets. Les conjectures sont un ennemi dont vous n'avez pas besoin dans votre vie. C'est comme essayer de frapper une cible avec un bandeau sur les yeux - la plupart du temps, vous raterez.


Les décisions prises sur des intuitions sont aussi bonnes que de lancer une pièce de monnaie, ce n'est pas ainsi qu'un logiciel réussi est construit.


Considérez Amazon, une entreprise qui vénère pratiquement les données. Chaque décision architecturale, chaque fonctionnalité ajoutée et chaque modification apportée est basée sur une analyse exhaustive des données client. Le résultat? Une expérience d'achat hyper-personnalisée qui fait revenir les clients.

Construire des mécanismes de collecte de données

"Où puis-je obtenir ces données ?" Bonne question! Vous construisez des mécanismes pour le rassembler! Celles-ci peuvent être aussi simples que les commentaires directs des utilisateurs ou aussi complexes que les pipelines d'analyse de données automatisées. Pensez-y comme si vous posiez des pièges pour obtenir des idées - plus vous en placez, plus vous en attraperez.


Cela dit, il est crucial de se rappeler qu'il ne s'agit pas de collecter des données pour le plaisir. Il s'agit de recueillir des informations exploitables qui vous aident à offrir des fonctionnalités meilleures et plus utiles à vos utilisateurs. Allez-y, embrassez votre data scientist intérieur !

Le cheminement vers une approche axée sur les données et centrée sur l'utilisateur

Passer à une approche axée sur les données et centrée sur l'utilisateur peut sembler difficile, mais les résultats en valent la peine. L'adoption de nouvelles méthodologies, la culture des données et la promotion d'une culture axée sur l'utilisateur sont des changements à l'échelle de l'équipe.


Oui, cela peut sembler difficile, mais le résultat est un processus de développement logiciel plus léger, plus efficace et axé sur la valeur. Lorsque nous nous concentrons plus souvent sur les bonnes choses, nous pouvons accomplir plus avec moins !

Champion du changement

Écoutez, il pourrait y avoir de la résistance. Il pourrait y avoir ceux qui s'accrochent aux anciennes méthodes, aux méthodes confortables. Mais c'est votre chance de défendre une nouvelle ère. Votre chance de diriger votre équipe vers un avenir où les décisions sont guidées par des faits et non par des suppositions.


Où le logiciel est conçu pour résoudre de vrais problèmes, pas pour satisfaire les démangeaisons d'un développeur.

Votre appel à l'action

Voici votre première étape. Commencer petit. La prochaine fois que vous êtes sur le point d'ajouter une fonctionnalité ou de prendre une décision architecturale, demandez : "Avons-nous des données pour étayer cette décision ? Est-ce que cela sert les utilisateurs ou est-ce juste une toute nouvelle chose ?"


Un bon logiciel n'est pas construit sur des caprices ou des intuitions ; il repose sur des décisions éclairées.


En fin de compte, il s'agit d'offrir une valeur massive à vos utilisateurs - de créer des logiciels que les gens utilisent, aiment et sans lesquels ils ne peuvent pas imaginer leur vie. Et vous êtes plus que capable de le faire.


Alors, allez-y, rassemblez vos faits, donnez la priorité à vos utilisateurs et commencez à créer des logiciels incroyables. Vos utilisateurs attendent.