Aujourd'hui est une journée ensoleillée. Vous conduisez sur la route de votre village où vivent tous vos amis, votre famille et votre chien bien-aimé. Une merveilleuse journée! Soudain, vous entendez un cri terrible et cauchemardesque déchirer les environs. L'énorme Hydre dégoûtante s'approche du village pour le détruire! Vous prenez une épée (bien sûr, vous avez une épée!) Et essayez de protéger tous ceux que vous aimez. Mais il y a un petit problème: le monstre a de nombreux objectifs, et lorsque vous en coupez un, un nouveau grandit rapidement!

Il semble que vous ne pouvez pas gagner cette bataille. Peut-être pouvez-vous jouer avec Hydra assez longtemps pour que tout le village ait le temps de fuir une terrible menace? Enfin, vous deviendrez un véritable héros du monde entier! Qui ne veut pas ça?

Le rôle d'Hydra est l'entropie dans les logiciels: c'est votre ennemi, il vous épuise, mais vous ne pouvez jamais vous en débarrasser complètement. Mais vous devez toujours vous battre avec lui pour que vos candidatures (et collègues) restent saines et saines.

Nous découvrirons:

1. Qu'est-ce que l'entropie dans un logiciel et comment le remarquer dans votre code.
   
2. Quelles sont ses causes possibles et comment maintenir l'entropie faible.
   

Assez parlé, au point!

Connaissez votre ennemi

Qu'est-ce que l'entropie et comment s'est-elle retrouvée dans mon application?

Parfois, il est utile de connaître l'étymologie des mots utilisés, en particulier des mots spécifiques comme l'entropie. Traduit du grec, cela signifie «transformation». Changer. Quelque chose auquel vous devriez vous habituer en tant que développeur de logiciels.

L'entropie fait référence à la deuxième loi de la thermodynamique. Il dit que dans un système fermé et isolé, la quantité de chaos ne diminue pas avec le temps. Il reste stable ou en croissance.
L'idée d'entropie dans les logiciels est née à travers le livre Object-Oriented Software Engineering . Plus le programme change, plus il y a de chaos, son entropie augmente.

La première chose que les pauvres développeurs doivent nous expliquer est la vérité tragique: nous pouvons combattre la quantité d'entropie dans nos programmes, mais nous ne pouvons jamais nous en débarrasser.

Créer la meilleure équipe (avec votre participation, bien sûr!), Le meilleur environnement, la meilleure gestion, la meilleure culture de l'entreprise, le meilleur projet. Que va-t-il se passer avec le temps?

1. Vous fredonnerez tous les matins, "C'est le meilleur projet!" Un projet vert qui ressemble à un beau champ, illuminé par un magnifique lever de soleil.
   
2. Vous et l'équipe ajouterez de plus en plus de fonctionnalités. Puisque vous êtes le meilleur des meilleurs, pendant un moment, tout a l'air bien.
   
3. Des mois ou des années passeront. Personne ne veut plus travailler sur un projet. Même si elle était bien conçue, la technologie est obsolète, le projet demande trop d'efforts et de temps pour être compris, son expansion est coûteuse. Il est trop difficile de construire son bon modèle mental.
   

Comment avez-vous créé cette complexité? Vous avez juste besoin de faire évoluer le projet. Plus d'éléments signifient souvent plus de dépendances et plus de complexité. J'ai déjà écrit un article détaillé à ce sujet.

Si vous expliquez cela à Lyokha, votre collègue développeur, il répondra:

«Nifiga! Êtes-vous un imbécile Le chaos et le désordre n'ont pas leur place dans ma belle application! Ma réputation ne sera pas ternie par des bêtises! Je suis le maître de mon destin! Si je ne change pas mon programme, alors la complexité ne grandira pas, et à propos de cette preuve de la contradiction, je déclare que vous vous trompez, et je suis le meilleur! »

Vous pouvez expliquer calmement, de manière convaincante et décisive à Lyokha que même si vous ne changez pas le programme, tout autour de lui changera. Si vous avez des bibliothèques tierces qui ne sont pas mises à jour, il y aura des problèmes de sécurité. Et si vous les mettez à jour, cela ouvrira la porte au changement et à l'entropie.

De plus, si un jour vous devez changer quelque chose dans votre logiciel après une longue période, vous ne vous souviendrez pas de tous les détails. Et même la meilleure documentation ne vous aidera pas. Le monde a changé et ce qui était vrai hier peut ne jamais l'être, tant au niveau technologique qu'au niveau des entreprises.

De tels changements apportent à la fois une grande quantité d'entropie.

La question n'est donc pas de s'en débarrasser, mais avec modération. C'est une vraie bataille dans laquelle nous, développeurs, sommes lancés.

Définition de l'entropie dans le logiciel

Qualité logicielle

Comment savoir que votre application présente un haut niveau d'entropie? Un bon indicateur est la qualité du code.

Qu'est-ce que c'est et comment le mesurer? Selon Accelerate: The Science Behind Devops :

• Si le rapport des changements / échecs augmente, la qualité diminue. Suivez les changements, les bugs et les plantages, comparez-les entre eux. Si chaque modification entraîne de nouveaux bugs ou plantages, l'entropie de votre programme augmente.
  
• Un rôle important est joué par la perception subjective du projet par les développeurs. Si tout le monde a le sentiment qu'il devient de plus en plus difficile de faire évoluer l'application sans la casser, l'entropie est probablement élevée. Cependant, cette sensation devrait être courante.
  
• Si l'équipe passe beaucoup de temps à corriger les bogues ou à se remettre des échecs, l'entropie doit avoir fait un nid dans votre application.
  

Si vous pouvez obtenir des informations sur la corrélation des changements et des échecs et passer du temps à corriger les bogues, vous pouvez trouver un bon calendrier pour convaincre la direction de la nécessité d'une sorte de refactoring.

Démon de difficulté

Même si vous disposez d'un code de la plus haute qualité, la complexité peut facilement augmenter en ce qui concerne les capacités mêmes du programme. L'entreprise elle-même est une source de la complexité nécessaire dont vous ne pouvez vous débarrasser.

Compte tenu de la complexité excessive de l'entreprise, les développeurs devront consacrer beaucoup d'efforts à construire un bon modèle mental des activités de l'entreprise. Par conséquent, ils commettront des erreurs en essayant de traduire les exigences de l'entreprise en code.

Parlons plus en détail de la complexité de l'entreprise: avons-nous vraiment besoin de toutes ces fonctionnalités complexes qui nous laissent tomber?

La raison de l'entropie et comment y faire face

Cascade d'entropie

Le problème

Plus ou moins évidente, la principale cause d'entropie dans les logiciels est les développeurs eux-mêmes. Ils sont paresseux, ils manquent de qualifications, surtout Sanka, avec qui vous travaillez. Il pose tellement de questions!

Je suis fortement en désaccord avec cette opinion. D'après mon expérience, la principale raison de l'entropie est le leadership, en particulier dans les entreprises avec un style de gestion en cascade.

Comme Gerald Weinberg l'a noté dans The Secret of Consulting :

Même s'il s'agit d'un problème purement technique, son origine remonte toujours à l'action ou à l'inaction de la direction.

Je sais ce que tu pensais: «Tu as tort! La direction n'est pas toujours responsable de tout! C'est juste pratique pour les développeurs de blâmer les patrons pour tout! »

Je ne dis pas que le leadership est à blâmer pour tout, mais il a toujours un certain degré de responsabilité . Le développeur a-t-il fait quelque chose de mal? Vous devez revoir le processus d'embauche. Les spécifications ont été mal mises en œuvre? Peut-être que certains dirigeants ne savent pas ce qu'ils veulent vraiment, et donc les spécifications ne lui importent pas.

Par conséquent, il est si difficile d'être un leader! Plus vous êtes grand dans la hiérarchie, plus c'est difficile.

En tant que développeurs, dans quelle mesure influencez-vous la prise de décision? Si à 100%, alors félicitations, vous êtes à blâmer pour tout. Si à 0%, votre faute ne l'est pas. Entre ces pôles se trouve tout le spectre d'influence. Et la cascade n'en implique pas un grand nombre.

Vous utilisez Scrum, Kanban et Poker Planning? Bien sûr, vous n'utilisez pas la cascade! Vous utilisez Agile comme un enfant construit une maison avec un tournevis.

Bien sûr, les outils sont importants, mais leur signification est bien inférieure à l'importance de votre façon de penser , qui est nécessaire pour le développement correct du logiciel. Pour citer le manifeste Agile:

Les personnalités et les interactions sont plus importantes que les processus et les outils.

Utiliser Scrum ne signifie pas que vous utilisez Agile, surtout si vous n'avez pas la façon de penser que cette méthodologie essaie d'enseigner.

Avec la gestion des cascades, quelqu'un de plus haut que vous prend une décision, plus haut, d'autres prennent de nouvelles décisions, etc.

Aux niveaux inférieurs de la hiérarchie se trouvent des employés dont la malédiction est de suivre toutes les décisions prises. Quelle est leur tâche? Faire, comme si des ouvriers sur la chaîne de montage d'une usine automobile. Ils n'ont pas besoin de réfléchir, ils doivent faire des voitures .

Mauvaise nouvelle: en tant que développeur, vous serez au bas de la hiérarchie.

Si quelqu'un au sommet prend des décisions concernant les fonctions de l'application et que vous n'avez pratiquement aucune possibilité d'influencer le processus décisionnel, alors bienvenue à la cascade! Malheureusement, le plus souvent, la haute direction ne voit pas que dans le monde du développement logiciel, il n'y a pas de phase de production . Les développeurs sont engagés dans la conception du système , et cette tâche est loin de l'ensemble convoyeur de la cabine.

Pourquoi? Parce que, contrairement à une voiture, les applications évoluent constamment! Vous devez les concevoir correctement pour qu'elles fonctionnent, répondent aux besoins des utilisateurs, que les applications aient des performances acceptables, qu'elles soient évolutives et résistantes aux changements, tout en maintenant l'entropie à un niveau bas. Pour ce faire, vous devez prendre de nombreuses décisions sur la manière de refléter les connaissances métier dans votre code.

Si vous n'affectez pas la complexité que le leadership vous incombe, vous devrez consacrer beaucoup d'efforts à la gérer dans le code. Cela sera considéré comme une complexité «nécessaire»: une complexité qui ne peut être évitée.

Résultat possible? Les niveaux d'entropie peuvent augmenter très, très rapidement.

Solution possible

L'entreprise doit exercer une prise de décision et une responsabilité conjointes aussi activement que possible.

Si vous reconnaissez votre entreprise dans le modèle en cascade que j'ai décrit, alors vous devez parler avec ceux qui prennent les décisions:

• Donnez des données et des arguments solides pour expliquer pourquoi et comment simplifier la fonctionnalité X ou Y. Expliquez le prix possible du développement d'une fonctionnalité complexe, maintenant et à l' avenir .
  
• Expliquez pourquoi le développement de logiciels Agile signifie que les gens doivent travailler ensemble. Les gestionnaires, les concepteurs, les développeurs et tout le monde devraient faire partie du processus décisionnel en fonction des besoins de l'entreprise.
  
• Si votre direction rejette automatiquement l'offre, vous devez comprendre pourquoi elle l'a fait. Posez des questions.
  
• Parlez de ce que les décideurs considèrent le plus important: l'argent et le temps. Montrez-leur que la pensée de style Agile (et pas seulement les outils) peut vous sauver tous les deux.
  

Cependant, il est difficile d'essayer de résoudre le problème si on ne vous l'a pas demandé. De nombreux gestionnaires sont très satisfaits du modèle de la cascade et ne savent souvent même pas qu'ils le suivent. Vous aurez besoin de beaucoup de diplomatie et de tact.

Compte tenu de tout cela, si vous estimez que les solutions commerciales ajoutent trop de complexité à votre application et que vous ne pouvez rien y faire même si vous essayez, alors je vous conseille de trouver un autre emploi. C'est épuisant - travailler avec une entropie élevée tous les jours, et faire un produit gonflé de plaisir ne suffit pas ... ou l'utiliser. Cela peut vous donner une idée du succès que votre produit attend.

Et le dernier: ce qui peut sembler compliqué au niveau de l'entreprise peut être simplifié si vous connaissez bien les processus métier. C'est extrêmement important. Par conséquent, en savoir plus sur les activités de votre entreprise, ce qu'elles font et ce qu'elles ne font pas, cela vous aidera à simplifier les fonctionnalités et la base de code.

En exprimant notre architecture, nous expliquons quelque chose à l'ordinateur. Et pour cela, nous devons bien comprendre ce que nous expliquons.

Fouet Donald

Code qualité et devoir technique

Le problème

En plus de la complexité «nécessaire» introduite par l'entreprise, l'entropie dans les logiciels est étroitement liée à la qualité du code et à la dette technique.

Qu'est-ce que la dette technique? Autrement dit, ce sont des simplifications (hacks) que vous utilisez pour gagner du temps, sachant que plus tard cela peut vous revenir. Surtout dans les cas où d'autres fonctionnalités dépendent de ces hacks: vous devrez le réparer avec intérêt, comme avec une dette réelle, sous forme de difficultés et de maux de tête.

Selon la tâche de votre candidature, la dette technique peut être plus ou moins acceptable. Si le programme doit durer quelques mois, vous ne pouvez pas penser à la dette technique, à l'entropie ou à la qualité. Assemblez simplement les morceaux de code et vous avez terminé!

Par exemple, cela peut être une solution temporaire avant de créer une application plus complexe à partir de zéro. Ou alors, vous pouvez rapidement écrire un prototype pour illustrer l'idée, puis tout réécrire ou abandonner le concept.

D'un autre côté, les entreprises souhaitent généralement développer des applications à plus longue durée de vie. C'est raisonnable: la réécriture d'une application peut être très coûteuse (surtout si elle est volumineuse), et personne ne peut garantir que son niveau d'entropie sera inférieur. La copie est une entreprise très risquée.

Dans de tels cas, vous devez être très prudent avec le devoir technique et la qualité du code. Il s'agit d'une partie importante de votre travail en tant que développeur.

Dans le célèbre livre The Pragmatic Programmer (dans lequel, entre autres, le principe DRY est introduit), une analogie intéressante de la dette technique est donnée. Une étude est décrite ici qui compare la destruction de bâtiments urbains avec ... des fenêtres détruites. La fenêtre cassée donne une impression d'abandon, inspirant tous les intimidateurs de la région. Par conséquent, les bâtiments dont les fenêtres sont brisées sont vandalisés plus rapidement que les bâtiments dont les fenêtres sont entières.

La dette technique est une simplification ou un hack de votre code, une fenêtre cassée. Quand un autre développeur, ou même vous-même à l'avenir, le remarquerez, il y aura une tentation d'ajouter encore plus de dette technique, car "il y a encore un mauvais code ici, alors pourquoi s'envoler?"

Exemple: vous avez écrit une solution de contournement pour un bogue complexe, car vous n'avez pas eu le temps de le rechercher. Un autre développeur (ou vous-même plus tard) en plus de cette solution de contournement peut écrire un code différent, résolvant un autre problème. Des couches de solutions de contournement que personne ne trouvera jamais très rapides se développeront.

Solution

Tout d'abord, comment savoir si un code a une dette technique?

Demandez-vous:

• Puis-je expliquer simplement et logiquement ce que fait le code?
  
• Les noms corrects sont-ils utilisés ici? Est-ce qu'ils aident à expliquer ce que fait le code?
  
• Les noms longs avec "et" s'appliquent-ils, comme "deleteUserAndShutDown"? C'est un bon signe que vous devez séparer une fonction, une méthode ou une autre construction.
  
• Est-ce que vous pensez que du code a été ajouté à cause de la paresse? Cela viole-t-il la logique et nuit-il à la compréhension?
  

Plus vos connaissances et votre expérience se développent, plus vous êtes curieux et plus vous tenez souvent des discussions saines avec d'autres développeurs, plus vous remarquerez des schémas d'endettement technique. Ceci est un code avec un étranglement .

Lorsque vous rencontrez de tels modèles, veuillez ne pas les considérer comme la permission d'ajouter une dette encore plus technique:

1. Une augmentation de la durée technique entraînera de nouveaux problèmes. Ils reviendront et vous poursuivront (et votre équipe) encore plus.
   
2. Ayant rencontré une dette technique, refactorisez-la. C'est la meilleure option. Si vous n'avez ni le temps ni l'énergie, ajoutez simplement un commentaire // TODO: refactoriser pour telle ou telle raison. Signalez un problème, ne le laissez pas caché dans la base de code.
   

N'oubliez pas que vous devez refactoriser en parallèle avec le développement d'autres fonctionnalités afin qu'elles correspondent à l'architecture actuelle. En termes simples, la réparation de la dette technique ne doit pas être une tâche indépendante, mais un processus continu qui peut ne pas être lié à la tâche actuelle. Lors du développement d'une fonctionnalité, donnez-vous le droit de corriger la dette technique rencontrée.

Refactorisez de petits morceaux de code à la fois et exécutez souvent des tests pour vous assurer que le système se comporte comme prévu.

Enfin, lors de la refactorisation, vous aurez peut-être besoin de bons arguments:

1. Tout d'abord, pour vous-même. Il est facile de penser que votre collègue n'est pas en mesure de programmer et que vous savez mieux que les autres. Mais si vous ne voyez pas les avantages spécifiques du refactoring, alors ne le voyez pas. Peut-être que tout cela n'est que dans votre ego, et vous pouvez ruiner quelque chose.
   
2. Si le refactoring est lié au style de code, cela signifie que votre équipe ne l'a pas clairement défini. Organisez une réunion et décidez ensemble du style de code que vous souhaitez adopter. Cela devra être écrit quelque part, afin que tout le monde puisse gérer au besoin. Modifiez l'accord en fonction des besoins de l'équipe. Sinon, votre code sera rempli de commentaires comme «nous utilisons des onglets !!! PAS D'ESPACES !!!!! 11! 1 !!! ”. C'est un bruit inutile.
   
3. Enfin, si quelqu'un vous demande pourquoi vous avez changé son beau code, vous aurez de vrais arguments pour expliquer votre décision.
   

Les bons arguments jouent toujours un rôle positif à l'avenir. Par exemple, encapsuler une bibliothèque tierce pour qu'elle ne provoque pas de fuite dans votre base de code. Si vous ne comprenez pas pourquoi je parle d'une fuite, alors lisez ce que j'ai écrit sur les abstractions .

Il est difficile pour nous, humains, de faire des prévisions à moyen et long terme. Par conséquent, il n'est pas toujours facile de refaçonner ou de «vendre» quelque chose en vue d'un avenir inconnu.

Le devoir technique reflète le dualisme entre la voie simple et la bonne . Le premier est rapide et attrayant, le second rendra votre projet évolutif et facile à entretenir. Vous aurez besoin d'autodiscipline pour choisir le deuxième chemin aussi souvent que possible. Sinon, l'avenir sera rempli de souffrances.

Si vous êtes trop fatigué, ennuyé ou plein d'autres pensées ou émotions qui réduisent votre motivation à rester sur la bonne voie, et non la simple, alors il vaut mieux ne pas encore programmer. Faites une promenade, parlez avec des collègues, faites une pause. Revenez au code avec de nouveaux cerveaux.

Le plus souvent, une dette technique est ajoutée lors du débogage. Si vous corrigez un bogue en ajoutant une solution de contournement, vous n'avez rien corrigé. Le bug reste, il est juste plus difficile à exécuter et à le trouver accidentellement. Vous devez corriger les bogues en utilisant la refactorisation , la modification ou la suppression complète du code. Testez ensuite le code pour vous assurer que le bogue ne se reproduit plus.

Enfin: blâmer ses collègues pour leurs erreurs est improductif. Si vous parlez mal ou sarcastiquement de votre base de code, cela ne résoudra pas non plus les problèmes, cela ne fera qu'aggraver la situation. Ne détruisez pas l'esprit d'équipe. Vous devez réduire l'entropie dans le projet et ne pas la détruire verbalement.

Tests automatisés

Le problème

Il y a quelque chose de fascinant pour moi dans le monde magique du développement logiciel, en particulier dans les startups: de nombreux programmeurs ne veulent toujours pas écrire de tests automatisés.

Pourquoi cela me fascine-t-il? Dans tous les autres domaines de l'ingénierie, ils testent ce qu'ils font en suivant un processus rigoureux. Lorsque vous construisez une fusée, vous devez tester de nombreux systèmes, sinon la fusée tombera. Il en va de même pour les voitures, les ponts, les avions - n'importe quoi.

Économiser de l'argent .

Un exemple simple: la NASA teste minutieusement son code (voir règle 5) .

, , , . , , .

. .

, , — , . ? , . , , ( ), , - .

, : , . , .

, .

Solution

, , , .

. - 1,3 . , . «» .

:

• « ».
  
• « , ».
  
• « . , , ».
  

, , - ( ), :

• . , , .
  
• . , , - .
  
• . — , .
  
• , - . , - . !
  
• , . !
  

, .
, . , . , .

, , . .

, , . , , - .

, , . , , :

• , , .
  
• - , .
  

, . , . . , , , - , .

— , .

, .

,

:

• .
  
• , .
  
• , - .
  

. , , .

?

— . - , . , .

C'est tout! , .

, , .

, , : « , , ? , . !».

: , . , . , .

, , , . , , . !

. :

• .
  
• , .
  
• .
  

, . , . , , .

, , . ?

, . , , .

:

• , . «, ?» — , « ! ! !».
  
• , . , , , , . «, , ?» « , 289 ».
  

, . , !

( !) .

. , , .

, — , , . !

!

, , , , . ? ? - ? ?

. , . -, . , , , .

, , . . — .

Alors. ?

• — . . , .
  
• — .
  
• . / .
  
• , , .
  
• , . , .
  
• Créez une atmosphère qui facilite le partage des connaissances grâce à une programmation conjointe, une analyse de code ou simplement en établissant des liens vers des sources d'informations intéressantes (articles, livres).
  

Le logiciel idéal n'existe pas. L'entropie fera toujours partie de notre travail. Cela ne signifie pas que nous avons déjà perdu cette bataille. Cela signifie que la réduction de l'entropie dans toute la base de code est déjà une victoire!

Liens utiles:

• Le programmeur pragmatique
  
• L'entropie logicielle expliquée: causes, effets et remèdes
  
• Entropie dans le logiciel
  
• Pourriture logicielle, entropie et théorie des fenêtres brisées