Voici la troisième partie de la publication en 5 parties de la traduction d’un article de Ben Watson publié le 20 janvier 2008 sur son blog : Top 5 Attributes of Highly Effective Programmers. Ma traduction est amateur, mais vous permettra de profiter des idées de Ben Watson dans votre langue maternelle.
Il propose, et développe 5 qualités essentielles qui distinguent le bon développeur du mauvais :
- Humilité
- Aimer apprendre (2e partie)
- Amour du détail (3e partie)
- Adaptabilité (4e partie)
- Passion (5e partie)
—
Amour du détail
Développez des logiciels avec les technologies d’aujourd’hui est une affaire de détails. Peut-être que dans 100 ans, le logiciel va arriver à un point où il pourra s’écrire lui-même, être complètement découpé en composants interopérables, auto-documenté, auto-testé et ensuite…il n’y aura plus de développeurs. Mais avant que cela n’arrive (si jamais cela arrive), prenez l’habitude d’être attentif à tous les détails.
Pour illustrer : prenez une fonctionnalité de n’importe quel logiciel, et essayer de penser à tout le travail qui a dû être effectué pour la modifier de quelque manière. Pour n’importe quoi de pas primordial, vous pourriez probablement arriver à une liste d’une centaine d’opération mineures : modifier l’interface graphique (ce qui inclut les images, le texte, la localisation, les événements, la customisation, etc.), les tests unitaires, les algos, l’interaction avec les composants en relation, et tout cela de nouveau divisé en étapes mineures.
J’ai toujours trouvé que les plans étaient inutiles, mais la planification est indispensable. – Dwight Eisenhower
Voici un problème cependant : quelques humains peuvent garder chacune des tâches dans leur tête, durant un certain temps. Heureusement, le souci du détail ne signifie pas nécessairement être capable de suivre mentalement chacun des détails. Cela signifie que vous développez une approche mentale pour les gérer. Par exemple, les étapes pour modifier une partie d’un logiciel pourraient être :
- Comprendre globalement ce que le code fait et pourquoi
- Examiner toutes les dépendances et interactions en relation avec ce code
- Avoir une bonne représentation mentale de comment tout cela s’assemble
- Evaluer les conséquences des modifications de la fonctionnalité
- Mettre à jour le code qui le nécessite (et répéter ce cycle pour chacun des composants)
- Mettre à jour les éléments auxiliaires qui peuvent dépendre de ce code (builds système, installeurs, tests, documentation, etc.)
- Tester et recommencer
Un exemple : J’étais en train de travailler sur une portion de code. J’ai réalisé qu’il y avait plusieurs tâches à effectuer immédiatement après avoir fini ce que j’étais en train de faire. Si je ne les faisais pas, je détruisais le logiciel. Si j’essayais de me souvenir de toutes, j’en aurais sûrement oublié une en route. J’avais donc plusieurs choix :
1.Reporter à plus tard, en essayant de me rappeler de toutes
2.Les effectuer immédiatement
3.Reporter à plus tard, après les avoir écrites.
Chaque possibilité est utile selon les circonstances. Bon, peut-être pas la première. Je pense que c’est idiot d’échouer dès le départ et de prendre de mauvaises habitudes. Si les tâches secondaires sont courtes, facile et bien comprises faites les immédiatement et revenez à votre tâche initiale.
Quoi qu’il en soit, si vous savez qu’elles nécessitent beaucoup de travail, mettez les par écrit. Je préfère un bloc-notes tout simple dans tous les cas, mais des fichiers textes, les tâches Outlook, les notes, OneNote, un système de bug tracker et les autres méthodes peuvent aussi travailler à rendre cela possible.
Plus vous avez d’expérience, plus vous serez capable de capter tous les détails dont vous avez à vous soucier. Vous les analyserez plus vite, mais vous aurez toujours besoin, d’une manière ou d’une autre de garder la trace de ce que vous ferez après. Il y a tout simplement trop de détails. Une organisation efficace est une capacité clef pour d’un bon ingénieur logiciel.
Un autre aspect auquel prêter attention est la pensée critique (ndt : critical thinking). La pensée critique implique un scepticisme de bon aloi sur tout ce que vous faites. C’est particulièrement important quand vous examinez les détails de votre implémentation, de vos designs ou plans. C’est la capacité de sortir de tous ces détails ce qui est important, ce qui est correct, ou au contraire, ce qui est nul et doit être abandonné.Cela vous guide également quand vous devez utiliser une méthode de développement connue, et quand vous devez venir avec une nouvelle solution à une problème délicat.
Opensource et médias sociaux 