Quelques bonnes pratiques

1. De l’importance du socle

Toute compétence technique doit se baser sur des compétences théoriques fiables et assurées. Le problème est que l’informatique et ses pratiques changent non seulement vite, mais de plus en plus vite.

Il est appréciable d’être compétent dans la technologie du moment, car alors les sollicitations sont nombreuses, les postes souvent bien rémunérés et la sensation d’excellence dans les dernières avancées de son domaine de prédilection est grisante. Mais cette mise à niveau est d’autant plus difficile à vivre quand la mode vient à passer. Or, en tant qu’amateurs de technologies, les développeurs qui se flattent de leur rationalité font souvent les meilleures victimes de toute mode irrationnelle.

Ainsi, le meilleur investissement technique d’un développeur reste d’avoir des bases solides. Cela aide à acquérir toutes les autres compétences, à évaluer les technologies et les conceptions, et à trouver les meilleures réponses où elles se trouvent avec les mots-clés les plus pertinents. De bonnes bases sont la condition sine qua non d’un travail bien fait et l’assurance d’être reconnu et respecté par ses pairs.

2. Structures de données et algorithmes communs

La première des bases est la maîtrise des structures de données. Les ouvrages dédiés à la programmation se focalisent souvent sur ce sujet, et avec raison. De nombreux développeurs (et clients !) estiment avoir fait le tour du problème une fois celui-ci modélisé.

Il ne faut pas tomber dans ce piège, mais force est de reconnaître que l’architecture d’un programme devient de plus en plus difficile à changer avec le temps, tout simplement parce que la modification d’un élément de base implique des modifications dans tous les projets qui reposent...

1. DRY

DRY signifie Don’t Repeat Yourself : ne vous répétez pas. Chaque ligne de code que vous écrivez représente un bogue potentiel dans l’application, une possible incompréhension pour une future personne qui la lira, du code supplémentaire à maintenir, etc. On ne s’en rend pas forcément compte dans cette quête à la fonctionnalité dans laquelle on peut parfois écrire trop vite pour atteindre l’objectif plus tôt. D’où l’importance de bien avoir cette règle en tête.

Se répéter est très (trop) facile dans le monde de l’informatique. Le copié-collé est à portée de raccourcis-clavier aisés à utiliser, la taille des disques durs permet une dépense sans compter des octets, les processeurs rapides avalent les instructions tellement vite qu’on ne perçoit plus les petits détours logiques inutiles. Mais encore une fois : un code qui fonctionne peut être un véritable cauchemar à maintenir et à déboguer.

De façon générale : moins de code vous écrivez, moins de problèmes vous risquez. 

En programmation orientée...

1. Rédiger des conventions d’écriture

Personne n’aime...

1. Débogage

Du code, ça produit des bogues. Il est illusoire et utopique d’exiger d’un développeur un code sans aucun bogue. Un code de qualité n’est pas uniquement un code qui contient peu de bogues, mais aussi un code qui permet de les traquer et les éliminer rapidement.

Bien sûr, il existe différents outils et méthodes pour déboguer. Une heuristique qui a fait ses preuves consiste tout simplement à traquer le bogue dans les derniers éléments de code modifiés (parce que les tests ont confirmé que les dernières versions étaient parfaites). Parfois, le problème se cache dans des hypothèses établies durant la genèse du logiciel. Il faudra alors aller le chercher en profondeur, avec en crainte de fond la remise en cause de l’architecture complète de l’application.

Chaque méthode de production de code (IDE, framework, langage) possède ses outils de débogage, et chaque couche logicielle également. On n’utilise pas les mêmes outils pour détecter des problèmes d’accès au système de fichiers ou de surcharge de la RAM, ni les erreurs réseau ou les interblocages. Là encore, regardez ce que proposent votre communauté et votre équipe, et exploitez les compétences particulières de chacun.

2. Traces

Une pratique reste commune à presque toutes ces méthodes et tous ces outils de débogage : tracer ce qui se passe et en écrire un résumé dans un fichier afin...

1. Savoir poser des questions

Dans l’informatique comme dans l’histoire de la science et tout autre métier, pratiquer l’art de poser des questions est aussi le meilleur moyen d’y répondre.

Ce qui est surprenant devrait être investigué.

Ce qui est à la base des raisonnements devrait être investigué.

Ce qui est vrai depuis trop longtemps sans qu’on se souvienne pourquoi devrait être investigué.

Étudier le problème inverse de celui que l’on examine est intéressant.

Et... les questions que l’on pose sont-elles les bonnes questions à poser ?

La communauté des « hackers » a souvent des réactions épidermiques aux questions trop simples, trop fréquentes, mal formulées. Elles irritent et se voient plus facilement rejetées....

1. L’humain

Ce n’est pas une discussion avec un collègue ou un manager qui explique votre promotion ou qu’on vous attribue des projets : c’est surtout la confiance que vous inspirez, la sympathie dont vous faites preuve, le respect que l’on vous porte. En plus des prérequis techniques, votre évolution se base également sur le social et l’humain. Ne perdez jamais cela de vue.

Indépendamment d’un « bon vouloir », il y a aussi le pouvoir : une entreprise en chute libre peut vous offrir des challenges temporaires, mais ne peut pas vous offrir de croissance à long terme.

Quelle que soit la situation, lorsque vous discutez avec votre direction, sachez écouter et être patient : vous disposez d’une connaissance rare et d’informations que votre interlocuteur n’a pas. Ceci peut le mettre mal à l’aise, voire le faire se sentir vulnérable ou dépassé. Prenez le temps de comprendre leurs demandes : cela vous permettra de repérer leurs préoccupations, de les apaiser si possible, et, même si vous ne parvenez pas à résoudre le problème, d’éviter d’aggraver la situation.

Réfléchissez à ces questions et appliquez-en les enseignements, car c’est comme cela qu’on vous verra...