1 - Lire le manuel
C’est un classique, mais il ne faut jamais l’oublier. Attention, il n’est pas question ici de lire de couverture à couverture une brique décrivant un langage de programmation. Pour moi, le délicieux acronyme « RTFM » signifie plutôt d’éviter d’entrer immédiatement notre problème dans Google en espérant une solution immédiate. Souvent, il suffit de prendre le temps de jeter un coup d’œil dans la description des fonctions que l’on utilise pour comprendre notre problème. Il est vrai qu’il est parfois plus long de chercher dans un manuel, mais vous y découvrirez de nombreux avantage.
- Vous saurez le «pourquoi » de votre problème et non seulement le : «comment » faire pour le régler.
- Vous vous familiariserez rapidement avec la documentation de vos outils. Cela vous permettra de trouver beaucoup plus rapidement de l’information lorsque vous rencontrerez des problèmes plus complexes.
- Cela vous donnera la chance de trébucher sur des fonctions ou des comportements de l’outil en question que vous n’auriez jamais découvert autrement.
- Finalement, cela vous apportera une vue beaucoup plus globale du fonctionnement de ce que vous utilisez comme langages, api, framework etc. Vous serez capable de régler certains problèmes avant même qu’ils ne se posent.
Sans mettre de côté toutes les ressources qui sont mises à notre disposition: blog forums ect. , Le premier recours devrait toujours être la documentation qui, ceci dit, est spécifiquement rédigé pour nous : développeur.
2 - Questionnez vos habitudes ainsi que les « best practices » dont vous avez entendu parler.
En temps que développeur vous aimez utiliser des standards qui ont fait leurs preuves, et c’est une excellente chose. Cependant, gardons en tête que la méthode parfaite de coder n’existe pas. En réfléchissant sur les normes déjà établies et en comprenant les motivations qui ont précédés ces normes vous serez capable de repousser leurs limites.
Certains analystes iront même jusqu’à détruire tout ce que l’on connait d’une méthode pour en reconstruire une nouvelle encore plus solides. Soyez audacieux lorsque vient le temps de rendre votre code encore plus propre, plus efficace et plus clair que la norme le prévoit. Qui sait, peut-être un jour ce sera votre tour d’écrire cette norme.
3 - Codez et commentez toujours comme si vous alliez réutiliser votre code
On passe notre temps à écrire du code qui accompli différente tâche mais on réutilise souvent les même manières de régler des problèmes. Lorsqu’une situation semblable apparaît, la première chose que nous faisons c’est d’ouvrir du vieux code pour s’en inspirer; Tout le monde fait cela. C’est normal et même une façon plutôt efficace de travailler. On ouvre le fichier et on se met à copier et coller sporadiquement du code. Malheureusement, à chaque fois il nous faut renommer toutes les variables, changer le commentaire, les noms de fonctions parfois même des objets tout entier.
Pourquoi ne pas faire un effort la première fois qu’on écrit une fonction?
- Identifiez les éléments qui sont générique à toutes vos applications et donner leurs des noms liés à leur fonctionnalité plutôt qu’à leurs contextes. (ex : $user au lieu de $client_surfer)
- Écrivez des commentaires relatifs à leur environnement direct et non au contexte global de l’application.
ex :
//Comparer les deux tableaux pour en extraire les rangé communes au lieu de:
// Extraire les rapports financiers qui sont présents dans les tableaux $mes_rapport_favorit et $certain_rapport_du_site
Vous sauverez un temps fous à ne pas être obliger de renommer vos variable ou commenter de nouveau votre code ou pire encore, laisser des commentaires qui ne corresponde pas à votre code. Faites toutefois attention de ne pas tomber dans le piège de devenir trop vague dans vos description. Il n’y a rien de pire qu’un commentaire confus.
4 - Faites des prototypes
N’hésitez pas à essayer du code dans un environnement test et d’expérimenter plusieurs façons d’atteindre un même objectif. Parfois vous tomberez sur une solution plus rapide, plus performante ou plus simple pour atteindre votre but. Vous décèlerez les parties les moins robustes de vos fonctions ou objets.
La chose la plus intéressante dans le prototypage est que vous vous attacherez beaucoup moins à votre code. Vous vous sentirez beaucoup plus à l’aise de complètement recommencer une partie de votre travail. Cela peut paraître bête mais lorsque l’on implémente une fonctionnalité et que l’on découvre qu’elle ne répond pas à nos attentes, on a tendance à la « patcher ». S’il s’agit d’un prototype, vous vous ferez un plaisir de tout démonter pour mieux le reconstruire au lieu de rabouter ce qui existe déjà.
5 - Suivre des blogues et des Twitter ce n’est pas juste pour les designers
Tous les designers font un tour de leurs blogues préférés et des dernières tendances sur le web pour s’inspirer avant d’entamer une tâche. La construction d’interface graphique, les méthodes de travaille qu’ils utilisent ainsi que leurs outils sont en constante évolution.
Une seconde… c’est vrai aussi pour nous non? Nous aussi nous avons besoins de savoir ce qui se fait de mieux dans notre domaine, de nous tenir à jour! « Les blogues, c’est pour les créatifs nous on programme. » : est un stéréotype qu’il faut voir disparaître. Souvenez-vous que pour créer une fonctionnalité, il faut être inventif et inspiré. Il y a des tonnes de programmeurs et d’analyste reconnus qui ont un blogue et un twitter, il est peut-être temps que vous fassiez vos devoirs!
Voici quelques blogs qui pourraient vous intéresser :
- https://code.google.com/
- https://perishablepress.com/
- https://code.tutsplus.com/
- https://www.catswhocode.com/blog/
- https://www.thecodersblog.com/
- https://www.lullabot.com/articles
- https://www.smashingmagazine.com/
Évidemment il y en a des dizaines d’autre qui valent la peine d’être consulté, cette liste n’est qu’un point de départ. Pour ce qui est de twitter je vous suggère de commencer par suivre les éditeurs des logiciels, librairies, framework et langages que vous utilisez couramment pour vous tenir au courant des sorties des nouvelles versions.
Une dernière pensée pour la route :
En tant que développeur, ne pas savoir comment régler certaines situations fait partie de notre quotidien. Dans notre métier, on se démarque non pas par ce que l’on sait déjà faire, mais parce que l’on est capable d’accomplir.