Approche logicielle
Il y a deux façons d'aborder le développement logiciel. La première, c'est d'aligner du code pour répondre à un besoin immédiat en croisant les doigts pour la suite. La seconde, c'est de construire une solution pérenne, performante, et capable d'encaisser les évolutions futures sans s'effondrer. Je pense qu'on préfère tous la deuxième voie ;)
C'est cette deuxième voie que j'ai choisie. Laissez-moi vous expliquer comment je conçois un logiciel robuste.
Le point de départ : le métier
Oui, le métier. Et pour bien le comprendre, faisons une rapide digression dans les années 1970-1980. En réalité, je n'invente rien : à cette époque, on parlait encore d'« analyste-programmeur ». Une seule et même personne concentrait les deux casquettes : l'analyse du métier (les règles, les calculs, les processus vitaux de l'entreprise) et la programmation pure (l'écriture, la compilation, le debug).
Depuis, l'informatique s'est complexifiée. Une seule personne ne peut plus tout gérer de A à Z. La conséquence ? La partie « métier » est peu à peu sortie du périmètre direct du développeur pour devenir une simple liste d'exigences extérieures. Et c'est un immense gâchis.
Car le métier de l'entreprise, c'est précisément ce dont l'ingénieur devrait être obsédé. Je ne parle pas seulement d'appliquer une spécification, je parle d'en faire la boussole qui guide chaque choix d'architecture. Le code se doit de refléter fidèlement le business, jusque dans la sémantique de la moindre fonction.
L'orienté objet comme traducteur du réel
C'est exactement là que la conception orientée objet révèle sa véritable puissance. Pour beaucoup, ce n'est qu'un paradigme technique parmi d'autres. Pour moi, c'est le moyen d'expression ultime pour combler ce fossé entre le fonctionnel et la technique.
Quand on maîtrise cette approche, on ne code plus des structures de données abstraites : on déduit directement des concepts métiers pour en faire des objets dans le langage. Le code cesse d'être une bouillie d'instructions incompréhensibles pour devenir le reflet miroir de la réalité de votre entreprise.
Des garde-fous, pas un dogme : tests et principes
Une fois que le code reflète la réalité du métier à travers des objets bien pensés, un « miracle » d'ingénierie se produit : il devient naturellement testable. Plus besoin de mettre en place des stratagèmes complexes ou de simuler la moitié du système pour vérifier une simple règle de calcul. Chaque objet a sa propre responsabilité, claire et délimitée.
C'est d'ailleurs toute l'essence des fameux principes SOLID. Pour beaucoup, c'est un acronyme récité lors des entretiens d'embauche. Sur le terrain, ce sont des garde-fous vitaux. Je ne les applique pas pour la beauté de la théorie, mais parce qu'ils offrent une garantie inestimable : l'assurance qu'une nouvelle évolution demandée par le client ne fera pas s'effondrer le reste de l'application en silence.
Le bon sens de l'ingénieur : l'équilibre avant tout
Mais attention au piège inverse. J'ai vu trop de projets s'enliser sous le poids de leur propre architecture parce que l'équipe voulait « faire de l'objet » à tout prix. Le résultat ? Des abstractions inutiles, des usines à gaz et un code qui devient plus complexe que le problème qu'il est censé résoudre.
L'ingénierie logicielle est avant tout une question d'équilibre et de pragmatisme. C'est tout l'esprit du principe KISS (Keep It Simple, Stupid) : on ne crée pas une classe ou une interface abstraite pour satisfaire son ego de développeur. Si une logique métier tient parfaitement dans une simple fonction, elle doit rester une fonction. C'est sans doute l'enseignement le plus précieux de mes années d'expérience : mon rôle n'est pas de sur-concevoir un système, mais de placer le curseur exactement au bon endroit pour livrer un code propre, performant et utile.
Passons à la pratique
En fin de compte, la théorie n'a de valeur que si elle survit à l'épreuve de la production. Vous connaissez maintenant ma vision de l'ingénierie et le niveau d'exigence que j'applique à mon code.
Vous partagez cette philosophie ? Vous avez un défi logiciel complexe exigeant une architecture résiliente, ou une équipe à renforcer avec un profil autonome et pragmatique ? La meilleure façon de savoir si nous sommes faits pour collaborer est d'en discuter de vive voix.