Catégorie : Livres

Dans le livre 97 Things every programmer should know, Diomidis Spinellis nous parle de l’importance du versionnage d’un projet.

Voici l’article de Diomidis Spinellis, en Français.

Mettez tout dans tous vos projets sous contrôle de version. Les ressources dont vous avez besoin sont là : des outils gratuits comme Subversion, Git, Mercurial et CVS; un espace disque abondant; serveurs bon marché et puissants; mise en réseau omniprésente; et même des services d’hébergement de projet. Après avoir installé le logiciel de contrôle de version, tout ce dont vous avez besoin pour mettre votre travail dans son référentiel est d’émettre la commande appropriée dans un répertoire propre contenant votre code. Et il n’y a que deux nouvelles opérations de base à apprendre: vous validez vos modifications de code dans le référentiel et vous mettez à jour votre version de travail du projet avec la version du référentiel.

Une fois que votre projet est sous contrôle de version, vous pouvez évidemment suivre son historique, voir qui a écrit quel code, et se référer à un fichier ou une version de projet à travers un identifiant unique. Plus important encore, vous pouvez faire des changements de code sans crainte – plus de code commenté au cas où vous en auriez besoin à l’avenir, car l’ancienne version vit en toute sécurité dans le référentiel. Vous pouvez (et devez) étiqueter une version logicielle avec un nom symbolique afin de pouvoir facilement réexaminer à l’avenir la version exacte du logiciel exécuté par votre client. Vous pouvez créer des branches de développement en parallèle: la plupart des projets ont une branche de développement active et une ou plusieurs branches de maintenance pour les versions publiées qui sont activement prises en charge.

Un système de contrôle de version minimise les frictions entre les développeurs. Lorsque les programmeurs travaillent sur des parties logicielles indépendantes, celles-ci sont intégrées presque par magie. Lorsqu’ils marchent les uns sur les autres, le système les remarque et leur permet de régler les conflits. Avec une configuration supplémentaire, le système peut informer tous les développeurs pour chaque changement engagé, en établissant une compréhension commune de la progression du projet.

Lorsque vous configurez votre projet, ne soyez pas avare : placez tous les actifs du projet sous contrôle de version. En plus du code source, incluez la documentation, les outils, les scripts de construction, les cas de test, les illustrations et même les bibliothèques. Avec le projet complet en toute sécurité rentré dans le référentiel (régulièrement sauvegardé), les dommages potentiels de perdre votre disque ou vos données sont minimisés. Mettre en place pour le développement sur une nouvelle machine consiste simplement à vérifier le projet à partir du référentiel. Cela simplifie la distribution, la construction et le test du code sur différentes plates-formes: sur chaque machine, une seule commande de mise à jour garantit que le logiciel est la version actuelle.

Une fois que vous avez vu la beauté d’un travail basé sur un système de contrôle de version, quelques règles vous rendront (vous et votre équipe) encore plus efficace :

• Valider chaque changement logique dans une opération distincte. Il est difficile de les démêler dans la fonction si vous modifiez plusieurs changements en une seule opération. Ceci est particulièrement important lorsque vous effectuez des refactorings à l’échelle du projet ou des changements de style, ce qui peut facilement masquer d’autres modifications.
• Accompagner chaque commit avec un message explicatif. Au minimum, décrivez succinctement ce que vous avez changé, mais si vous voulez également enregistrer la justification du changement, c’est le meilleur endroit pour le stocker.
• Enfin, évitez de créer du code qui brisera la construction d’un projet, sinon vous deviendrez impopulaire avec les autres développeurs du projet. La vie sous un système de contrôle de version est trop belle pour le gâcher avec des faux pas facilement évitables.

Qu’en pensez-vous ?

Dans le livre 97 Things every programmer should know, Gudny Hauknes, Kari Røssland, et Ann Katrin Gagnat nous partage leurs expériences en pair programming, et en réception du flux.

Voici leur article en français :

Imaginez que vous êtes totalement absorbé par ce que vous faites : concentré, dévoué et impliqué. Vous avez peut-être perdu la notion du temps. Vous vous sentez probablement heureux. Vous rencontrez le flux. Il est difficile à la fois d’atteindre et de maintenir le flux pour toute une équipe de développeurs car il y a tellement d’interruptions, d’interactions et d’autres distractions qui peuvent facilement le rompre.

Si vous avez déjà pratiqué le pair programming, vous êtes probablement familier avec la façon dont la programmation à deux contribue au flux. Si vous ne l’avez pas fait, nous voulons partager nos expériences pour vous motiver à commencer dès maintenant ! Pour réussir avec le pair programming, les membres individuels de l’équipe et l’équipe dans son ensemble doivent faire quelques efforts.

En tant que membre de l’équipe, soyez patient avec les développeurs moins expérimentés que vous. Affrontez vos peurs d’être intimidé par des développeurs plus qualifiés. Réalisez que les gens sont différents et appréciez-le. Soyez conscient de vos propres forces et faiblesses, ainsi que celles des autres membres de l’équipe. Vous pourriez être surpris par ce que vous pouvez apprendre de vos collègues.

En équipe, présentez le pair programming pour promouvoir la distribution des compétences et des connaissances tout au long du projet. Vous devez résoudre vos tâches par paires et faire pivoter les paires et les tâches fréquemment. Convenir d’une règle de rotation. Mettez la règle de côté ou ajustez-la si nécessaire. Notre expérience est que vous n’avez pas nécessairement besoin de terminer une tâche avant de la tourner à une autre paire. Interrompre une tâche pour la passer à une autre paire peut sembler contre-intuitif, mais nous avons constaté que cela fonctionne.

Il existe de nombreuses situations où le flux peut être brisé, mais où la programmation par paires vous aide à le garder :

• Réduisez le «facteur camion». Il s’agit d’une expérience de pensée légèrement morbide, mais combien de membres de votre équipe devraient être touchés par un camion avant que l’équipe ne soit incapable de terminer le livrable final ? En d’autres termes, à quel point votre livraison dépend-elle de certains membres de l’équipe ? La connaissance est-elle privilégiée ou partagée ? Si vous avez tourné des tâches entre des paires, il y a toujours quelqu’un d’autre qui a les connaissances et peut compléter le travail. Le flux de votre équipe n’est pas aussi affecté par le «facteur camion».
• Résoudre les problèmes efficacement. Si vous faites du pair programming et que vous rencontrez un problème difficile, vous avez toujours quelqu’un avec qui discuter. Un tel dialogue est plus susceptible d’ouvrir des possibilités que si vous êtes coincé par vous-même. Au fur et à mesure que le travail tourne, votre solution sera réexaminée et reconsidérée par la prochaine paire, de sorte que ce n’est pas grave si vous n’avez pas choisi la solution optimale au départ.
• Intégrez en douceur. Si votre tâche actuelle consiste à appeler une autre partie du code, vous espérez que les noms des méthodes, des documents et des tests sont suffisamment descriptifs pour vous permettre de mieux comprendre ce qu’il fait. Sinon, l’appariement avec un développeur impliqué dans l’écriture de ce code vous donnera une meilleure vue d’ensemble et une intégration plus rapide dans votre propre code. En outre, vous pouvez utiliser la discussion comme une opportunité pour améliorer la convention nommage, les documents et les tests.
• Atténuer les interruptions. Si quelqu’un vient vous poser une question ou que votre téléphone sonne ou que vous devez répondre à un courrier électronique urgent ou que vous devez assister à une réunion, votre partenaire de programmation peut continuer à coder. Quand vous revenez, votre partenaire est toujours dans le flux et vous allez vite le rattraper et le rejoindre.
• Amener les nouveaux membres de l’équipe à la vitesse de croisière. Avec le pair programming et une rotation appropriée des paires et des tâches, les nouveaux arrivants apprennent rapidement à connaître le code et les autres membres de l’équipe. Le Flow vous rend incroyablement productif. Mais c’est aussi vulnérable. Fais ce que tu peux pour l’obtenir, et garde-le quand tu l’auras !

Steve Smith, dans le livre 97 choses que tout programmeur devrait savoir, a écrit sur le thème du Don’t Repeat Yourself.

De tous les principes de la programmation, le Don’t Repeat Yourself (DRY) est peut-être l’un des plus fondamental. Le principe a été formulé par Andy Hunt et Dave Thomas dans The Pragmatic Programmer, et sous-tend de nombreuses autres bonnes pratiques de développement de logiciels. Le développeur qui apprend à reconnaître la répétition, et comprend comment l’éliminer par une pratique appropriée (ou une abstraction appropriée), peut produire un code beaucoup plus propre.

La duplication = gâchis

Chaque ligne de code qui entre dans une application doit être conservée et constitue une source potentielle de bogues futurs. La duplication gonfle inutilement la base de code, ce qui augmente les possibilités de bogues et ajoute une complexité accidentelle à l’application. Le gonflement que la répétition ajoute au projet rend également plus difficile, pour les développeurs travaillant sur le projet, la compréhension de l’ensemble du projet, voir même de s’assurer que les modifications apportées à un emplacement ne doivent pas nécessairement être effectuées ailleurs ils travaillent dessus. DRY exige que «chaque élément de connaissance doit avoir une représentation unique, sans ambiguïté, faisant autorité au sein d’un système».

Répétition des appels de processus par l’automatisation

De nombreux processus de développement de logiciels sont répétitifs et facilement automatisable. Le principe DRY s’applique dans ces contextes, ainsi que dans le code source de l’application. Les tests manuels sont lents, sujets aux erreurs et difficiles à répéter, de sorte que les suites de tests automatisées doivent être utilisées dans la mesure du possible. L’intégration d’un logiciel peut prendre beaucoup de temps et être sujette à des erreurs si elle est effectuée manuellement. Par conséquent, un processus de génération doit être exécuté aussi souvent que possible, idéalement à chaque enregistrement. Partout où des processus manuels pénibles peuvent être automatisés, ils doivent être automatisés et normalisés. L’objectif est de s’assurer qu’il n’y a qu’un seul moyen d’accomplir la tâche, et c’est aussi indolore que possible.

Répétition dans les appels logiques pour l’abstraction

La répétition dans la logique peut prendre de nombreuses formes. Copier-coller la logique if-then ou switch-case est parmi les plus faciles à détecter et à corriger. De nombreux modèles de conception ont l’objectif explicite de réduire ou d’éliminer la duplication de la logique dans une application. Si un objet nécessite généralement plusieurs choses avant de pouvoir être utilisé, cela peut être accompli avec un modèle abstrait ou un modèle de méthode d’usine. Si un objet a de nombreuses variations possibles dans son comportement, ces comportements peuvent être injectés en utilisant le modèle de stratégie plutôt que de grandes structures if-then. En fait, la formulation des modèles de conception eux-mêmes est une tentative de réduire la duplication des efforts nécessaires pour résoudre des problèmes communs et discuter de ces solutions. En outre, DRY peut être appliqué aux structures, telles que le schéma de base de données, ce qui entraîne une normalisation.

Une question de principe

D’autres principes logiciels sont également liés à DRY. Le principe ‘Once and Only Once’, qui ne s’applique qu’au comportement fonctionnel du code, peut être considéré comme un sous-ensemble de DRY. Le principe ‘Open/Closed’, qui stipule que «les entités logicielles doivent être ouvertes pour extension, mais fermé pour modification», ne fonctionne qu’en pratique lorsque DRY est suivi. De même, le fameux principe de responsabilité unique, qui exige qu’une classe ait «une seule raison de changer», repose sur DRY. Lorsqu’il est suivi en termes de structure, de logique, de processus et de fonction, le principe DRY fournit des conseils fondamentaux aux développeurs de logiciels et facilite la création d’applications plus simples, plus faciles à maintenir et de meilleure qualité. Bien qu’il existe des scénarios où la répétition peut être nécessaire pour répondre aux performances ou à d’autres exigences (par exemple, la dénormalisation des données dans une base de données), il ne doit être utilisé que lorsqu’il traite directement un problème réel plutôt qu’un problème imaginaire.

Dans tout programme, il y a potentiellement une gestion des erreurs à mettre en place.

Pete Goodliffe a écrit un article traitant de l’importance de la gestion de ces erreurs. En voici la traduction française.

Je me promenais un soir dans la rue pour rencontrer des amis dans un bar. Nous n’avions pas partagé une bière depuis un certain temps, et j’étais impatient de les revoir. Dans ma hâte, je ne regardais pas où j’allais. J’ai trébuché au bord d’un trottoir et fini à plat ventre. Eh bien, cela m’a bien servi de ne pas faire attention, je suppose.

Cela me faisait mal à la jambe, mais j’étais pressé de rencontrer mes amis. Donc, je me suis relevé et continué. En marchant plus loin, la douleur empirait. Bien que je l’avais d’abord rejeté comme un choc, j’ai rapidement réalisé qu’il y avait quelque chose qui n’allait pas.

Mais je me suis précipité au bar avec indifférence. J’étais à l’agonie au moment où je suis arrivé. Je n’ai pas eu une bonne soirée, parce que j’étais terriblement distrait. Le matin, je suis allé chez le médecin et j’ai découvert que j’avais fracturé mon tibia. Si je m’étais arrêté quand j’ai senti la douleur, j’aurais pu évité beaucoup de dégâts supplémentaires en marchant dessus. Probablement le pire matin ma vie.

Trop de programmeurs écrivent du code ressemblant à ma soirée désastreuse.

Erreur, quelle erreur ? Ce ne sera pas sérieux. Franchement. Je peux l’ignorer. Ce n’est pas une stratégie gagnante pour le code solide. En fait, c’est juste la paresse. (Le mauvais type.) Peu importe à quel point vous pensez qu’une erreur est dans votre code, vous devriez toujours le vérifier et toujours le gérer. À chaque fois. Vous ne gagnez pas de temps si vous ne le faites pas; vous stockez des problèmes potentiels pour l’avenir.

Nous signalons des erreurs dans notre code de plusieurs façons, y compris :

• Les codes de retour peuvent être utilisés car la valeur résultante d’une fonction signifie «cela n’a pas fonctionné». Les codes de retour d’erreur sont beaucoup trop faciles à ignorer. Vous ne verrez rien dans le code pour mettre en évidence le problème. En effet, il est devenu normal d’ignorer certaines valeurs de retour des fonctions C standard. À quelle fréquence vérifiez-vous la valeur de retour de printf ?
• errno est une curieuse C aberration, une variable globale distincte définie pour signaler une erreur. Il est facile d’ignorer, difficile à utiliser, et mène à toutes sortes de problèmes désagréables – par exemple, que se passe-t-il lorsque plusieurs threads appellent la même fonction ? Certaines plateformes vous isolent de la douleur ici; d’autres ne le font pas.
• Les exceptions sont un moyen plus structuré de signalisation et de gestion des erreurs. Et vous ne pouvez pas les ignorer. Ou pouvez-vous? J’ai vu beaucoup de code comme ça :
  

  try {
  // …do something…
  }
  catch (…) {} // ignore errors

  La grâce salvatrice de cette terrible construction est telle qu’elle met en évidence le fait que vous faites quelque chose de moralement douteux.

Si vous ignorez une erreur, fermez les yeux et prétendez que rien ne va mal, vous courez de grands risques. Tout comme ma jambe s’est retrouvée dans un état pire que si j’avais cessé de marcher dessus, labourer indépendamment des drapeaux rouges peut conduire à des échecs très complexes. Traiter les problèmes dès que possible. Gardez un court compte.

Ne pas manipuler les erreurs conduit à :

• Un code fragile et rempli de bugs difficiles à trouver.
• Un code non sécurisé. Les crackers exploitent souvent une mauvaise gestion des erreurs pour pénétrer les systèmes logiciels.
• Une mauvaise structure. S’il y a des erreurs de votre code qui sont fastidieuses à traiter continuellement, vous avez probablement une mauvaise interface. Exprimez-le afin que les erreurs soient moins intrusives et que leur manipulation soit moins onéreuse.

Tout comme vous devriez vérifier toutes les erreurs potentielles dans votre code, vous devez exposer toutes les conditions potentiellement erronées dans vos interfaces. Ne les cache pas, en prétendant que tes services fonctionneront toujours.
Pourquoi ne vérifions-nous pas les erreurs ? Il y a un certain nombre d’excuses courants.

Avec lesquels êtes-vous d’accord ? Avec lesquels êtes-vous contre ?

• La gestion des erreurs perturbe le flux du code, le rend plus difficile à lire et rend plus difficile l’identification du flux d’exécution «normal».
• C’est un travail supplémentaire, et j’ai une échéance imminente.
• Je sais que cet appel de fonction ne renverra jamais une erreur (printf fonctionne toujours, malloc renvoie toujours une nouvelle mémoire, si elle échoue, nous avons de plus gros problèmes …).
• Ce n’est qu’un programme de jouets et n’a pas besoin d’être écrit à un niveau de production digne.

Dans le livre Les 97 choses qu’un développeur devrait savoir, j’ai lu un des conseils les plus intéressants, qui est le fait de lire du code. Il a été écrit par Karianne Berg. Il rejoint le conseil sur les codes review.

Nous, programmeurs, sommes des créatures étranges. Nous aimons écrire du code. Mais quand il s’agit de le lire, nous sommes habituellement timides. Après tout, écrire du code est tellement plus amusant, et lire du code est difficile, parfois presque impossible. Lire le code d’autres personnes est particulièrement difficile. Pas nécessairement parce que le code des autres est mauvais, mais parce qu’ils pensent et résolvent probablement les problèmes d’une manière différente que vous. Mais avez-vous déjà pensé que lire le code de quelqu’un d’autre pourrait améliorer le vôtre ?

La prochaine fois que vous lirez du code, arrêtez-vous et réfléchissez un instant. Le code est-il facile ou difficile à lire ? Si c’est difficile à lire, pour quelle raison ? La mise en forme est-elle mauvaise ? Est-ce que la convention de nommage est incohérente ou illogique ? Plusieurs préoccupations sont-elles mélangées dans le même code ? Peut-être que le choix du langage interdit que le code soit lisible. Essayez d’apprendre des erreurs des autres, afin que votre code ne contienne pas les mêmes. Vous pouvez recevoir quelques surprises. Par exemple, les techniques de rupture de dépendance peuvent être bonnes pour un couplage faible, mais elles peuvent parfois rendre le code plus difficile à lire. Et ce que certaines personnes appellent le code élégant, d’autres appellent illisible.

Si le code est facile à lire, arrêtez de voir s’il y a quelque chose d’utile que vous pouvez en apprendre. Peut-être y a-t-il un modèle de conception que vous ne connaissez pas ou que vous aviez déjà eu du mal à implémenter? Peut-être que les méthodes sont plus courtes et leurs noms plus expressifs que les vôtres. Certains projets open source sont pleins de bons exemples de comment écrire un code brillant et lisible, tandis que d’autres servent d’exemples du contraire ! Découvrez une partie de leur code et jetez un œil.

La lecture de votre ancien code, à partir d’un projet sur lequel vous ne travaillez pas actuellement, peut aussi être une expérience enrichissante. Commencez avec vos codes les plus anciens et avancez jusqu’au plus récent. Vous trouverez probablement que ce n’est pas du tout aussi facile à lire que lorsque vous l’avez écrit. Votre code de début peut également avoir une certaine valeur de divertissement embarrassant, de la même manière que d’être rappelé de toutes les choses que vous avez dites quand vous buviez dans le pub la nuit dernière. Regardez comment vous avez développé vos compétences au fil des ans – cela peut être vraiment motivant. Observez les parties du code difficiles à lire et déterminez si vous continuez à écrire du code de la même manière aujourd’hui.

Donc, la prochaine fois que vous ressentez le besoin d’améliorer vos compétences en programmation, ne lisez pas un autre livre. Lire le code.