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
