Utilisés indifféremment à tort, les termes « programmation » et « codage » renvoient à des notions proches mais malgré tout différentes.
Coder est associé à la production pure et dure : l’informaticien est obligé de coder, c’est à dire d’écrire des instructions informatiques que l’ordinateur pourra exécuter. Vulgairement, on demande aux codeurs de « pisser du code ». Cette tâche consiste à transformer une feuille de route bien connue en langage informatique.
Programmer nécessite de prendre de la hauteur. À la différence du codeur, l’informaticien doit mettre en place l’ensemble du système qui résoudra le problème posé. Pour cela, il est impératif de connaître l’algorithmie (l’art d’écrire des programmes) mais aussi de connaître les différentes technologies indispensables pour construire un logiciel utilisable, ergonomique et qui vieillira bien.
Un informaticien peut prendre successivement la casquette du codeur et du programmeur et plus l’informaticien réalise du travail de haut niveau plus il passe du temps sur les tâches de programmation. Ainsi, on a logiquement la progression suivante :
L’apprentissage d’un langage
Au départ, l’amateur apprend un langage de programmation. À partir d’une grammaire et d’une orthographe précise imposée par le langage informatique sélectionné, le codeur réalise de petits programmes simples (souvent inutiles) ou de type mathématique.
Les premières instructions
Rapidement, les besoins de codage nécessitent de réaliser des branchements et des boucles. Concrètement, on a besoin de faire des « SI » / « SINON » et des « FAIRE TANT QUE ». Ces opérations en apparence anodines permettent de poser des bases solides et incontournables qui permettent de traiter la plupart des cas simples et de réaliser des calculs très intéressants avec une portée inconnue (sans connaître à l’avance le nombre d’opérations à traiter).
Un peu de Math ?
Vient ensuite l’étape ou l’informaticien se rend compte que certains problèmes sont ardus et parfois insolvable avec l’informatique. De grosses têtes se sont déjà pensés sur des cas similaires et la meilleure solution est connue. On attaque ici les problèmes liés à la rapidité d’exécution, aux tris, aux structures en forme d’arbre ainsi qu’à la récursivité. Les mathématiques ne sont pas loin et le mal de tête non plus…
Les premiers vrais programmes
Avec un tel bagage, il est enfin possible de s’atteler à la réalisation de vrais programmes. Essais et erreurs revenant régulièrement amènent bien souvent le programmeur à se pencher sur la notions de canevas, de moules réutilisables et à créer ses propres composants qu’il pourra reprendre dans différents projets.
Du côté de l’existant
Se rendant compte que réinventer la roue n’est vraiment pas l’idéal, le concepteur se tourne alors vers ceux qui ont déjà réalisé cette tâche. Des bibliothèques de code, des méthodes d’analyse, des méthodes de programmation avec un cadre structurant et des bonnes pratiques font gagner du temps.
Pourquoi ne pas les réutiliser ? Le travail devient plus simple. Plus besoin de perdre du temps sur les problèmes triviaux et communs. Il suffit de se baser sur le code et la logique solide que de plus intelligents que soi ont déjà construit.
Se reposer sur les autres, ça peut coincer
Finalement, les bibliothèques c’est bien mais ça pose des problèmes : que faire lorsque la techno change ? Et que se passe-t-il si un problème ne peut pas être résolu dans le cadre imposé par le moule choisi ? Et pour finir, comment régler ce pénible bug qui est lié à l’outil utilisé et qui empêche d’avancer ? Cette étape se fait généralement dans la douleur. Après avoir foncé et fait confiance au code d’autres personnes, le concepteur se demande si ce raccourci était au final si intéressant et si la rapidité initiale ne va pas se payer sur le long terme…
En parlant de suivi, c’est aussi maintenant que les bugs et les notions de qualité logicielle commencent à pointer le bout de leur nez. Coder c’est bien mais coder propre, durable et sans erreur fait gagner beaucoup de temps. On met alors en place des mécanismes de tests, de suivi de code, de résolution de problèmes, d’archivage des modifications et de leurs impacts. Ces aspects ne sont pas drole du tout mais sont nécessaires dans tout logiciel professionnel.
C’est quoi le problème déjà ?
Le temps est venu de prendre de la hauteur. Finalement, le code, ce n’est que du code. Quel est le problème à résoudre vraiment ? Existe-t-il des gens qui se sont penchés sur le problème et qui ont déjà trouvé une solution ? Peut-on la réutiliser ? Cette solution convient-elle à notre besoin ? Peut-on lui faire confiance, la faire évoluer, la détourner, se l’approprier et la personnaliser afin d’atteindre de façon élégante, robuste et durable le but fixé ? D’informaticien, le concepteur devient architecte.
Un logiciel au sein d’un écosystème mouvant
Arrivé à ce point, d’autres défis surgissent : comment interagir avec l’extérieur ? Une logiciel qui fonctionne seul dans son coin, c’est bien mais un logiciel qui sait communiquer avec les autres applications de l’entreprise c’est encore mieux. Et cela doit se faire de façon intuitive, transparente et être capable de gérer les cas spéciaux (les changements de l’autre côté – lorsque les outils avec lesquels on se connecte changent)…
Les notions de performance, de sécurité et de fiabilité des données ou encore de qualité prennent une autre dimension. Réaliser un outil qui servira à 3, 30 ou 300 personnes n’exige pas les mêmes ressources ni les mêmes fondations.
De simple codeur, on est successivement passé par les métiers d’analyste programmeur, d’informaticien et d’architecte logiciel.