Dites non au développement “en oignon”!

developpement en oignons

Tout développeur a déjà été confronté au moins une fois à ce curieux mode de développement que j’ai baptisé “le développement en oignon“. C’est à force d’échanger avec des développeurs de tous horizons et pratiquant tous types de langages de programmation que j’ai remarqué que je n’étais pas tout seul à avoir fait ce constat…

Voilà pourquoi je fais ce petit billet pour vous dire à vous, chers amis développeurs, que non, non, vous n’êtes pas tout seuls dans ce cas!

Le développement en oignon, qu’est-ce que c’est?

Vous savez, vous arrivez sur un projet, vous avez un développement à faire, ou plutôt une “maintenance évolutive” ou “maintenance corrective” et vous vous rendez compte que la personne qui est passée avant vous a pas forcément codé de la meilleure des façons.

Les plus radicaux d’entre nous diront qu’il a codé “comme de la merde”, “avec ses pieds”…

Dans les pires cas, vous l’insulterez et maudirez sa petite personne (parfois sa famille aussi, ça arrive…) sur plusieurs générations, dans d’autres cas moins excessifs, vous vous contenterez d’un petit “mais qui a codé ce truc??”.

Le principe même du développeur étant de dénigrer ce qui a été fait, et de penser toujours pouvoir faire mieux (le développeur étant à la fois perfectionniste et parfois utopiste), il va alors rajouter sa couche à l’existant.

Cette nouvelle couche, il la trouvera bien meilleure que la précédente, mais au fil des corrections apportées au développement, chacun apportera sa touche et sa patte à l’ensemble donnant alors un code loin d’être harmonieux sur l’ensemble de l’application. Le problème c’est qu’aucun quasiment n’aura la vision d’ensemble du projet et restera borné à la couche qu’il a à modifier/ajouter.

Vous comprenez un peu plus le coté “oignon” avec ces couches que chacun rajoute à sa manière? Passons à la deuxième partie de la métaphore.

Quand vous attaquez un oignon, couche par couche, que se passe t-il? Vous pleurez! C’est exactement ce qu’il se passe au final avec le développement du même nom!

Qui touche t-il?

Après avoir échangé sur le sujet avec d’autres amis développeurs et pour avoir connu agence web à taille humaine et maintenant SSII à taille (in)humaine, j’aurai tendance à dire que ce phénomène est bien plus répandu en SSII qu’en agence.

Il y a à mes yeux une explication à cela. Le turnover qui est moins important en agence qu’en SSII: le développeur étant moins considéré comme un simple “pion” dans une agence qu’en société de service fait qu’il restera plus longtemps en poste et qu’il aura une vision plus large du projet qu’un développeur qui serait en mission pour quelques mois.

Que faire contre cela?

Malheureusement, et c’est bien là que le bât blesse… Il n’y a rien d’autre à faire que de changer d’environnement et d’espérer trouver un pâturage plus vert ailleurs…

Par rapport au fait qu’on retrouve beaucoup plus ce genre de développement en SSII qu’en agence web, je ne pourrais que vous conseiller alors d’aller en agence web. Mais là encore tout est question de goût!

Il faut aussi avoir testé les deux univers pour pouvoir se faire un avis objectif la dessus, mais de mon coté ce n’est clairement pas une facette “plaisante” de l’univers impitoyable des sociétés de service!

Je sais pas vous, mais moi ça va déjà mieux de vous en avoir parlé, sur ce je retourne rajouter des couches à “l’oignon géant” que mes prédécesseurs ont commencé à construire!

 

6 thoughts to “Dites non au développement “en oignon”!”

  1. C’est beau ce que tu dis là et tellement vrai. A partir du moment où l’on se retrouve en TMA, il y a forcément ce côté “oignon” (superbe métaphore !) ! La SSII est d’autant plus affectée à cela que les sociétés s’enchainent sur un même projet et que, par conséquent, on retrouve plusieurs standards appliqués, puis désappliqués, puis souillés, puis remasterisés, … Et le jour où ça plante : c’est une misère pour s’y retrouver…
    Très bon article et tu me donnes envie de faire un petit billet sur la vie en SSII 🙂

  2. Je partage ce point de vue, et je complèterai même avec ma propre expérience. Le dév en oignon, c’est pas forcément une histoire d’anciens ou de nouveaux dévs, de technos, de concepts.

    On peut aussi y être confronté soi même, sur un code qu’on a produit soi même, et pas forcément il y a dix ans.

    Et c’est normal selon moi, ça témoigne de la maitrise de son sujet. Plus on avance dans le projet, plus ses contours se définissent clairement, et plus les portes qu’on avait laissé ouvertes au début du projet se ferment.

    De plus, selon la durée, d’autres facteurs interviennent: le dév a acquis de l’expérience, et son style a peut être évolué, le projet a pris de l’ampleur, et les imératifs de scalabilité ont laissé place à des contraintes d’optimisation…

    Le code en “oignons”, ça pique aux yeux, mais c’est pas pire que le code en pot-au-feu.

    1. Dans l’ensemble je suis d’accord avec toi. J’apporterais toutefois quelques précisions:
      – Ça touchera plus facilement les dév qui ont le moins d’expérience (ce sont ceux qui ont le moins d’expérience dans la gestion de projet aussi…).
      – Pour le projet en lui même, revenir sur ce qui a été fait n’est en soit pas mauvais (je pense au refactoring), c’est plutôt la question de “combien de dév sont intervenus sur le même code”. Plus ce chiffre sera elevé et plus l’effet “développement oignon” fera pleurer. Le dév a beau être quelconque, si c’est toi qui l’a dév, tu sauras t’y retrouver.
      – Le code pot-au-feu, j’arrive à l’imaginer: on fait du code avec plein de code venant de tous horizons, sans prendre le temps de l’analyser et le comprendre parfois, et la métaphore me fait bien sourire! Une bonne idée pour un prochain billet!

  3. J’aimerais avoir des précisions sur le développement en pot au feu de @nicogiraud ! (Ça donne faim tout ça).

    Pis d’abord, j’aime pas les oignons.

  4. Pour moi, c’est un dev où tu as autant de code externe que de code produit. Tu sais comme le fameux “htaccess/htpasswd” que beaucoup de dév pompaient sur “comment ça marche” et qui comportait une faille de sécurité!

Leave a Reply to Xavier Cancel reply

Your email address will not be published. Required fields are marked *