0 commentaire
Dans le cadre de notre activité d'éditeur de logiciels web, nous faisons régulièrement des études de marché et des comparatifs techniques des outils de création de sites existant.

Nous avons décidé de rendre publique l'étude que nous avons faite sur le code source de Kiubi et sur ceux des principaux projets opensource connus de type CMS, Blogs ou solution e-commerce à destination des TPE/PME.

Nous avons pour cela utilisé l'outil PHPLoc, mis au point par Sebastian Bergmann. Cet outil analyse la structure du code PHP, on pourrait même aller jusqu’à dire son esthétique, sans pour autant se préoccuper de ce que fait concrètement ce code, ni chercher à savoir si il est infesté de bugs ou optimisé.

Pourquoi analyser la complexité du code source ?

Il y a une corrélation indiscutable entre la complexité du code source d'un logiciel et la difficulté à le comprendre, le maintenir et le faire évoluer. Cela donne ainsi une lecture sur le coût total de possession et sur la pérennité du projet, indépendamment du type de licence du logiciel, de la taille de son équipe de développement ou de sa communauté d'utilisateurs.

Il est évident que tous ces projets n'ont pas la même couverture fonctionnelle, il est donc important d'avoir en tête les capacités et objectifs de ces projets avant de les comparer entre eux. Nous avons pris les versions françaises considérées comme stables et n'avons installé aucune extension complémentaire. Il s’agit véritablement ici d’installations "out of the box" et on comprendra que ces classements peuvent très vite se dégrader à l'installation de modules supplémentaires.
 
Encore une fois, ce comparatif ne s'attarde que sur le code lui-même. Il s'agit d'un parti pris qui nous permet une comparaison quantifiée entre les plateformes techniques auditées dans le but de révéler leur philosophie technique.

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 :

  Juillet 2010 Septembre 2010 Typologie
Magento 1.3.2.4 1.4.1.1 e-commerce
ezPublish - 4.3.0  CMS
Typo3 - 4.4.2  CMS
Spip - 2.1.2 CMS
Joomla 1.5.15 * CMS
Kiubi 07/2010 09/2010 CMS + Blog + e-commerce
Wordpress 2.9.1 3.0.1 Blog
Prestashop 1.2.5.0 1.3.1 e-commerce
Drupal 6.15 6.17 CMS
Thélia 1.4.2.1 * e-commerce
OsCommerce 2.2rc2a * e-commerce
Dotclear 2.1.6 2.2 Blog
 * 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.

  Juillet 2010 Septembre 2010 Evolution
Magento 288 962 366 462 +26%
ezPublish NC 290 770  
Typo3 NC 163 267  
Spip NC 159 457  
Joomla 123 099 123 099 0%
Kiubi 83 295 90 270 +8%
Wordpress 75 967 82 962 +9%
Prestashop 63 841 77 387 +21%
Drupal 37 478 43 955 +17%
Thélia 31 164 31 464 0%
OsCommerce 32 188 32 188 0%
Dotclear 32 015 33 267 +4%

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

  Juillet 2010 Septembre 2010 Evolution
Magento 4 346 5 174 +19%
ezPublish NC 2 523  
Typo3 NC 1 081  
Kiubi 855 946  +11%
Joomla 759 759 0%
Prestashop 411 443 +8%
Thélia 195 195 +0%
Wordpress 174 168 -3%
Dotclear 140 148 +6%
OsCommerce 73 73 0%
Spip NC 45  
Drupal 1 1 0%

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.
  Juillet 2010 Septembre 2010 Evolution
Wordpress 204 195 -4%
Dotclear 176 174 -1%
Typo3 NC 153  
Prestashop 128 135 +6%
Joomla 121 121 0%
OsCommerce 120 120 0%
ezPublish NC 110  
Thélia 91 91 0%
Kiubi 75 70 -4%
Magento 67 73 +5%

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.

  Juillet 2010 Septembre 2010 Evolution
Wordpress 5,34 5,52 +3%
Typo3 NC 5,06  
Spip NC 4,58  
Drupal 4,50 4,50 0%
Kiubi 4,26 4,24 -0,5%
Prestashop 3,99 4,08 +2%
ezPublish NC 3,51  
Dotclear 3,36 3,42 +2%
Magento 2,88 2,87 -0,4%
Thélia 3,11 3,11 0%

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. 

  Juillet 2010 Septembre 2010 Evolution
Spip NC 2 662  
Wordpress 1 841 2 186 +19%
Drupal 1 951 2 146 +10
ezPublish NC 435  
Typo3 NC 197  
Kiubi 214 192 -10%
Prestashop 188 191  +2%
Magento 31 37 +19%
Dotclear 23 24 -4%

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

Les constantes servent à figer la configuration de l'application et sont très pratique car elles se propagent toutes seules partout dans le code. Leur nombre reflète la difficulté ou la complexité de l'installation de l'application dans son environnement.
 
  Juillet 2010 Septembre 2010 Evolution
OSCommerce 5245 5246 0%
Joomla 648 648 0%
Magento 457 457 0%
Spip NC 401  
Typo3 NC 346  
Wordpress 288 326 +13%
Prestashop 166 315 +90%
Kiubi 238 244 +3%
Thélia 197 197 0%
Drupal 162 164  +1%
ezPublish NC 62  
Dotclear 42 44 +5%

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

  Juillet 2010 Septembre 2010 Evolution
Magento 1,11 1,13 +1,8%
Typo3 NC 0,93  
ezPublish NC 0,91  
Joomla 0,67 0,67 0%
Drupal 0,64 0,63  -1,6%
Kiubi 0,57 0,61 +7%
Wordpress 0,58 0,59 +1,7%
Thélia 0,57 0,57 0%
Dotclear 0,42 0,43 +2,4%
Spip NC 0,39  
Prestashop 0,39 0,35 -10,3%
OSCommerce 0,32 0,32 0%

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

En quelques mois, la plupart des CMS étudiés ici sont devenus un peu plus volumineux, un peu plus complexes, un peu moins bien documentés. La pression des utilisateurs fait naturellement tendre tout logiciel vers l’obésité. D’un côté, les utilisateurs réclament des fonctionnalités superflues indispensables, mélangeant malheureusement leurs envies et leurs besoins. D’un autre côté, il est aussi beaucoup plus valorisant et plaisant pour les développeurs de sortir de nouvelles fonctionnalités inédites. Comment résister à la tentation de coupler son logiciel avec la dernière technologie à la mode ? 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.

Ce tour d'horizon des CMS nous montre des positionnements diamétralement opposés. 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.

Enfin, les vieux de la vieille comme Joomla, osCommerce et Spip, vivent grâce aux nostalgiques alors que leurs communautés les abandonnent progressivement pour des équivalents plus simples. Elles vont inévitablement s’éloigner de ces projets pour en former de nouveaux avec l’ambition de refaire mieux, en plus simple et plus centré sur leurs cœurs de métier, ainsi va le cycle de vie des logiciels.

(facultatif)

(facultatif)
(anti-spam)Combien font cinq plus deux ? (chiffres)