Categories
Programming Software Architecture

Pourquoi devriez-vous commencer à utiliser CUPID et non SOLID pour écrire un logiciel maintenable?

Si SOLID a toujours été la norme, il peut parfois être difficile de toujours appliquer ses principes, et selon Dan North, il peut même être dépassé.

SOLID est un acronyme décrivant les principes d’écriture d’un logiciel maintenable. Développées par Robert Martin, les cinq lettres représentent cinq principes de conception qui contribueraient à rendre les conceptions de logiciels faciles à comprendre, flexibles et évolutives lorsque les exigences nécessitent des modifications.

Bien qu’il ait été la norme pour la conception et l’architecture de logiciels au cours des deux dernières décennies, il peut parfois être difficile de toujours appliquer ses principes. Selon Daniel Terhorst-North, créateur de Behaviour-Driven Development and Deliberate Discovery, SOLID est peut-être même obsolète.

« Quand Robert Martin décrivait tous ces principes, il collectionnait des choses. Il n’était pas simplement assis là à faire des déclarations. Ce sont des choses qu’il avait vues dans la nature et il pensait que c’était des choses utiles à rassembler. Il y avait donc une bonne intention derrière. Mais certaines choses résistent à l’épreuve du temps et d’autres non, et dans le développement piloté par les tests – nous en reparlerons plus tard – j’ai découvert cela il y a plus de 20 ans, c’était vieux de plusieurs décennies.” dit-il lors de son interview à Coding Over Cocktails. 

North étant un critique ouvert de SOLID, il a proposé une alternative qui appelle à écrire un code simple. Il l’appelle CUPIDON.

Écrire du code simple

CUPID, dit North, a été conceptualisé alors qu’il réfléchissait aux principes SOLID après une conférence. 

“Donc, pour chacun des cinq principes, je passe 15 secondes à le décrire, 15 secondes à décrire pourquoi je ne l’aime pas, et 15 secondes à dire ce que je ferais à la place et à penser que j’aurais exactement la réponse à votre question. Et en écrivant la conférence, j’ai réalisé que la chose que je ferais à la place était la même chose à chaque fois, c’est-à-dire écrire du code simple », dit-il.

Dans son interview ci-dessous, il explique comment il définit le “code simple” et pourquoi il est important que tous les développeurs comprennent ce que vous essayez de construire.

“Le code simple”, explique North, ne concerne pas le code que lui seul comprend, mais le code qui “s’intègre dans la tête de quelqu’un d’autre”.

« Mes qualifications pour le chef de cette personne sont qu’elle comprend la langue, le code idiomatique dans ce style de langue. Donc, je ne vais pas prendre quelqu’un qui n’a jamais vu de code Go auparavant et lui dire : “Qu’est-ce que ça fait ?” Donc, l’idée est que quelqu’un qui connaît le langage, son écosystème, ses bibliothèques de base, son temps d’exécution, sa chaîne de construction. Et aussi, une certaine familiarité avec le domaine dans lequel nous travaillons », dit-il.

Être capable d’écrire du code simple et de pouvoir aimer coder est ce qui l’a inspiré à créer CUPID.

«J’ai commencé à y penser et je me suis retrouvé avec des propriétés. J’ai dit que je ne décrirais aucun principe comme universel. Ils sont tous contextuels, mais il y a des propriétés du code avec lesquelles je pense qu’il est agréable de travailler, qui rendent le codage amusant », ajoute North.

Apprenez-en plus sur SOLID et CUPID dans cet épisode et écoutez d’autres experts mondiaux de l’architecture, du design et des technologies qui facilitent la transformation numérique sur le podcast Coding over Cocktails.

What’s wrong with SOLID and Test Driven Development with Daniel Terhorst-North by Coding Over Cocktails

 

Leave a Reply Cancel reply