100830 5 min

La densité du code

La densité du code


L'énorme gain de poids du code est due à une recherche spécifique en terme de densité.

C'est le chargement du programme qui prend 90-95% du temps de génération de la page, et pourtant les serveurs sont très puissants. Pas mal de CMS pèsent 10Mo, et chargent le serveur comme une mule, et ce à chaque page. Ce qui représente une lourdeur d'une conséquence formidable à l'échelle d'internet.

Ainsi le rapport entre le poids, la charge demandée au processeur, et le nombre de fonctionnalités qui entrent en jeu au cours d'une opération (souvent bourrée d'automatismes), peut se nommer la densité du système. En gros, c'est cosmique, il s'avère préférable pour la performance que le logiciel soit écrit de la façon la plus méticuleuse possible.

En l'occurrence, dans 343 859 bytes (poids total du logicel) on a 596 fonctions soit 577 caractères en moyenne par fonction, sans compter le poids de l'index qui est écrit en dur (tout n'est pas robotisé à l'extrême non plus sinon le processeur souffre).
Si on voulait battre un record on pourrait encore compresser de 50%, ce serait marrant à faire. Mais comparé aux autres CMS, si celui-ci a une densité de 50, la leur est de 10.

C'est un enjeu important, plus d'intelligence dans le code va devenir la seule source de richesse dans le futur !

Plusieurs facteurs font la densité du système, la façon dont il est rédigé, la façon dont il est construit au niveau logique (les deux se nomment confusément l'écriture), la profondeur avec laquelle il est automatisé, et l'intelligence que permet la rigueur des protocoles.

Au niveau de la rédaction, il faut bannir l'alternance php/html dans une page, cela est hautement interdit ! Tout doit être écrit en PHP, et les chaînes de caractères doivent autant que possible être produites par des fonctions. C'est cela qu'on nomme la profondeur de l'automatisation.

Au niveau structurel, il s'est agit de démonter des sources et n'en conserver que les principes élémentaires et indivisibles. C'est cela la bonne base à partir de laquelle construire les premières routines les plus usitées.
Souvent, par exemple le calendrier, les codes sources sont énormes (70Ko), mais les principes élémentaires sont très classiques, ainsi la calendrier de philum s'écrit en une vingtaine de lignes de code ; et 35 lignes pour faire un forum en ajax avec différents fils de discussion.

Bannir l'orienté objet

Il est certain que la plupart des développeurs vont être surpris en voyant le style d'écriture du code... autant que nous le somme en voyant le leur !

C'est même bizarre de voir tous les développeurs utiliser exactement la même densité, à savoir très faible, comme si elle était héritée sans faire exprès. Mais en programmation il faut tout repenser tout le temps. Aucune action ne doit être répétée manuellement, et cela s'entend à un grand nombre de niveaux.

Il y a que quand on doit écrire une fonctionnalité, on préfère la pondre d'un jet plutôt que poliment se référer aux routines existantes, et si l'occasion se présente, écrire les routines et sous-routines qui auraient dû l'être, et qui peuvent servir ailleurs, et qui doivent être créées, tout en sous-pesant leur utilité future. Une fois le job initial terminé, reste à aller appliquer les bonnes nouvelles aux endroits où on aurait besoin de la nouvelle sous-routine.
Quand on travaille pour un patron, même très sympa, on n'a pas tout le temps qu'on voudrait pour faire tout cela, et à ce qu'il semble, ni même le temps pour y penser.

L'utilisation des classes n'est pas l'apanage du modus operandi d'écriture "orienté objet".
Déjà au moins avec le mode procédural on peut créer de réels "objets" dans le sens où quand on a besoin d'une fonctionnalité, on sait où la trouver, mais à condition de respecter un principe élémentaire qui change tout :

Les fonctionnalités sont toujours écrites selon un protocole de poupées russes.
Cela fait qu'il y a de nombreuses fonctions très standards qui sont utilisées un grand nombre de fois. Or ce n'est pas possible de faire un script écrit à la mode fractale avec la POO (Poah!).
Cette façon d'écrire, innovante, on n'a qu'a l'appeler la programmation orientée WOAOUH !





Les petites fonctions sont appelées par les plus grandes, et selon les besoin on appelle soit des petites soit des moyennes, soit des grandes fonctions, qui utilisent implicitement les autres, en s'épargnant le code inutile.
Et si le processus disponible est inadapté comme souvent, il suffit de reprendre différemment les chacun de ses processus internes.

Il est arrivé de n'avoir qu'à rajouter un branchement pour faire émerger des fonctionnalités d'une puissance surprenante, par exemple la réception de flux rss combinée à l'enregistrement d'articles en série.

C'est là que le lecteur curieux peut s'apercevoir de l'intérêt de ce qui est protocolaire dans un logiciel (qui fabrique une raison, pensez à toutes les fois où il vous semble avoir raison, c'est pareil !). C'est la compatibilité entre les objets qui fait la puissance du logiciel (et donc du calcul qui produit la raison !)

En gros vous pouvez imaginer que pour créer une fonction de la dimension du grand oval, il n'y a qu'à écrire la partie qui n'inclue pas les autres fonctions. Cette manière de travailler est dite incrémentielle (toute l'intelligence développée s'ajoute et ne se perd pas).

Par la suite ce concept s'est étendu de façon surprenante, au point de créer des protocoles très sévères (des habitudes guidées par la paresse en fait !), de façon à produire un logiciel d'une très grande fiabilité, complexité, et avec un potentiel de développement qui ne fait qu'accroitre avec le temps (là où le plus souvent les logiciels s'empêtrent dans leur complexité).

D'ailleurs il serait vraiment temps de créer des ressources brutes, quitte à ce qu'on nomme "logiciel" le petit script qui les utilise en allant les piocher sur différents serveurs... (ah futur quand tu nous tiens)

Le code est consultable en ligne.