Nouveautés

Quel est le rapport entre l'entropie et le développement logiciel ?

18/10/2016

Traduction : traduction automatique

Et pourquoi la qualité est si importante. Et que l'on ne sera jamais assez reconnaissant pour les choses qui existent en haute qualité. Malheureusement, la qualité n'est pas un cadeau. Elle demande des efforts et du travail. Partie 4 de notre manifeste d'ingénierie : valorisez la qualité !

Bien que tous les posts précédents commençaient par une citation ou une courte histoire, je ne vais pas continuer ainsi ;) Ce n'est pas parce que quelque chose a toujours été comme ça que cela doit rester comme ça. C'est exactement la même chose dans le développement de logiciels. Par exemple, un homme sage a compris qu'il était possible d'améliorer la compréhension et la lisibilité de notre code en renommant la fonction "FillAuto" en "BindModel". Le nom initial de la fonction ne disait absolument rien de ce qui se passait dans le code. Certes, tout le monde le savait avec le temps, mais les nouveaux membres du personnel étaient régulièrement déconcertés. L'homme sage a osé remettre en question une tradition dans notre code et apporter un changement positif.

C'est précisément l'objet de ce billet de blog. Nous écrivons du code, le code évolue, nos connaissances augmentent. Le code a malheureusement une caractéristique négative : à moins de l'aborder de manière très consciente, il devient de plus en plus complexe à chaque modification. L'entropie augmente. Il arrive un moment où le code existant ne répond plus aux exigences d'une nouvelle histoire. Que ce soit parce que le code d'origine n'était qu'un prototype, parce que les performances ne sont plus suffisantes ou parce que nous avons entre-temps introduit de nouveaux patterns, c'est à ce moment-là qu'il faut intervenir et exiger ce qui vous revient de droit : le temps d'un refactoring. Mais les refactorings ne sont pas les seuls à contribuer à la qualité. Les tests automatisés, les critères d'acceptation bien définis, les revues de code proprement menées et bien sûr l'état d'esprit ont une grande influence.

Prévoyez du temps pour les tests unitaires, les tests d'intégration et les tests d'interface utilisateur.

Il faut certes du temps pour écrire les tests, mais en contrepartie, vous obtenez une sorte d'assurance que votre code fonctionne comme vous le souhaitez. De plus, les tests aident par la suite les autres développeurs à comprendre votre code et à détecter d'éventuels bugs à un stade précoce. Et vous apprenez à découpler les classes et à garder le code testable. Écrire des tests fait donc de vous un meilleur développeur ! Si vous voulez en savoir plus sur les tests, je vous recommande cet article.

Prévoyez suffisamment de ressources pour les CATs.

CAT = Crevoir le code, Avérifier les critères d'acceptation &amp ; Texaminer les cas de test.
Soyez également conscient qu'un CAT est plus qu'une simple revue de code. Le code peut être aussi bien structuré et compréhensible que possible. Si les critères d'acceptation ne sont pas remplis, l'histoire n'est pas complète. Ne considérez pas les CAT comme une torture, mais comme un défi. En tant que réviseur, vous apprendrez à mieux connaître d'autres stories et vous pourrez y intégrer vos connaissances. En tant que relecteur, vous serez informé des problèmes et des possibilités d'amélioration qui feront de vous un meilleur développeur!

Et pour finir, soyez toujours motivé pour fournir la meilleure qualité possible.

Dès le début de l'histoire, obtenez des commentaires d'autres développeurs et documentez votre mise en œuvre et vos conclusions afin que d'autres puissent profiter de vos connaissances. Cela fera de vous tous de meilleurs développeurs ! (et compilez d'abord votre code localement avant de le publier dans le Repository). Cela fera de vous des développeurs plus populaires ;))

Comme vous pouvez le constater, si vous restez motivé et que vous mettez toujours l'accent sur la qualité, vous deviendrez automatiquement de meilleurs développeurs de logiciels.
Maintenant, je veux quand même faire une citation :

Programmez toujours comme si le type qui doit maintenir le code était un psychopathe violent qui sait où vous habitez.

Notre manifeste

Nouveautés
Pourquoi la force ne devrait pas toujours être avec vous
par Tim Csitkovics

Notre manifeste vous convainc?

Ou il ne vous convainc pas, mais vous voulez quand même développer chez nous ? Nous avons les offres d'emploi suivantes dans le développement de logiciels :

La grammaire

Qui remarquera l'erreur grammaticale volontairement indulgente de notre quatrième manifeste?

Cet article plaît à 40 personne(s)

Benjamin Truninger

Software Engineer

benjamin.truninger@digitecgalaxus.ch

Nouveautés

Chiffres annuels, tendances des ventes, nouveaux services, nos efforts en matière de développement durable pour les produits de première main, etc.

Tout afficher

2 commentaires

later

Recherche

Quel est le rapport entre l'entropie et le développement logiciel ?

Prévoyez du temps pour les tests unitaires, les tests d'intégration et les tests d'interface utilisateur.

Prévoyez suffisamment de ressources pour les CATs.

Et pour finir, soyez toujours motivé pour fournir la meilleure qualité possible.

Notre manifeste

Pourquoi la force ne devrait pas toujours être avec vous

Notre manifeste vous convainc?

La grammaire

2 commentaires

Top 10 catégories

Aller à

Pourquoi la force ne devrait pas toujours être avec vous

2 commentaires

Digitec Offre du jour