La qualité NK

Sur l'affaire NK, en fait c'était moi l'idiot monumental. Comment j'ai pu vouloir attendre un code sans reproche de qualité professionnel d'une team composé exclusivement de développeurs amateurs (je ne suis même pas sûr qu'ils connaissaient les étapes de fonctionnement de zend engine)... En fait décrocher la lune aurait été plus facile...

Je viens tout juste de comprendre que le fait qu'ils aient réalisés deux releases candidates de la même version non compatibles entre elles c'est pas par choix ou par fainéantise, mais parce qu'ils n'ont pas les compétences en programmation pour trouver les 30 lignes à modifier afin que leur dernière version reste compatible avec les versions précédentes. Ce qui fait que cette compatibilité est "impossible" puisque qu'en réalité ils ne sont pas maitre de leur code.

Bref forcément j'avais des attentes trop élevés en considérant les développeurs de NK comme des développeurs professionnels. Mais effectivement comme les développeurs de NK me l'ont fait remarqué, la communauté de NK est habitué à du code non professionnel qu'il faut modifier dès qu'on veut ajouter un patch. Vouloir augmenter la qualité du service de NK et la qualité du code pouvait du coup être une erreur.


La qualité de service professionnel c'est entre autre de garder la compatibilité entre les Releases Candidates afin de permettre à la communauté de faire des thèmes et des modules pour la version en cours de correction. Comme ça, dès la sortie de la version stable, il y a déjà un bon nombre de modules et de thèmes. La compatibilité arrière est quelque chose énormément pris au sérieux chez les logiciels de plus grande envergure. Bison et Flex par exemple qui sont les deux logiciels les plus utilisés pour les logiciels de compilation et d'interprétation ont gardé leur compatibilité arrière avec Yacc et Lex qui sont des antiquités. S'il n'y a pas de compatibilité arrière entre deux RC, alors les développeurs de thèmes et de modules ne voudront plus développer pendant les RC (pour ne pas devoir modifier et rendre de nouveau compatible toutes leurs créations à chaque RC) et attendront la version finale.

Si on parlait d'un CMS "classique" y a donc une dégradation de la confiance et de la "qualité du CMS" au niveau des développeurs autour du CMS, mais ça engendre aussi une dégradation de la qualité au niveau des utilisateurs puisque d'une part ils auront beaucoup moins de modules durant les RC, mais en plus mettre à niveau une version RC sur leur site relèvera presque de l'impossible dans le sens où les modules et les thèmes qu'il avait installé ne fonctionneront plus correctement. Mais ce qui est beau sur NK, et ce que m'a finalement fait comprendre la team NK, c'est que les créateurs de thèmes et de modules sont passionnés par la programmation et sont donc même presque heureux de pouvoir retoucher leur code entre deux versions. Ce qui rend cette recherche de qualité inutile sur Nuked-Klan bien que ca soit un CMS.

Enfin de toute facon je ne peux pas participer à un tel projet. Peut-etre que ca fait plaisir a la communauté ce genre de gestion très particulière, mais c'est handicapant pour une carrière professionnel. Vous comprenez  que si pendant un entretien d'embauche pour être ingénieur je dis que j'ai géré le projet NK et qu'il y a un retard moyen de 6 mois sur les différentes dates de sortie et que la compatibilité arrière n'est pas conservé sur les différentes releases candidate de la même version, je ne suis même pas sur que le recruteur veuille bien m'embaucher comme développeur...