Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Quelque chose ne va vraiment pas avec les développeurs "modernes" »
Un développeur à "l'ancienne" critique la multiplication des bibliothèques

Le , par Hinault Romaric

45PARTAGES

19  0 
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.

Le billet de blog William Edwards

Et vous ?

Partagez-vous le point de vue de William Edwards ?

Pensez-vous que le choix de plusieurs outils récents pour développer un produit n’est pas le meilleur ?

Vous reconnaissez-vous dans sa définition d’un “développeur moderne” ? Et que lui répondriez-vous ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de zeyr2mejetrem
Membre chevronné https://www.developpez.com
Le 06/03/2012 à 17:52
Citation Envoyé par deathness Voir le message
Apparemment il fustige les dev qui suivent à l'excès l'école de pensée "ça sert à rien de réinventer la roue".

Tout dépend du contexte, c'est franchement dur de répondre comme ça.

A mon avis la question c'est plus:
quel doivent être les critères pour juger si on peut réutiliser de l'existant?

Des choses comme le fait que l'existant soit open ou close-source, maintenu ou non, criticité de la chose, etc...
Je pense surtout qu'il est comme beaucoup de monde ... excédé de se récupérer des usines à gaz.

En PHP il n'était pas rare que je me retrouve à faire de la maintenance logicielle sur des applis déployant toute l'infra Zend_Framework ... juste pour pouvoir exécuter des requêtes dans une base de donnée sans avoir à écrire l'ouverture de connexion

Il est clair qu'on ne doit pas réinventer la roue ... mais parfois ca peut être salutaire pour la maintenance de se demander si on utilise pas le marteau pour écraser la mouche.
16  0 
Avatar de kolodz
Modérateur https://www.developpez.com
Le 06/03/2012 à 18:30
Cette après-midi, j'ai eu une réunion sur l'ajout d'un outil sur le site sur lequel je fait de la "maintenance et amélioration". (Comprendra qui voudra)

Le but étant de :
Savoir si la page convertit... mieux.. dans cette configuration...
Logiquement, je répond qu'on a déjà des outils d'analyse sur tout le site et que je ne vois pas pourquoi ils ne peuvent pas faire l'affaire.

J'ai pour simple réponse qui justifie tout :
Si les grosses sociétés l'utilisent, c'est qu'elle est forcément mieux.(1)
Je répond donc :
Je remplace donc les outils actuelles par celui-ci ? Vue qu'ils ont aussi pour but de savoir si nos pages convertisses...

Tout ça pour dire qu'il est parfois difficile d'être un développeur ( au service du client) moderne.

Le problème n'est pas de savoir si la librairie est nouvelle ou non. Mais de savoir si celle-ci n'est pas en doublon ou s’intègre à l'environnement pré-existant.

Cordialement,
Patrick Kolodziejczyk.

(1) : Argument du pseudo technicien-marketeux(2)
(2) : Marche aussi avec pseudo développeur ou tout autre variante
12  0 
Avatar de nflowerpower
Membre du Club https://www.developpez.com
Le 06/03/2012 à 17:53
Deathness, tu commentes alors que tu n'as même pas lu l'article....

Et pour gagaches, ne te focalise pas sur un des exemples qu'il donne.

L'idée générale de ce poste; c'est essentiellement de critiquer la manie qu'on les nouveau développeur à vouloir absolument utiliser toutes les technologies les plus récentes en oubliant de répondre à cette question essentielle:
- quelle(s) technologie(s) va être la plus efficace pour répondre à mon problème.

Avec pour résultat, des applications complexes souvent peu performante, mais utilisant de nombreux outils/langages/framework modernes.
Alors qu'un résultat plus performant aurait pu être obtenue en utilisant moins d'outils/langages (qu'il soit moderne ou non

Cogs bad = les engrenages, c'est mal.

En effet, à vouloir utiliser de trop nombreux outils/langages/framework (pour ne pas réinventer la roue); le développeur crée une très grand complexité pour faire fonctionner ensemble tous ces éléments qu'il a choisis, non pas parce qu’ils répondent à un besoin, mais parce que c'est à la mode de les utiliser.
14  3 
Avatar de arkhamon
Membre éprouvé https://www.developpez.com
Le 14/03/2012 à 14:08
Bonjour a tous,

moi je vais me contenter de faire 3 constats et de poser une question. Mes constats :
  • pour piloter un airbus A330, ue compagnie aérienne embauche un pilote de ligne diplôme en aviation civile, et pas un jardinier, aussi doué soit-il avec son avion radio commandé...
  • Pour faire de la chirurgie cardiaque, un hôpital embauche un chirurgien cardiaque diplômé en chirurgie et spécialisé en cardiologie et pas un plombier, aussi doué soit-il avec des tuyaux...
  • pour construire un immeuble, on prend un architecte diplômé, avec une spécialisation en IGH, et pas un môme de 8 ans, aussi doué soit-il avec ses légos...

Ma super question de la mort qui tue :
Alors pourquoi par tous les saints du ciel continue-t-on à prendre n'importe qui (et pas des informaticiens diplômés et spécialisés) pour faire de l'informatique ?????????????????

Il fut un temps où le développement d'application était confié à des analystes-programmeurs (et pas à un chef de projet ingénieur spécialisation 3ème année en finance internationale), car de façon étrange et amusante... C'EST LEUR METIER !!!!!
Il fut un temps où on apprenait aux programmeurs une règle simple : "Un ordinateur c'est comme les chiottes, on est prié de le laisser en sortant dans le même état qu'on les a trouvés en entrant". Ca va paraître vieux jeu, mais ça met à l'abri des "fuites mémoires".

Maintenant, n'importe quel guignol qui sort d'une pseudo école d'ingénieur en informatique (mais avec option Finance en 3ème année) voire d'une sup de co et qui a pondu 3 lignes de code en C++, un petit serveur en PHP et 2 requêtes SQL sur un pseudo projet se retrouve bombardé "Développeur". Le mieux, c'est qu'au bout d'un an, on le nomme très officiellement "Sénior" sur son périmètre.

Après les DSI s'interrogent sur la source des "incidents de production" et lancent des grands chantiers de "stabilisation de la production".

Georges Clemenceau avait si mes souvenirs sont bons déclaré : "La guerre est une chose trop sérieuse pour qu'on la confie à des militaires".

Je vous en propose une autre : "L'informatique est une chose sufisamment sérieuse pour qu'on la confie à des informaticiens." Celle là est de moi.

Un vieux dinosaure... de 45 ans...
12  1 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 07/03/2012 à 7:34
Premier point, je suis d'accord avec lui.

Second point, ce n'est pas toujours possible de programme "de la bonne façon".

Dans une société ou les développeurs se suivent (parce que les salaires ne sont pas suffisants, les cahiers des charges inconsistants, les horaires flexibles...etc, etc...) il est plus efficace d'avoir recours à des frameworks "connus" que sur du code interne.

D'ailleurs on voit plus souvent des offres "Développeur Symfony" que "Developpeur PHP", ou "Développeur jQuery" qui "Développeur Javascript", etc...

Tout simplement parce que le nouveau développeur n'aura pas besoin d'apprendre le framework interne pour bosser, il arrive avec un savoir externe immédiatement utilisable.

L'autre tendance c'est l'architecture logicielle, on ne programme plus on travaille sur des concepts haut niveau. L'objectif est là encore la productivité, "ne pas réinventer la roue"...mais tout cela bien souvent au détriment des performances.

Quelque part ça ne me dérangerais pas si les "nouveaux développeurs" ne connaissaient pas QUE ça ! Si on commençait par du haut niveau, du framework 2.0, et qu'ensuite on s'intéressait à l'optimisation quand c'est nécessaire en tapant dans les couches basses pour éviter les lourdeurs inhérentes à ces modèles de développement.

Mais justement, le "nouveau développeur" ne sait pas ce qu'il se passe dans les couches basses, ou pire encore, il l'a oublié ! Il s'est fait sué pendant ses études à faire de l'algorithmique mais ne sais plus faire une recherche dichotomique et ne sais même plus ce que c'est...alors il serait bien en mal de faire mieux qu'un framework !

En résumé ce qui me chagrine ce n'est pas l'évolution des méthodes de travail, c'est la perte de compétence qui va avec.
10  0 
Avatar de Pergos
Membre habitué https://www.developpez.com
Le 07/03/2012 à 9:19
@zePangolin le problème de la curiosité, c'est qu'il faut du temps pour la mettre en oeuvre...
Dans toutes les boites que j'ai faites à l'exception de la première (mais les assurances, en même temps, ca compte qu'à moitié : ils avaient de l'argent à perdre ! -ou à investir, dépend du point de vue-), les plannings sont calculés serrés : 5J de dev = 1S dans le planning ! Aucun temps réservé pour de la veille, pour gratter un peu du vieux code, pour faire du refactoring,...
Y a même un boite où ils s'étonnaient qu'on prenne du retard sur les dev alors qu'on croulait sous la maintenance (donc pression, donc codage à la va-vite -parce qu'on est humain quand même-, donc bugs, donc maintenance...).

J'ai aussi fait une boite où on te demandait de coder en repompant d'un projet sur un autre, je cite "sans se poser de question"... Tout ça parce que les spec n'étaient pas signées mais que si on ne démarrait pas le dev, on serait dans les choux... Moralité : trois refontes du cahier des charges avant signature finale des spec par le client, et au moins autant de refonte du code, un projet à dégueuler sur place, conspué par un client mécontent et du résultat, et du temps pour en arriver là !!! (et les dev en ont pris plein la gueule, bien entendu ! -après, on s'étonne qu'on reste pas en place !-).

Bref, en se posant des questions sur les dev et leur manière de faire les choses, regardons aussi l'ensemble de l'industrie logicielle : des clients qui croient que "y a qu'à, faut qu'on" à coup de baguettes magiques pour trois-francs-six-sous, des responsables qui croient dur comme fer au "copier-coller" du code décontextualisé ("y a juste à faire comme là" "ouais, mais là, c'est un script SQL qui prend des données extraites d'un tableau excel où une macro VB calcule ta clé cryptée..." "oui, c'est ce que je dis : faut juste refaire tout le truc dans la proc stock oracle, c'est exactement la même chose, doit pas y en avoir pour longtemps" "heu...), de dev qu'on pressurise à coup de "on pourrait déporter le plateau en Inde, vous savez",...

J'adore mon taf, mais y a des jours où quand même, marcher sur la tête me sort par les yeux.......
10  0 
Avatar de deathness
Membre émérite https://www.developpez.com
Le 06/03/2012 à 16:43
Apparemment il fustige les dev qui suivent à l'excès l'école de pensée "ça sert à rien de réinventer la roue".

Tout dépend du contexte, c'est franchement dur de répondre comme ça.

A mon avis la question c'est plus:
quel doivent être les critères pour juger si on peut réutiliser de l'existant?

Des choses comme le fait que l'existant soit open ou close-source, maintenu ou non, criticité de la chose, etc...
11  2 
Avatar de mithraw
Nouveau membre du Club https://www.developpez.com
Le 06/03/2012 à 18:28
Je pense un peu comme lui...
Je dois dire que souvent, les frameworks/api fournissent beaucoup plus de fonctionnalités que celles qui sont réellement nécessaire au fonctionnement du soft, on se retrouve a embarquer un grand nombre de truc dont 10% sera utilisés...

Ca permet certes d'avoir un bon potentiel d'évolutivité du soft, mais ça a la risque d'alourdir énormement le tout.

Me concernant il m'est déjà arrivé par exemple de recoder un client xml / webservice, ca m'a pris 3 jours a partir de libs de bases tel que tinyxml et libcurl (pour du c/c++) et ca m'a permis de m'affranchir d'usines a gaz monstrueuses.
9  0 
Avatar de Guilp
Membre éprouvé https://www.developpez.com
Le 07/03/2012 à 9:25
Attention à ne pas faire de généralités. J'ai déjà connu tout un coeur d'une grosse appli fait en natif, parce que "ça sera sur mesure, plus rapide, plus optimisé", etc. Et au final, on a quelque chose de lourd, mal pensé, mal construit, pas maintenable, où seulement le gars qui l'a fait sait se relire (et encore), une grosse usine à gaz que personne ne veut toucher.

Bref, pour moi, le sujet, c'est pas framework ou pas framework, mais c'est d'avoir du discernement ou pas. L'ennemi, dans tout ça (et c'est comme ça que j'ai compris l'auteur de l'article), ce sont les effets de modes qui conduisent à des choix immatures. (et en l’occurrence, comme le pointe l'article, certains choix de framework/lib sont des effets de mode).

Choisir de faire le cœur de son appli en C++ natif parce que "le c++ c'est bien, c'est rapide", ou choisir du "spring-hibernate-maven-struts" parce que "c'est génial", c'est tout aussi dangereux quand on ne connait pas ses limites, ses compétences.

Le discernement... C'est choisir ses outils (et ses employés) en fonction des objectifs de performance, maintenabilité, qualité, qui dépendent tellement du contexte de chaque projet que ça n'a rien à voir avec la question générale du "framework ou pas framework".
8  0 
Avatar de FR119492
Rédacteur https://www.developpez.com
Le 14/03/2012 à 16:02
Salut!
"L'informatique est une chose suffisamment sérieuse pour qu'on la confie à des informaticiens."
Oui et non, selon les cas. S'il s'agit d'un projet purement informatique, tu as certainement raison. En revanche, ayant travaillé de nombreuses années dans l'industrie, j'ai constaté que lorsqu'on devait faire du calcul numérique (par exemple calculer la répartition du champ magnétique dans un four d'électrolyse pour la production d'aluminium), les purs informaticiens étaient inutilisable parce qu'ils ne connaissaient rien d'autre que l'informatique.

Je ne nie donc pas l'importance des purs informaticiens, mais je crois qu'on doit parallèlement former des ingénieurs généralistes qui doivent connaître à fond
  • les mathématiques,
  • le calcul numérique,
  • la physique,
  • la programmation.


Un encore plus vieux dinosaure... de 71 ans...
8  0