De façon traditionnelle, l’exercice en tant que professionnel de l’informatique en général est conditionné par le passage du postulant par une formation qui mène à un diplôme dans le domaine. La France est un bel exemple de ces pays où l’accès à bon nombre de postes de développeur informatique nécessite de présenter au futur employeur un parchemin qui correspond à 4 années d’études supérieures à minima (bac+4, bac+5, doctorat, etc.). L’obtention d’un emploi nécessite de faire valoir le diplôme adéquat ou du moins celui que le futur employeur mentionne sur l’offre. De façon générale, le cursus universitaire apparaît donc comme une sorte de préparation aux défis qui attendent le postulant sur le terrain. Seulement, l’auteur de la plateforme serverless Binaris lui attribue un certain nombre de tares dont la propension à pencher sur la théorie plutôt que sur des aspects susceptibles de faire de ses produits d’excellents praticiens.
« Voici quelques-unes des choses que j’aimerais que l’on enseigne à l’université plutôt que de s’appesantir sur de la théorie pure » :
1. Éviter de baser ses décisions sur le nombre de lignes de code
Le nombre de lignes de code est l’une des métriques autour desquelles les discussions d’équipes de développement en informatique tournent souvent. Pour un projet donné, il peut être question de savoir s’il est mieux d’avoir une grosse ou une petite base de code (en termes de nombre de lignes de code). Le développement de l’auteur de la plateforme Binaris laisse filtrer que ce type de questionnement est quasi inutile lorsqu’il souligne que « le faire serait similaire à évaluer la qualité d’un livre sur la base du nombre de lignes de code. »
De façon brossée, il précise qu’il n’est pas nécessaire de compter, mais d’écrire autant de lignes de code que nécessaire tout en restant cohérent avec quelques principes : le code est cohérent ; le code est autodescriptif ; le code est bien documenté ; le code s’appuie sur des fonctionnalités modernes et stables ; le code n’est pas inutilement complexe, etc.
2. Il n’y a pas de « bons » et de « mauvais » langages de programmation
Dans un parallèle qu’il établit avec une boîte à outils, il montre que chaque langage de programmation introduit un jeu de compromis avec lequel chaque développeur doit traiter. En d’autres termes, il n’y a pas de
« bons » et de « mauvais » langages de programmation. Il y aurait simplement un choix à effectuer et même s’il souligne qu’il y a, dans la plupart des cas, peu de situations pour lesquelles le choix du langage est une question cruciale, il dresse une liste de points à prendre en compte pour l’atteinte de cet objectif : la disponibilité des ressources en ligne ; la rapidité de développement ; la tendance à générer des bogues ; la qualité et l’étendue de l’écosystème de bibliothèques ; les performances, etc.
« Il y a aussi un type d’association que les tendances actuelles suggèrent fortement. Si vous travaillez dans le domaine de la science des données, il serait réaliste d'utiliser Python, R ou Scala (peut-être Java). Si c'est un projet pour passer du temps, utilisez le langage qui vous rendra le plus heureux. Il n'y a qu'une seule règle non négociable sur laquelle je m'appuie. Je refuse d'utiliser des langages qui n'ont pas la plupart des problèmes que je vais rencontrer directement résolus sur StackOverflow. Ce n'est pas que je ne peux pas le résoudre, c'est juste que ce n'est pas la peine d'y consacrer du temps », ajoute-t-il
3. Lire le code d’autres développeurs est une activité difficile
« Lire le code des autres donne presque l'impression de lire une langue étrangère. Même si vous êtes à l'aise avec le choix du langage de programmation de l'auteur, vous devez quand même vous adapter à différents styles et choix d'architecture. Cela suppose également que l'auteur a écrit un code cohérent et fiable - une cible qui peut être atteinte ou manquée », écrit-il laissant ainsi filtrer que la lecture du code d’autres développeurs n’est pas une activité aisée. Pourtant, c’est une activité qui meuble une bonne partie du quotidien du développeur qui travaille au sein d’une équipe. Il faut arriver à maîtriser cet exercice et le développeur de la plateforme Binaris suggère de faire de la revue de code sur des plateformes comme GitHub pour aiguiser cette aptitude.
« La seconde astuce qui peut vous aider à lire le code d'autres personnes est un peu plus unique. C'est une technique que j'ai mise au point et elle a vraiment réduit le temps qu'il me faut pour me sentir à l'aise avec du code d'autres développeurs. Après avoir regardé le style du code que je veux lire, je commence par ouvrir vi et à écrire du code dans le style utilisé par le projet. Lorsque vous écrivez du code dans le nouveau style, vous améliorerez également vos compétences en lecture. Le style vous semblera moins étranger, comme vous l'avez déjà expérimenté. Même lorsque je parcours un projet aléatoire sur Github, je m'y adonne rapidement », ajoute-t-il.
4. Garder à l’esprit qu’il n’y a pas de code « parfait »
Dans son billet, l’auteur de la plateforme Binaris a aussi tenu à recadrer l’idée selon laquelle tous les programmeurs en industrie écrivent du code « parfait ». Il insiste sur ceci que même dans ces sphères où l’on a affaire à des programmeurs très expérimentés, le salut passe par les revues de code.
« Je travaille avec une équipe d'ingénieurs vraiment brillants. Ce sont quelques-uns des programmeurs les plus compétents et les plus confiants dont on puisse s'attacher les services. Chaque membre de notre équipe (y compris moi) aurait une crise de panique totale si quelqu'un suggérait de faire passer du code non révisé. Même si vous pensez être le prochain Bill Gates vous ferez des erreurs. Je ne parle même pas d'erreurs logiques, je parle de fautes de frappe, de caractères manquants. Je parle de choses pour lesquelles on a besoin d'une autre paire d'yeux », écrit-il.
5. Travailler comme développeur ne veut pas dire 8 heures de programmation par jour
Dans bien de pays au monde, la journée de travail a une durée de 8 heures. Pour un employé de bureau, on arrive au lieu de service, s’installe sur un siège devant un ordinateur et se lance dans ses activités. Mais, lesquelles ? De quoi s’agit-il dans la réalité ? De « 8 heures de travail » ou « 8 heures au travail » ? En d’autres termes, pour combien de temps les travailleurs sont-ils productifs sur une journée de travail ?
« Très peu de personnes sont capables d’écrire du code pendant plus de 4 heures par jour. Les personnes qui ne sont pas d'accord avec cette affirmation sont soit l'exception à la règle, soit travaillent dans des entreprises qui devraient mieux les traiter. La programmation est une tâche exigeante sur le plan mental. Il est tout à fait déraisonnable de s'attendre à ce que quelqu'un écrive du code 8...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
). Il est donc implicite que la personne qui va relire le code n'aura pas la même réflexion et la même image d'ensemble du code que le développeur précédent. Un code qui peut nous paraître simple à "déchiffrer" peut paraître tout aussi compliqué à autrui. Je pense que peu importe qui écrit du code, il sera toujours difficilement intégrable à notre propre réflexion. 
Envoyé par Gnomial
