De retour de vacances, c’est la rentrée.
Plein d’idées d’articles pour cette nouvelle saison, mais je vais commencer simplement avec un petit ‘quizz’.
Imaginons que l’on vous demande de catégoriser une application en fonction de sa taille, en nombre de lignes de code (LOC) ou en nombre d’objets. Quelle est votre estimation d’une application de petite taille ? Quand dites-vous qu’une application est grosse ? A partir de quels nombres pensez-vous qu’elle est ‘monstrueuse’ ou hors normes ?
Cette question se pose assez fréquemment et, dans mon expérience, il est difficile d’y répondre précisément et avec certitude.
On vous demande ‘200 000 lignes de code Java, c’est une grosse application ?’ ou bien ‘500 programmes Cobol, c’est gros ?’. Ce peut être votre patron ou un commercial à qui un client demande une idée de tarif pour prendre en charge la maintenance d’une application de cette taille. Ce peut être un client ou un responsable au sein de votre entreprise qui souhaite faire appel à vos services pour un audit de qualité applicative mais voudrait savoir quel effort ou combien de temps s’avère nécessaire pour analyser cette application.
Remarquez bien que je ne suis pas en train de parler d’effort de développement ou de maintenance d’une application ou de productivité des programmeurs. Certaines personnes considèrent que la métrique LOC est une ‘malpractice’ et je suis bien d’accord pour dire qu’elle ne doit pas être utilisée pour mesurer la productivité, l’effort ou les fonctionnalités dans une application. Mais quand je vais analyser le code d’une application, j’aime savoir s’il s’agit d’une petite application ou d’un gros monstre. Tous les consultants en Qualité de code se posent cette question, et chacun à sa propre grille.
Ci-dessous, les valeurs que j’utilise :
Taille de l’application en KLoc
Taille de l’application | |||||
Basse | Moyenne | Elevée | Très élevée | ||
Technologie | Objets | Lignes de code (000) | |||
Mainframe Cobol | Programmes Cobol et Copy-books | 200 | 800 | 2 000 | 4 500 |
Client/Server 4GL | Programmes (VB, …), classes (C, C#), procédures (PL/SQL), etc. | 80 | 300 | 750 | 1 500 |
J2EE, .NET | Pages (ASP, JSP, HTML), classes (Java , C#), Javascript, Xml, etc. | 50 | 200 | 400 | 1 000 |
ABAP | Programmes, includes, reports, fonctions, etc. | 100 | 400 | 800 | 1 500 |
Par exemple, une application J2EE sera :
- De taille réduite en dessous de 50 000 LOC.
- De taille moyenne entre 50 KLoc et 200 KLoc.
- De taille élevé entre 200 KLoc et 400 Kloc.
- De taille très élevée jusqu’à 1 000 Kloc.
Au-delà de 1 million de lignes de code, je considère qu’une application J2EE est ‘monstrueuse’, c’est-à-dire hors-normes. Remarque : le plus souvent, il ne s’agira pas d’une unique application, mais plutôt d’un système composé de multiples modules applicatifs. Mais quelque soit le nom qu’on lui attribue, si ce code est entre les mains d’une unique équipe de projet, alors celle-ci est face à un Everest. Avec les problèmes spécifiques que pose la gestion d’une telle montagne de code.
La table ci-dessous présente la même évaluation, mais basée sur le nombre d’objets.
Taille de l’application en nombre d’objets
Taille de l’application | |||||
Basse | Moyenne | Elevée | Très élevée | ||
Technologie | Objets | Nombre d’objets | |||
Mainframe Cobol | Programmes Cobol et Copy-books | 200 | 750 | 2 000 | 4 000 |
Client/Server 4GL | Programmes (VB, …), classes (C, C#), procédures (PL/SQL), etc. | 100 | 200 |
600 | 1 500 |
J2EE, .NET | Pages (ASP, JSP, HTML), classes (Java , C#), Javascript, Xml, etc. | 80 |
150 |
500 |
1 000 |
ABAP | Programs, includes, reports, fonctions, etc. | 400 |
1 000 |
2 500 |
6 000 |
Souvent, le nombre d’objets sera la seule indication connue : peu de clients ou de responsables de projet connaissent le nombre de lignes de code dans une application. Et cette indication peut être trompeuse.
Par exemple, on vous livre une application Cobol avec 800 programmes, et comme la personne en charge d’effectuer cette extraction n’a pas voulu s’embêter, il vous a livré les 20 000 Copy-books présents sur le système Mainframe. Au premier abord, c’est plus que monstrueux, mais il n’y a probablement que 2 ou 3% de ces Copy-books qui correspondent à cette application. Celle-ci est donc en définitive de taille moyenne. Par contre, si vous décidez d’analyser toutes les Copys, alors vous avez un gros travail d’analyse devant vous, pour un résultat qui n’a pas pas beaucoup de sens en termes d’audit applicatif, puisque le périmètre d’analyse ne correspond pas à une application ou une équipe de projet.
Parfois vous aurez une application J2EE avec énormément de pages JSP ou un grand nombre de fichiers de configuration Xml (notamment avec certains frameworks du marché) et peu de classes métier. Lá encore, le nombre d’objets ou de lignes de code ne sera pas vraiment représentatif.
J’ai eu beaucoup d’échanges à ce sujet avec des professionnels réalisant des audits de qualité de code, et si nous arrivons souvent à tomber sur des chiffres assez proches, tous s’accordent à dire que ce n’est qu’une indication qui peut varier fortement comme le montrent les exemples précédents. Mais parfois, vous devez répondre à cette question ‘Est-ce une grosse application?’ sans avoir plus de données.
Et vous, comment catégorisez-vous une application ?
Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.