Cela fait plusieurs années que vous faites des applications de bureau en .NET / C# / Winform / WPF / SQL Server / EF, avec tous les patterns qui vont avec, et vous vous intéressez depuis peu au web ?
Si c'est le cas, vous avez surement découvert ASP .NET et son fameux MVC 4 et 5.
Lors de cette découverte, vous avez apprivoisé rapidement l'ensemble de l'écosystème coté "Backend" tant les concepts et méthodes sont proches de la programmation orientée objet traditionnelle.
Seulement voila, lorsque vous avez commencé a regarder la partie "Frontend", vous n'avez pas pu vous empêcher de gerber tant les principes et outils qui dominent sont chaotiques, improductifs, soumis au monde de la bidouille et sans aucune foi ni loi.
Si le monde informatique est plein de logiciels qui sont en interaction direct avec l’utilisateur, d’autres types de programmes s’exécutent dans l’ombre et permettent le bon fonctionnement de plusieurs services indispensables.
Ces logiciels fantômes qui servent à traiter vos mails, acheminer vos documents vers une imprimante, lancer des sauvegardes automatiques et bien d’autres choses sont appelés dans le jargon informatique des « démons systèmes ». Ils travaillent en arrière-plan et ont pour vocation à faire des traitements critiques, il est donc primordial que ceux-ci soient les plus robustes possibles.
Or, la plupart du temps, les concepteurs de ces programmes n’appliquent pas les bonnes pratiques comme ils pourraient le faire avec des logiciels de gestion traditionnels, et ce pour plusieurs raisons :
Les programmeurs travaillent souvent seul sur un démon système
Le .NET framework fourni des API natives très peu adaptées à la mise en place de design SOLID
Les démons systèmes sont (de premier abord) des programmes simples qui ne font que des choses répétitives.
De plus, il n’existe pas vraiment de bonnes pratiques quant à
l’exploitation d’un démon système, ainsi chaque programmeur y va de sa
créativité (enregistrement de logs dans des fichiers ou dans l’observateur
d’événements, interface de contrôle obscure, configuration sous forme de fichier
XML, INI ou base de registre, suivi des opérations à travers un fichier de
sortie, …)
Tout cela peut rendre complétement fou ceux qui sont chargés
d’installer, configurer et maintenir ces programmes, c’est pourquoi j’ai créé
« SystemHell », un Framework Open Source permettant de mettre au
point rapidement et facilement des services systèmes (démons) en .NET, avec
l’avantage de donner plus de souplesse aux administrateurs pour les installer,
les configurer et les maintenir.
Nous allons voir ensemble comment manipuler cet outil pour
mettre sur pied des démons avec une vraie qualité professionnelle.
Plutôt que de lire, écoutez cet article avec ASTREAD
Chaque jour dans le monde, des milliers de personnes se jettent
dans un nouveau projet de développement logiciel : Que ce soit une startup
qui veut lancer un concept avec son site web, une entreprise qui veut développer
un logiciel de gestion ou un étudiant qui désire créer une application mobile,
tous voient en la technologie un moyen simple et rapide de réaliser leurs
ambitions.
Mais savez-vous que selon « l’observatoire des
projets » qui a réalisé une étude sur le taux d’échec dans le domaine de
l’informatique en 2012, 55% des responsables sondés estiment qu’entre 16% et
50% de leurs projets stratégiques sont purement et simplement abandonnés !
L’histoire que je vais vous raconter parle de l’un de ces millions
de projets qui a bien failli finir dans les oubliettes de l’informatique, tout
en entrainant avec lui l’avenir d’une société et des salariés qui la composent.
Loin d’être un cas isolé, nous allons voir comment ce projet
hautement stratégique a lentement dérivé, pour arriver à une situation
tellement catastrophique que tous ceux qui y ont participé de près ou de loin
s’en sont retrouvés profondément affectés.
Comme la fin du projet signifiait la fin de la société, il
n‘était pas question pour la direction de l’abandonner.
C’est dans ces
conditions difficiles que j’ai été désigné pour en reprendre les rênes.
Or, l’équipe était tellement accablée par cet échec qu’elle
ne pouvait accepter de recommencer.
Seule une profonde remise en question des méthodes de
travail tant sur le plan technique que humain pouvait les convaincre de
remettre le couvert.
J’ai donc été obligé de revoir ma façon de penser et d’aller
à contre-courant de tout ce qui se faisait jusqu’alors, allant parfois à
l’encontre d’un certain bon sens et des directives données par les
dirigeants même de la société !
Et figurez-vous que ça a marché.
Je vous propose donc de vous faire revivre cette expérience
qui a changée à jamais notre façon de gérer des projets de développement…
