Logiciels comparés

Suite aux nombreuses demandes reçues, trois nouveaux CMS font partis du comparatif : Spip, ezPublish et Typo3. Nous avons également trouvé intéressant de relancer les tests sur les projets qui ont évolué fonctionnellement, c’est à dire qui ont eu au moins un changement de version mineur dans leur branche stable depuis les versions utilisées pour le premier comparatif (vieilles d’environ 6 à 9 mois). Nous constatons que tous les logiciels ont évolué, sauf Oscommerce et Joomla qui n’ont sortis que des correctifs depuis, ce qui conforte notre précédente analyse sur ces projets.

Versions des logiciels testés et typologie principale :

* ignoré car sans mise à jour significative de la version stable

Nombre de lignes de code et évolution

Nous cherchons ici à connaître le nombre de lignes de code constituant les différents CMS et logiciels e-commerce analysés.

Magento atteint un nombre impressionnant de lignes de codes. C’est ce qui se passe quand on inclus le framework ZEND quasi intégralement et qu’on y ajoute le Framework PEAR.  Est-il encore possible de maitriser pleinement un code aussi important ?  Joomla parait également très volumineux alors qu’aucun module  supplémentaire n’a été installé.
EzPublish, Typo3 et Spip sont de gros CMS, très orientés vers la gestion de publication (articles, documents, rapports, etc). Ils proposent des fonctionnalités avancées de gestion de droits d’utilisateurs, de workflow et de classification de documents. C’est pourquoi ils se rencontrent moins fréquemment sur des sites pour TPE/PME qui ont des besoins très limités sur ce point car il y a rarement plus d’une personne ou deux à mettre à jour le site. Ces fonctionnalités ont un coût, celui de l’explosion de la complexité de l’outil. Leur communauté a également eu le temps (en plus de 10 ans) d’ajouter beaucoup de fonctionnalités hors de leur cœur de métier. Au final on obtient des CMS qui font « tout » et qui sont aussi volumineux qu’un Magento.
Pour les autres logiciels, le nombre de lignes  est, selon nous, en phase avec le type de logiciel (CMS, Blog ou  solution e-commerce).
Chose intéressante à noter, on remarquera que tous les logiciels analysés ont gagné entre 4 % et 26 % de code source sur la même période de temps. L’importance de cette croissance de code ne semble pas être corrélée à la taille de leurs communautés respectives. Plusieurs facteurs permettent d’expliquer cela. Ces projets sont portés par une équipe restreinte qui a la responsabilité du « cœur » du système. Il faut par conséquent constamment assurer la compatibilité ascendante donc les développeurs ne peuvent pas faire de changements majeurs constamment, ils sont limités à faire des « petits pas ». Une bonne partie de leur énergie est aussi dépensée sur le code déjà existant, c’est à dire dans la correction de bug et l’amélioration de la stabilité du programme. Enfin, on remarquera que l’essentiel des  contributions de leurs communautés se concentrent plus sur le développement d’extensions tierces qui devront être installées dans un deuxième temps. Il peut se passer beaucoup de temps avant qu’une extension, aussi populaire soit-elle, soit intégrée dans le cœur du système.

Nombre de classes

En programmation, les classes permettent de packager des fonctionnalités et des interactions. Un faible nombre de classes volumineuses signifie en général que les classes sont complexes et trop rigides, un  nombre trop important indique qu’il faudra faire un montage savant de  petites classes avant d’être réellement productif. Bien entendu, ces  chiffres sont toujours à relativiser par rapport à la couverture  fonctionnelle attendue et au nombre de plateformes supportées.
Toujours un beau record pour Magento qui ne se concentre pourtant que  sur l’e-commerce (merci Zend et PEAR). EzPublish est connu pour être massivement orienté objet et Typo3 utilise également  un nombre de classes impressionnant. Pour les autres, la volumétrie  semble normale. Certains développeurs pourront s’inquiéter de voir s’ajouter 828 classes supplémentaires à Magento, soit plus que le nombre total de classes de Joomla !
Spip, tout comme Drupal, utilise une approche procédurale. Les quelques classes visibles sont apportées par des bibliothèques tierces. On voit bien pour OSCommerce, SPIP et Drupal que les projets  sont si anciens qu’ils datent d’avant le boom de la programmation orientée objet  (ce qui n’est pas une tare non plus). Un développement procédural, ou  pour simplifier « sans objets », amène à un code souvent plus accessible  pour le néophyte, mais ce modèle a montré ses limites en terme d’évolution et de maintenance. De plus, la programmation objet a le vent en poupe, c’est donc sur ce genre de projet que les communautés se forment le plus.

Longueur moyenne d’une classe en lignes de code

Autre statistique en rapport avec l’utilisation des objets, la longueur moyenne d’une classe en lignes de code exécutable. Des classes trop longues sont souvent synonymes de problèmes de conceptions. Partant du principe qu’une classe doit être un élément simple et réutilisable, faiblement dépendant de son environnement et n’avoir qu’un nombre très restreint de responsabilités, sa longueur doit forcement être limitée. Drupal et Spip ne figurent pas dans le classement car ils ont une utilisation trop faible de la POO pour que l’indice soit significaif.

Les plus « mauvais » élèves de la « classe » (WordPress et Dotclear) ont fait quelques efforts dans leurs nouvelles versions. Les classes de Typo3 semblent également un peu lourdes. Kiubi et Magento font jeu égal en termes de concision.

Complexité cyclomatique de Mc Cabe

La complexité cyclomatique, aussi nommée Mesure de McCabe, est un outil de métrologie logicielle développé par Thomas McCabe en 1976 pour mesurer la complexité d’un programme informatique. Cette mesure comptabilise le nombre de « chemins » au travers d’un programme représenté sous la forme d’un graphe (source Wikipédia). Plus ce nombre est élevé, plus le programme est complexe.

On notera une tendance à la hausse de complexité sur tous les logiciels à l’exception de Magento et Kiubi où les équipes de développement accordent une grande importance à l’amélioration et l’évolutivité du code existant. Alors que la mécanique générale derrière la gestion d’un blog est relativement basique comparativement à celle d’une solution e-commerce, on pourra s’étonner du fait que  WordPress affiche un indice de complexité double de celui de Magento !

Le nombre de fonctions

Les fonctions sont un moyen pratique de centraliser des fragments de  codes pour les réutiliser un peu partout. Les inconvénients sont la  difficulté à la fois de maintenir une cohérence dans un grand ensemble de  fonctions indépendantes et de leur trouver un nom sémantiquement pertinent.

Comparatif de fonctions:

Un grand nombre de fonctions est synonyme de programmation procédurale, anti-thèse de la programmation orienté objet. Les CMS Spip et Drupal en font un usage intensif. Certains pourront s’étonner qu’un logiciel nettement plus récent comme WordPress y recoure également dans de telles proportions.

Nombre de constantes

L’utilisation des constantes pose aussi le problème de la rigidité du cadre d’exécution. L’application ne peut plus modifier son contexte d’exécution une fois lancée, ce qui ferme la porte à beaucoup de techniques d’optimisations. Il devient aussi difficile d’émuler ce contexte d’exécution pour faire du débuggage de portions très ciblées du code. Enfin, toutes ces constantes occupent de la place en mémoire, il devient légitime de se demander si l’application a besoin de connaitre en permanence toute sa configuration, même celle par exemple des modules qu’elle n’est pas entrain d’utiliser. Le nombre de constantes utilisé par OSCommerce est gigantesque, près de 8 fois plus que le second du classement ! La solution e-commerce Prestashop se distingue par la plus forte progression en doublant presque le nombre de ses constantes.

Volume de commentaires

Très beaux scores pour Magento, ezPublish et Typo3, leur communauté regroupent des développeurs expérimentés qui ont l’habitude de documenter leur code. Le code source est peut-être complexe, mais au moins il est très bien documenté !   La mauvaise surprise vient de Spip dont le code est très mal documenté (les développeurs ont en réalité externalisé une partie importante de la documentation sur un site externe, d’où le mauvais score) et de la note de Prestashop qui a significativement baissé en seulement quelques mois pour quasiment atteindre le plancher représenté par OSCommerce.

Conclusion du comparatif de ces CMS

Comment en vouloir à un développeur de trainer les pieds quand il s’agit de corriger un obscur bug dans le fin fond de la fonction la plus complexe de son logiciel ?Linus Torvalds, le créateur du noyau Linux s’il faut encore le présenter, avouait en 2009 que le code source du noyau Linux était « bouffi et énorme » (source). Pourtant sa stabilité et sa popularité ne sont plus à prouver. Quel est son secret ?
Un travail de fond constant sur la qualité du code et un point de vue clair et net sur ce qui entre dans le périmètre fonctionnel et ce qui n’y rentre pas.La majorité des logiciels OpenSource qui réussissent sont ainsi rarement une illustration d’un fonctionnement démocratique, mais plutôt celle d’une dictature participative éclairée… ce qui est le mode de fonctionnement habituel des logiciels commerciaux.Les métriques présentées ici donnent une idée de l’énergie dépensée pour l’amélioration de la qualité du code.
A service rendu identique, il est impossible à l’utilisateur de juger de la qualité du code source.  Il ne voit que le travail effectué, et non comment il a été fait. Les différences ne vont apparaître qu’avec le temps. Une qualité médiocre va amener à long terme au ralentissement de la sortie de nouvelles fonctionnalités, à l’augmentation de la fréquence d’apparition des bugs, et mener finalement à la mort, prématurée ou non, du logiciel. Les indicateurs présentés ici sont autant d’indicateurs de maturité et de motivation de l‘équipe de développement que par conséquent de la pérennité du logiciel.

Magento a choisit la pureté du code avant tout, quitte à se séparer des développeurs les moins hardcore, tout en s’adonnant à une boulimie de fonctionnalités permise par les frameworks Pear et Zend au risque de s’effondrer sous son propre poids.
A l’inverse, WordPress n’a clairement pas fait une priorité de la pureté du code, préférant donner des outils brouillions aux développeurs occasionnels qui veulent un peu personnaliser leur site au risque de tomber dans la « programmation spaghetti« . Pour l’instant l’abandon prévu de la compatibilité avec PHP4 et la passage vers PHP5 n’a pas l’air d’impacter sur cette philosophie de développement. L’équipe a préféré mettre l’accent sur la couverture fonctionnelle.