Tweet
William Edwards, un développeur “senior” attire l’attention dans un article de blog sur les choix des développeurs qu’il appelle « modernes » et qui pour lui auraient de très mauvais effets sur l’industrie.
Les développeurs opteraient de plus en plus pour une multitude de bibliothèques externes modernes pour la conception d’une application.
Ces bibliothèques, bien qu’offrant chacune de bonnes performances, seraient utilisées sans une réelle maîtrise des spécificités de celles-ci, et le produit qui en ressortirait serait souvent complexe, et dans la plupart des cas assez difficile à maintenir voire peu performant.
William Edwards part d’un commentaire d’un lecteur sur un article qui expliquait comment l’outil NooSFere peut comprimer à 90% des emails.
L’application NooSFere utilise un cache avec l’algorithme LRU (Least Recently Used). Les mails deviennent une liste de pointeurs de chaine partagée et la compression est effectuée en arrière-plan en utilisant l’algorithme de compression de données LZMA (Lempel-Ziv-Markov chain-Algorithm).
L’utilisation uniquement des ressources du langage (table de hachage Java normale et listes liées) ayant permis un gain de performance énorme a été cependant critiquée par un développeur.
Celui-ci dans son commentaire se demande pourquoi Redis (système de gestion de base de données NoSQL, clef-valeur libre, scalable, hautes performances) n’a pas été utilisé dans le projet pour la LRU. Proposition qui est soutenue par une autre personne qui trouve que Redis couplé à node.js sont connus pour être assez performants. Donc, une orientation vers une solution Web.
« Les projets sont de plus en plus des sites Web » regrette Edwards, qui ajoute. « Vous n’avez pas besoin d’être un puissant programmeur. Vous pouvez utiliser JavaScript, exécuter node.js et utiliser MongoDB ou Redis en arrière-plan et vous pensez que votre solution est performante ? ».
De façon générale pour William Edwards, les développeurs optent beaucoup plus pour la facilité que pour la simplicité. Résultat, ils se retrouveraient très souvent avec des solutions complexes disposant de plusieurs briques logicielles (bases de données NoSQL, interfaces, divers scripts issus des copier/coller, bibliothèques d’accès aux données, etc.) et peu performantes.
« Il y a une nouvelle mentalité – un mouvement moderne – le développement d’une application revient à réfléchir sur comment relier une constellation de composants logiciels différents […] ils veulent utiliser tous les nouveaux outils qui brillent» conclut Edwards.
Pour lui, il serait presque toujours préférable d’utiliser une base de données locale (sqllite, levelDB, BDB etc.), un langage rapide reposant sur un runtime (et éviter les langages dynamiques), et utiliser le moins de machines possible pour effectuer une transaction (le premier ennemi de la performance serait le nombre de machines).
Bref, un avis tranché qui ressemble fort à une incompréhension générationnelle. Mais qui n’est pas dénué d’analyse.
Un avis, en tout cas, qui suscite débat et réactions.
Source : Developpez
Les développeurs opteraient de plus en plus pour une multitude de bibliothèques externes modernes pour la conception d’une application.
Ces bibliothèques, bien qu’offrant chacune de bonnes performances, seraient utilisées sans une réelle maîtrise des spécificités de celles-ci, et le produit qui en ressortirait serait souvent complexe, et dans la plupart des cas assez difficile à maintenir voire peu performant.
William Edwards part d’un commentaire d’un lecteur sur un article qui expliquait comment l’outil NooSFere peut comprimer à 90% des emails.
L’application NooSFere utilise un cache avec l’algorithme LRU (Least Recently Used). Les mails deviennent une liste de pointeurs de chaine partagée et la compression est effectuée en arrière-plan en utilisant l’algorithme de compression de données LZMA (Lempel-Ziv-Markov chain-Algorithm).
L’utilisation uniquement des ressources du langage (table de hachage Java normale et listes liées) ayant permis un gain de performance énorme a été cependant critiquée par un développeur.
Celui-ci dans son commentaire se demande pourquoi Redis (système de gestion de base de données NoSQL, clef-valeur libre, scalable, hautes performances) n’a pas été utilisé dans le projet pour la LRU. Proposition qui est soutenue par une autre personne qui trouve que Redis couplé à node.js sont connus pour être assez performants. Donc, une orientation vers une solution Web.
« Les projets sont de plus en plus des sites Web » regrette Edwards, qui ajoute. « Vous n’avez pas besoin d’être un puissant programmeur. Vous pouvez utiliser JavaScript, exécuter node.js et utiliser MongoDB ou Redis en arrière-plan et vous pensez que votre solution est performante ? ».
De façon générale pour William Edwards, les développeurs optent beaucoup plus pour la facilité que pour la simplicité. Résultat, ils se retrouveraient très souvent avec des solutions complexes disposant de plusieurs briques logicielles (bases de données NoSQL, interfaces, divers scripts issus des copier/coller, bibliothèques d’accès aux données, etc.) et peu performantes.
« Il y a une nouvelle mentalité – un mouvement moderne – le développement d’une application revient à réfléchir sur comment relier une constellation de composants logiciels différents […] ils veulent utiliser tous les nouveaux outils qui brillent» conclut Edwards.
Pour lui, il serait presque toujours préférable d’utiliser une base de données locale (sqllite, levelDB, BDB etc.), un langage rapide reposant sur un runtime (et éviter les langages dynamiques), et utiliser le moins de machines possible pour effectuer une transaction (le premier ennemi de la performance serait le nombre de machines).
Bref, un avis tranché qui ressemble fort à une incompréhension générationnelle. Mais qui n’est pas dénué d’analyse.
Un avis, en tout cas, qui suscite débat et réactions.
Source : Developpez
Commentaire