Mon expérience de développeur est relativement jeune (cela fait maintenant 1 an que j’ai commencé mon premier job chez DoYouBuzz), mais s’il y a bien quelque chose que j’ai compris sur le code c’est qu’il est, avant tout, personnel. Grammaires de langage, conventions, algorithmes, snippets de code et linters sont autant d’outils qui cadrent l’écriture de code, et pourtant il reste une infinité de liberté. Vous pouvez suivre toutes les conventions de codage que vous voulez, il y aura toujours une petite partie de vous dans votre code. Mais s’il vous appartient, vous en êtes aussi responsable. Il est de votre devoir de développeur de prendre soin de votre code.

L’écriture de code c’est de la poésie. Vous avez à votre disposition toutes les figures de style que vous voulez pour transformer une partition de caractères ASCII ennuyeux en poème. Vous pouvez tout à fait vous laisser aller à quelques Yoda Conditions. Vous êtes libres de concentrer votre code ou au contraire opter pour la légèreté et les retours à la lignes. Vous serez peut-être un amateur des return et en placerez dès que vous pouvez dans vos fonctions. Inversement vous vous lancerez dans une mise en abîme de if imbriqués. C’est à vous de choisir si vous préférez une approche fonctionnelle ou plutôt impérative. Dans tous les cas votre code vous appartient.

Construisez vous votre environnement de création. Ce n’est pas avec l’application que vous créez mais bien avec votre éditeur de texte que vous passerez le plus clair de votre temps. Tout comme le poète a besoin d’un cadre stimulant et d’une plume avec laquelle il est à l’aise, vous vous devez de trouver l’éditeur qui vous convient le mieux. Certain préféreront un Eclipse bien configuré avec toutes les fonctionnalités dont ils ont besoin à portée de souris. D’autres préféreront l’élégance du code pur et le confort du clavier et choisiront plutôt un Vim avec quelques plugins et toutes les commandes utiles en tête.

Soyez conscient. Vous êtes libres de faire ce que vous voulez de votre code, cependant, vous devez impérativement être conscient des conséquences de vos choix. Apprenez à fond les langages que vous manipulez et adaptez votre style au langage et à la plateforme pour laquelle vous écrivez. Sachez, par exemple, qu’une approche fonctionnelle va être globalement plus couteuse en mémoire qu’une approche impérative. Comprenez que vos collègues n’apprécieront pas forcement de relire des yoda conditions. Votre code peut être original, mais jamais au détriments des performances ou de la relecture.

N’ayez pas peur de la suppression. Supprimer des bouts de code est peut-être le sentiment le plus grisant du code. Supprimer du code, ça peut vouloir dire deux choses : soit la fonctionnalité est enlevée, soit vous avez réussi à factoriser la fonctionnalité en question. Dans les deux cas votre application ne s’en portera que mieux et votre code également. Dans le code, et tout particulièrement pour le web, moins de code veut dire un temps de chargement plus faible et moins de bugs potentiels. Je pense vraiment qu’une des choses qui qualifient un bon développeur et de pouvoir faire autant avec moins. Ne soyez plus ce collégien qui essaye absolument de remplir ses 5 pages de dissertation parce que la prof a dit “entre 5 et 10 pages” (oui, j’ai fait ça !).

Relisez et remaniez. Ne laissez jamais un bout de code dormir trop longtemps. Personne ne fait les choses parfaitement du premier coup. allez relire régulièrement du code que vous avez fait hier, la semaine dernière, le mois dernier ou encore l’année dernière. Vous pourrez être surpris par ce que vous lirez. Vous vous direz surement que vous avez bien changé depuis. C’est bon signe : c’est que vous progressez :) N’hésitez pas, à ce moment là, à réécrire ce qui vous choque. Dans mes projets persos, qui n’ont donc pas de deadlines (ce blog par exemple), je prends souvent le temps de refaire une fonctionnalité de A à Z. Assez régulièrement je me rends compte que je pouvais la faire bien plus simplement.

Réfléchissez. On sais tous qu’il ne faut pas attaquer un problème de plein fouet sans y avoir réfléchi un minimum. C’est très vrai, mais il y a une réflexion dont on parle moins : la réflexion à posteriori. Quand vous pensez le code avant de l’attaquer, vous savez ce qu’il doit faire mais pas ce qu’il va faire. Une fois le développement fini, vous avez précisément en tête les mécanismes de votre code ainsi que les détails de la fonctionnalité. C’est à ce moment que vous pourrez opérer suppression de code et remaniement. J’ai souvent entendu dire que lorsqu’on créé un bout de code, il ne faut pas penser optimisation dans un premier temps. Il est préférable de coder de façon (presque) naïve une première fois, puis ensuite d’identifier les bouts de code qui peuvent être factorisés/supprimés. Faire le contraire risque de vous embrouiller l’esprit au point de ne plus avoir en tête la fonctionnalité que vous développez. Les tests sont également là pour vous aider à préciser votre idée et surtout à valider vos futurs réécritures, utilisez les !

Soyez curieux. Une dernière chose, et pas des moindre : la curiosité. Quand quelque chose vous intrigue, que vous vous demandez comment ça marche, voyez y une opportunité de creusez plus loin, de progresser. L’Open Source (sous la forme de github par exemple) est une source d’informations et d’inspirations infinie ! Allez voir, par exemple, comment jQuery a réussi à abstraire et unifier les apis du DOM des différents navigateurs. C’est en lisant le code d’autres personnes que vous trouverez de l’inspiration et des façon de faire complétement différentes des vôtres. Apprenez d’autres langages de programmation qui n’ont rien à voir avec ce que vous faites, ça vous rendra plus intelligent. A mon avis, la curiosité est ce qui fait/fera d’un bon développeur, un excellent développeur.

Les quelques points que je traites dans cet article sont des réflexions qui me sont propres et qui me sont chères. Je n’ai aucune prétention de diffuser une quelconque doctrine du bon petit développeur, je n’ai clairement pas assez d’expérience pour pouvoir en faire autant. Cependant si un seul de ces points peut vous offrir une piste de réflexion si minime soit elle, alors ma mission est réussie.

Alors prenez bien soin de votre code et n’hésitez pas à réagir ;)