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...
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
