Tous les articles par jboucher

Timsoftien depuis 2005. Passionné par le développement logiciel en général et le libre en particulier, je sévis au coeur de l'Auvergne ou j'ai élu domicile depuis 2012. J'aime me promener a la frontière des mondes, dans des coins rares et magnifiques, quelque part entre l'informatique généraliste, le développement web, et l'admin sys et réseau. Mon goût pour l'écriture et Internet me feront sans doute souvent venir vous raconter des histoires sur le blog Timsoft. Bonne lecture !

Le développement logiciel, un art atemporel ?

 

En navigant sur le net, il vous est sans doute arrivé de tomber nez à nez avec un lien qui ne pointe plus vers son contenu. Une page d’erreur 404 ou bien même aucune page d’erreur du tout, comme si le site entier s’était lui-même volatilisé. On dit souvent entre nous, « tiens, ce lien est « mort »… ». Un lien à jour est vivant, un lien obsolète est mort. Et si c’était la même chose pour les logiciels ?

Lorsqu’un projet de développement débute, c’est en général l’effervescence ; les chefs de projets sont tout excités à l’idée de découvrir le métier du client et répondre à son besoin, les développeurs-euses sont excité-es à l’idée de « créer » un nouveau logiciel avec de nouvelles technos toutes neuves et ainsi expérimenter de nouveaux paradigmes et architectures (chacun son truc, comme on dit..). La joie de l’ouverture des cadeaux de Nowël, en somme. Le logiciel est alors en phase de gestation.

A la première livraison, c’est l’accouchement. Vous êtes fiers de votre nouveau bébé. Vous y avez mis tout votre cœur, avec du code tout beau tout propre. Vous le mettez au bain à coup de refactoring tous les jours. Les commentaires ont du sens, les nouvelles technos sont « super-sympas », même si vous avez pu à cette occasion y découvrir des inconvénients majeurs. C’est pas grave, on fait avec. Et le clou du spectacle, il y a même des tests unitaires qui garantissent la non régression des fonctionnalités de base.

Puis le projet grandit. Votre bébé est devenu grand. Au départ, vous ne saviez pas trop ce qu’il allait devenir. D’autres développeurs ont rejoint l’équipe et lui ont appris à faire de nouvelles choses. A bien y regarder, il a aussi pris de l’embonpoint. Il ne fait pas encore le café, mais il n’en est pas loin. Les technos (plus toutes jeunes) utilisées sont agréables, mais leurs inconvénients vous font de plus en plus râler. Ce n’est pas grave, il fonctionne toujours bien, il est en production, et les mises à jours et les évolutions sont nombreuses.

ND_Amiens_gargouilles_17
crédit image : wikipedia

Puis les années passent. Le bébé a disparu pour laisser la place à une cathédrale. Non pas que l’architecture était mauvaise, non. Pris dans son contexte, celui des débuts, tout fait sens, mais les besoins ont évolué. Les règles métier se sont étoffées, les usages également. Les utilisateurs, toujours plus nombreux, toujours plus exigeants, ont fait évoluer le logiciel, ce qui n’est pas un mal, car cela prouve que le projet est bel et bien vivant.

Mais les technos utilisées vous semblent bien loin de ce que l’on fait de nos jours ; très très loin. A bien y réfléchir, avec ce qui existe maintenant, nous pourrions imaginer faire mieux. Beaucoup mieux.  Beaucoup plus efficace. A la fois pour les développeurs, mais aussi pour les utilisateurs, qui ressentent bien un décalage entre ce monument, et le monde tel qu’il est aujourd’hui. Et puis il y a toutes ces petites briques faites main, toutes ces petites gargouilles magnifiques qui ornent l’ouvrage, et sur lesquelles vous avez passé tant d’heures avec vos collègues pour le rendre plus beau, plus riche, plus attrayant. Oui. L’air de rien, 15 ans se sont écoulés entre les débuts du projet et ce stade, une éternité dans le domaine de l’informatique. Et vous vous demandez bien comment le faire évoluer pour qu’il ne devienne pas un de ces monuments que l’on admire, mais sans jamais ou rarement y rentrer… comment le garder en vie ? … sans le détruire complètement et construire un gratte ciel à la place ?

Bien sûr, un projet logiciel n’est pas un organisme vivant. Il ne ‘vit’ que par l’activité que lui donnent ses participants, ses utilisateurs, et surtout ses développeurs. A mon sens, il y a deux morts pour un logiciel. La première (pas forcément la 1ère dans le temps), c’est l’équipe de développeurs qui la lui donne. Plus de mises à jour majeures. Plus d’évolution. Parfois, même, plus de maintenance. L’éditeur peut faire ce choix délibérément (cf. Windows XP), ou pas (cf. Open Office suite au rachat du projet par Sun).  L’autre mort, bien plus définitive, est celle qui est donnée par les utilisateurs. Parfois un logiciel est même mort-né, car ce dernier n’est pas encore livré qu’il est délaissé par les gens censés s’en servir (Windows Millenium, si tu nous entends..).

Les solutions à un tel problème sont loin d’être évidentes, mais il existe plusieurs pistes :

  • dans le cadre d’une licence propriétaire, cadrer dès le départ du projet les conditions de « fin de cycle » et anticiper un renouvellement des développements à long terme. Ce dernier peut prendre plusieurs formes, comme par exemple une réécriture par partie, si tant est que ce soit techniquement possible de séparer des morceaux de l’ouvrage pour le faire évoluer au moins partiellement. Il s’agit dans ces cas là d’un investissement sur le long terme, mais comme chacun sait, personne n’est prophète en son pays …
  • dans le cadre d’une licence libre, c’est un peu plus ouvert (par définition ;)) ), sans toutefois apporter de solution évidente au problème. La continuité de l’activité au sein du projet peut émaner d’autres sources comme des bénévoles, d’autres entités professionnelles, qui peuvent repartir de la base existante pour faire ressusciter le logiciel. Le cas d’Open Office est très intéressant ; le rachat du projet par Sun a provoqué le départ d’une grande partie des contributeurs d’Open Office qui n’ont pas voulu continuer de faire vivre le projet « dans de telles conditions ». Ce dernier a donc été « fourché » (fork) pour renaître sous la forme de LibreOffice. OpenOffice est donc mort dans la bataille, mais LibreOffice a continué d’avancer et d’évoluer.

Bref, n’est pas immortel qui veut. Dans tous les cas, un gros projet, qu’il soit logiciel ou pas, amène avec lui son histoire. Bien qu’il soit toujours tentant de la réécrire et d’y porter un jugement facile, il convient toujours de ne pas l’oublier et d’en tirer les leçons, et ainsi éviter que certaines erreurs du passé ne se répètent…

Introduction à une architecture orientée services

Capitaliser sur du code ; ça c’était avant

On ne le dira jamais assez : chaque projet informatique est unique. Il subsiste cependant des points communs d’un projet à l’autre. Des points que nous pouvons identifier pour anticiper les problématiques, et ainsi monter une solution qui bénéficie, de proche en proche, des expériences passées. On essaie donc de « capitaliser », comme les vils financiers, pour ne pas avoir à réinventer la roue.

Parmi les façons classiques de capitaliser, dans le monde du logiciel, il y a :
  • la reprise de composants logiciels existants. Soit par la reprise de binaires, soit par l’inclusion du code source existant au sein du projet. Il peut s’agir de l’utilisation de librairies existantes et éprouvées libres,… ou pas (jquery, winnovative pour la génération de rapports office, etc.)
  • la façon, la méthode d’assemblage de ces différents composants. Typiquement, sur une application web, nous allons identifier un front-end et un backend. On sait que l’on va devoir organiser le code   de façon à bien séparer les deux parties, on peut alors construire des « templates » de projet, afin de préparer en amont la future organisation du code. Aujourd’hui, de nombreux outils proposent de préconstruire  cette organisation (django en python, ou rails en ruby, par exemple).

Au final, le schéma d’une architecture d’application web se retrouve souvent sous la forme :
  • client JS + HTML
  • serveur web avec du code serveur type C#, Java, Python, Ruby, WhatElse,…
  • base de données PostRacle MySQLServer, EtTantD’autres…
Ensuite, il y a plein de façon de séparer les couches logiques : mais ça de nos jours, tout bon dev connaît ça par coeur   :  l’authentification (basic http, authentification par session/cookie, oauth, open id, etc.) , la méthode d’accès à la base, (direct ou orm) la génération de rapport, (office, csv, etc.). Tout ce joyeux monde est inclus comme un tout à l’éxecutable sous la forme de librairies internes. La partie runtime ne fait donc pas vraiment l’objet de séparation particulière, si ce n’est une organisation dans la façon de concevoir ces packages / namespaces, ou autre.

Bon, bien, bien. Et puis un jour, on se prend ça dans les dents.

Continuer la lecture de Introduction à une architecture orientée services