Lorsque de nombreuses applications informatiques se basent sur les mêmes frameworks, plugins ou autres modules similaires avec des rendus visuels différents, la question essentielle qui se pose est : Pourquoi faisons nous encore du codage informatique ?

Les différents fichiers de votre ordinateur peuvent être représentés de multiples façons. La façon dont la plupart des gens cherchent et trouvent leurs fichiers est dotée d’une interface visuelle, comme Mac Finder ou l’explorateur Windows. Mais vous pouvez également faire les mêmes actions sur ces fichiers en utilisant une interface basée sur des lignes de commandes comme le « Terminal ». Ce n’est ni plus ni moins que de multiples façons de présenter et d’interagir avec les mêmes informations. Autre exemple, les applications Web peuvent également être représentées de plusieurs façons : Un diagramme, des flux de données ou des Mockups (maquettes).

Mais les concepteurs de logiciels et d’applications, interagissent systématiquement qu’avec du code pur et dur. Mais est-ce que cette approche et cette manière de faire est la plus intuitive et la plus productive pour concevoir les logiciels ?

Un exemple frappant, est le programme de création de sons ou musiques électroniques Reason. Cet outil permet de glisser et de déposer des fils pour connecter les différents instruments, vous montrant exactement comment tout était connecté. Les fils visuels ont beaucoup plus de sens qu’un éventail sans fin d’écrans et de menus déroulant, qui est répondu dans les logiciel multimédias comme Adobe Flash.

Reason codage informatique

Reason codage informatique

En raison de l’interface de Reason, les utilisateurs ont une profonde compréhension de ce qu’ils font et peuvent rapidement créer des musiques sans utiliser du codage informatique complexes comme avec Adobe Flash et son langage de programmation ActionScripts.

Une mutation silencieuse

Je ne sais pas quand et comment cela s’est produit, mais à un moment donné, un «Informaticien» est devenu «Codeur» qui est devenu «Ingénieur logiciel». Mais la plupart de ce que font les « ingénieur logiciel », ce n’est pas l’ingénierie. Être ingénieur, c’est résoudre de nouveaux problèmes et réfléchir profondément pour relever des défis technologiques. C’est un travail intellectuel.

Des milliers de Framework générant automatiquement des classes CRUD ont déjà été construits. Ce problème à déjà été résolu. Mais pour une raison qui m’échappent, nous construisons encore plus d’applications, et souvent From Scratch (à partir de rien).

Une fois qu’un problème a été résolu, cette solution devrait être appliquée à d’autres problèmes similaires. Le pragmatisme voudrait qu’on mette en place un modèle avec des instructions de mise en œuvre et que celui-ci soit remis à un travailleur, ou à un ensemble de travailleurs, pour dupliquer le modèle en suivant les instructions au besoin. Nous ne disons pas à chaque travailleur dans une usine de voiture de concevoir une nouvelle voiture à partir de rien. Au contraire, nous donnons aux travailleurs un modèle, et on s’assure qu’ils leurs soit impossible de faire autrement et de produire des défauts ou des erreurs. Lorsque les instructions sont si faciles que n’importe qui peut les suivre, cela devient un travail automatisable. Plus que cela, il devient un travail « robotisable ».

Les ingénieurs devraient résoudre de nouveaux problèmes intéressants et ne pas concevoir les mêmes applications encore et encore. C’est un travail pour les robots.

C’est un fait vérifié que plus l’interface graphique d’une application informatique est originale et nouvelle, moins les gens comprendront rapidement comment l’utiliser. Il est donc contre-productif de réinventer à chaque fois le langage visuelle. Internet fonctionnerait beaucoup mieux si nous définissions un ensemble d’éléments communs visuels, puis les designers utiliseraient ces « normes » visuels en les combinant pour créer de nouvelles interfaces. Les feuilles de styles des pages webs devraient se générer en fonction de quelques mots-clés comme « Rendu musique, bleu, bonheur », ou « rendu business, professionnel, rose » ou « rendu mignon, enfants, attrayant ». À aucun moment, nous devrions taper du code HTML/CSS pour déplacer quelque chose de plus de 5 pixels.

Le codage informatique est vénéré par beaucoup comme le Saint Graal de l’ingénierie logicielle. Le code des vrais ingénieurs, disent-ils, ou le « codage » est-ce qui vous rend un excellent ingénieur. Beaucoup de personnes ont attaché leurs ego au codage. Ces personnes ont probablement besoin de revoir leur impact technologique réel, et je ne le dis pas avec ironie. Je faisais partie de ses gens-là :).

Mais connaître des instructions fantaisistes et avoir des compétences rudimentaires en codage ne vous rend pas un bon ingénieur, cela ne vous rend pas intelligent. Vous pouvez être un excellent codeur et un horrible ingénieur. Concevoir de meilleurs moyens, plus rapides, évolutifs et créatifs pour résoudre les problèmes réels, de personnes réelles est ce qui est le plus précieux, et cela deviendra de plus en plus vrai dans les années à venir.

Le codage permet les fautes de frappe. Plus que cela, il permet une «créativité» infinie. Mais la plupart des codes informatiques sont assez classiques. Les ingénieurs passent d’innombrables heures à traiter les fautes de frappe, l’indentation, la mise en page, les bugs, la discussion sur la nomenclature de code et les meilleures pratiques de codage. C’est absurde. Et c’est une perte de temps.

Ne pas réinventer l’eau chaude !

Aujourd’hui des alternatives pratique et basées sur du « rapid coding » émergent. Par exemple, GraphQL, outils intuitif de « requetage » des API sans passer par le codage d’un Backend lourd est en train de remplacer REST, et il le fera définitivement dans les années à venir. J’en suis sûre. Vous êtes-vous jamais demandé pourquoi avons nous besoin d’un Middleware agissant comme intermédiaire entre le client et la base de données ? Cela devrait être enlevé depuis longtemps, non ?

Algolia permet la recherche d’information dans une masse importante de données. Honnêtement, je ne sais pas comment ils font. Mais ce que je sais, c’est qu’un ordinateur est moins cher et mieux outillé pour optimiser les données structurées qu’un être humain.

Autre exemple, la conception des schémas de bases de données pour les applications. Les gens ne devraient plus écrire de schémas de base de données. Nous devrions être capable de mettre des données dans une pile et laisser les bases de données s’organiser automatiquement et s’optimiser en utilisant le Machine Learning. Avec les avancées actuelles en termes de capacité mémoire et de rapidité de calcul, la conception de base de données devrait être un processus d’optimisation, et non un processus d’ingénierie.

Les ingénieurs du monde entier récrivent des modules comme l’authentification, les tunnels d’achat, les messageries et d’innombrables autres fonctionnalités qui existent déjà. Et beaucoup d’entre eux se sentent probablement très fort à ce sujet.

Ce ne sont que quelques exemples de la façon dont les ingénieurs perdent du temps en reproduisant les mêmes fonctions de base encore et encore.

Et donc quelle serait la solution ?

Les Product Managers devraient faire en sorte de s’assurer que le produit développé effectue ce qu’il est censé faire, sans connaître comment coder le tout. Les seules choses qu’une entreprise devrait créer sont les fonctionnalités qui rendent leur produit unique. Tout le reste a déjà été construit dans d’autres applications et devrait être réutilisé. Et ceci est encore vrai avec la floraison de produit robuste, mature et surtout open-source.

Mais malgré la ferveur autour de l’open source, la plupart de ces projets ne sont pas maintenus ou ne sont pas utilisés au niveau des entreprises. Les entreprises finissent par promouvoir leur propre travail et font des brevets pour leur travails.

Actuellement je travaille avec mon équipe sur la refonte d’un grand portail Internet, avec beaucoup de règle métiers. Nous l’avons construit en utilisant des Framework PHP robuste, AngularJS et SolR comme moteur de recherche par indexation. Pourquoi s’entêter à aller refaire ce qui existe déjà ? Notre travail se concentre à ajouter la couche business et l’univers graphique, et non pas sur comment coder les couches plus basses pour interagir avec la base de données. Le temps de codage en est drastiquement réduit.

D’un autre côté, les entreprises ont un réel intérêt économique à réduire la barrière à l’entrée pour les travaux d’ingénierie logicielle, ainsi qu’à diminuer le nombre de personnes qu’ils doivent embaucher pour coder de nouvelles fonctionnalités. Si les applications Web deviennent plus faciles, plus de gens seront disponibles pour combler ces postes et les salaires diminuent.

Le constat est donc inévitable et amère. Les ingénieurs logiciels sont largement trop payés pour le travail qu’ils fournissent. En réalité, les ingénieurs logiciels ne sont pas plus intelligents ou mieux que tout autre type de travailleur. Avec la fin du codage informatique, la diversité augmentera. L’ingénierie reflètera le reste de la société, plutôt que de favoriser un petit sous-ensemble de personnes socio-économique.

Vous savez ce qui serait bien? C’est de stimuler l’innovation au sein des entreprises et d’inciter les ingénieurs logiciels non pas à faire des taches usuelles, mais de construire des éléments innovant dans les nouveaux domaines informatiques tel que le Bigdata, la réalité virtuelle ou la sécurité informatique. Ça c’est encore au stade d’ingénierie, mais pour combien de temps ?