Suite à vos nombreuses demandes, nous avons mis à jour notre comparatif des CMS et solutions e-commerce sous l’angle de l’analyse de leur code source. Nous avons non seulement ajouté trois CMS supplémentaires (SPIP, Typo3 et ezPublish), mais également pris en compte les nouvelles versions des logiciels précédemment comparés. Nous avons aussi analysé l’évolution du code de ces logiciels pour essayer de dégager des tendances.
Compte-tenu de l’enthousiasme généré par la publication de notre premier comparatif, nous avons décidé d’en faire une page dédiée de notre site. Cette page comporte également des critères d’analyse supplémentaires que nous avions jugés trop volumineux/complexes pour notre Blog. Cette page sera mise à jour régulièrement avec les nouvelles données.
Bonne lecture à tous !
L’équipe technique de Kiubi.
>> Lire le comparatif.
3
Comparaison des CMS et solutions e-commerce : mise à jour
GénéraleLe 21 Septembre 2010Ajouter à :
facebook |
viadeo |
twitter |
plus de bookmarqueurs
Commentaires
Je suis effaré de lire dans cette nouvelle version : « La mauvaise surprise vient de SPIP dont le code est très mal documenté » alors même que j'avais indiqué ici : http://www.kiubi.com/blog/2010/08/09/comparaison-complexite-CMS.html#commentaire_21 : « Enfin, pour SPIP, une partie des commentaire du code sont une URL qui renvoie à http://doc.spip.org/ ». Et là, en terme de ratio ligne de code/commentaires, les autres peuvent aller se rhabiller !
L'externalisation d'une partie de la documentation de SPIP, notamment sur les fonctions nous semble aller à l'encontre de l'état de l'art. Ce n'est pas très pratique pour le développer qui doit faire des allers-retours entre le code et le site (certes très bien fait) de la documentation. La logique voudrait que toute la documentation reste dans le code source. C'est à dire que tous les éléments nécessaires à la compréhension et la modification du code source y reste. N'est ce pas d'ailleurs un des principes fondateurs du libre ?
De plus, beaucoup d'IDE utilisent de l'introspection de code pour proposer des aides très utiles à la saisie et des corrections automatiques. Ces fonctionnalités très puissantes deviennent impossibles à mettre en place avec une documentation tronquée. Enfin, il s'avère souvent pratique de générer soit même une documentation de son projet une fois qu'on y a ajouté ses contributions avec des outils comme phpDocumentator. Et là encore l'externalisation de la documentation rends la démarche très laborieuse.
La mesure effectué par phploc sur Spip reflète donc bien à notre avis la difficulté de prise en main du code source par un développeur dans le sens large, c'est à dire par lui directement mais aussi par les outils de travail qu'il utilise au quotidien.
Bonjour,
Je trouve votre comparatif plutôt bien fait. Je trouve par ailleurs louable que la "maigreur" ou "légèreté" de votre code soit un objectif; c'est un objectif que nous partageons avec vous.
Cependant:
- si vous changez un jour de cibles fonctionnelles, votre code-source augmentera inévitablement (je pense que le code-source de SAP est très conséquent, mais il est utilisé pour gérer des multinationales...)
- vous conviendrez qu'il est quand même frappant de constater que l'augmentation du code-source de Magento est proportionnelle à son indiscutable succès commercial (je n'ai pas dis "succès technique", hein? Le développement off-shore a ses limites ;o)
- dommage que vous n'intégriez pas à ce comparatif objectif le CMS e-commerce RBS Change qui, aux côtés de Magento et de Prestashop, est une référence sérieuse en terme d'outil open source.
Mis à part ça, longue vie à Kiubi, on aime bien ce que vous faites!