Réflexion sur le métier

Salut à tous,

Je me suis fendu d'une diatribe sur le développement web (Surtout côté front-end, en fait) et son évolution : http://www.emmanuelbeziat.com/blog/le-probleme-du-dev-web-daujourdhui/

Je lance la discussion autour de ce sujet. Professionnels du milieu (et amateurs aussi, hein), quels sont vos avis ?

Bonsoir,

Voilà mon point de vue de jeune diplômé en informatique. Pour le moment je ne suis pas encore dans le monde professionel donc mon avis n'est peut-être pas le bienvenu, dans ce cas désolé, je supprimerai ce message le cas échéant.

Je ne vais pas m'étendre beaucoup sur tous les outils que tu cites parce que je n'en connais pas (encore) les trois quarts; je serais donc bien en peine de les critiquer précisément. Par contre j'aimerais revenir sur deux choses :
1 - La ligne de commande
2 - La perte de contrôle du code

Tu critiques la ligne de commande comme étant archaïque et tu souhaiterais des interfaces graphiques plus sympathiques à la place.
L'inconvénient de la ligne de commande c'est que c'est fondamentalement du code, et il faut donc de la doc et du temps pour apprendre à bien s'en servir. Le coût d'entrée en temps ou en ressources intellectuelles est cher au début.
Par contre l'énorme avantage est que c'est facilement scriptable. Si tu gères 1000 projets à peu près identiques, tu seras bien content d'avoir fait un petit script qui construit une nouvelle VM et qui installe tout ce qu'il faut dedans. Avec une superbe interface graphique tu prendras en main le logiciel en 5 minutes mais quand il faudra faire 1000 fois la même chose tu seras vite saoulé. En plus tu peux planifier ton script pour qu'il s'exécute en ton absence.

Si tu ne gères pas 1000 projets en même temps et si tu ne prévois pas d'en gérer 1000 un jour, bien sûr, l'investissement d'entrée peut te paraître prohibitif. Tant pis, c'est pas grave, tu n'es pas obligé de tout configurer à la ligne de commande non plus, personne ne t'y force.
En outre on a déjà pu prouver dans pas mal de domaines que l'utilisateur clavier va plus vite que l'utilisateur souris (En réalité c'est surtout les va-et-vient entre le clavier et la souris qui font perdre du temps)

Expérience perso, une fois qu'on a pris le pli d'utiliser un outil en ligne de commande, bien souvent on a l'impression de perdre son temps avec un logiciel graphique qui fait la même chose. C'est terriblement ch#@%$, ces boîtes de dialogue interminables avec 18 onglets où il faut faire 36 fois Suivant, Suivant, Suivant, J'accepte, OK, OK, OK, OK, casse-toi, OK, ouf enfin.
JE vois ça avec TortoiseGIT, ou encore le logiciel graphique de GITHub... c'est une galère, la terminologie change pour rien et on est perdu... au contraire, en ligne de commande on finit par connaître les commandes courantes par coeur et pour le reste, git help ouvre une page de doc.

Bon, on n'est bien d'accord que la ligne de commande ne va pas pour tout non plus. Je ne remplacerais pas mon éditeur de texte habituel par vi par exemple; pas plus que les graphistes ne pourraient pas remplacer leur photoshop
IL faut savoir prendre le meilleur des deux mondes selon ce qu'on veut faire et où on est à l'aise. C'est un simple constat personnel.

En ce qui concerne les dépendences qui dépendent des dépendences qui nécéssitent l'installation d'un logiciel de configuration du gestionnaire d'importation pour installer un package, le risque c'est la perdte de contrôle du code.
ON ne comprend plus ce que fait tel code parce qu'il a été automatiquement généré par un machin lourdingue et du coup on obtient un super truc pas optimisé dont 90% est inutile et dont on est incapable de le modifier parce qu'on a pas compris ce qu'il faisait et comment il le faisait. Mais on s'en contrefout puisque ça marche. On n'a qu'à prendre plus de serveurs et personne n'y verra rien.
Je carricature un peu mais sur ce point, j'ai l'impression d'être d'accord avec toi. ON dirait de la sophistication excessive. Je ne sais pas trop comment aborder cette question et il commence à se faire tard, mais c'est une question intéressante.
Peut-on se permettre de perdre le contrôle de son code et jusqu'à quel point ? Inversément, peut-on faire confiance ? Est-ce que c'est une fatalité ?
Puisque c'est générique, c'est pas forcément super optimisé, super accessible et super pratique à modifier ou à maintenir. Ca marche, est-ce qu'on s'en fout du reste ? En même temps le dicton dit que le mieux est l'ennemi du bien.

ET le jour où ça explose on est dans la m#@%e parce que c'est le bidule chose qui est dans la bibliothèque truc de la dépendence machin truc chouette qui a cramé et personne ne sait vraiment comment ça fonctionne... on s'était dit qu'on ne réinventerait pas la roue pour gagner du temps, mais visiblement on aurait dû... parce qu'évidemment on connaît le code qu'on a soi-même conçu (le contraire serait quand même regrettable). L'improbable est arrivé, il y a un bug ou une faille dans un code qu'on n'a pas soi-même écrit.

Enfin bref je divague, bone nuit. Peut-être que quelqu'un saura remettre un peu d'ordre dans mes pensées sur ce second sujet.
Modifié par QuentinC (08 Oct 2015 - 00:17)

Merci pour ton retour. Ton avis est parfaitement bienvenue, ne supprime rien !

Tes remarques sont pertinentes, et je n'avais pas vraiment développé la "perte de contrôle" autant que toi... Effectivement, c'est un sujet important. Mais comme je n'y ai pas encore réfléchi, je vais me garder ça pour demain, à tête reposée.

Je vais moi aussi revenir sur quelques points que tu soulèves à propos de la commande :

a écrit :
Si tu gères 1000 projets à peu près identiques, tu seras bien content d'avoir fait un petit script qui construit une nouvelle VM et qui installe tout ce qu'il faut dedans. Avec une superbe interface graphique tu prendras en main le logiciel en 5 minutes mais quand il faudra faire 1000 fois la même chose tu seras vite saoulé. En plus tu peux planifier ton script pour qu'il s'exécute en ton absence.

Justement, je pense que c'est dans cette séparation que se trouve le cœur du problème : pourquoi est-ce que le logiciel graphique ne pourrait pas faire exactement ce processus d'installation, répétable à souhait, planifiable pour bosser en ton absence ?

Ça rejoint un peu ce point :

a écrit :
chose. C'est terriblement ch#@%$, ces boîtes de dialogue interminables avec 18 onglets où il faut faire 36 fois Suivant, Suivant, Suivant, J'accepte, OK, OK, OK, OK, casse-toi, OK, ouf enfin.

Là, c'est un cas classique de mauvaise conception du logiciel. Mais l'un dans l'autre, une app en ligne de commandes mal foutue posera autant de problèmes d'ergonomie, alors qu'une app graphique bien pensée pourra faire gagner un temps fou.

L'idée est là pour moi : que ce soit entrer une commande avec une liste de paramètres ou cocher des cases avant de cliquer sur un bouton de validation, dans les deux cas ça appelle une fonction et ça lui passe les paramètres en question.

Un exemple simple :

superapp dep -R -g "site" "nike"

Si je tombe sur ça, je n'ai aucune idée de quoi il s'agit. Il me faut la doc. Si j'ai l'habitude de cette commande mais que je veux une option différente, il me faut la doc. Impossible de savoir à quoi -R correspond.

On prend la même chose avec une interface graphique, une case qui permet de cocher "dépendances" (dep), de choisir les options avec des labels beaucoup plus explicites que -R et -g, un champ pour écrire "site" et un dropdown pour choisir le client (nike), et un bouton valider.

Oui, on va perdre du temps à faire les manips à la souris ; mais ce même temps, on va le gagner lorsqu'on veut tout simplement modifier une option, qui nécessitera de cocher une case labellisée alors qu'il faudra ouvrir la doc et chercher la commande correspondante dans l'autre cas.

Alors je ne vois pas de "solution" moi-même pour ça, mais je pense qu'il y a quelque chose à chercher entre ces deux extrêmes pour trouver un équilibre. Quelque chose qui permette de se passer d'une terminologie obscure qui ne se maîtrise qu'au bout de la quinzième itération (et encore, lorsqu'elle est parfaitement identique à chaque coup), et une interface simple mais qui induis une perte de temps plus ou moins lourde.

Je n'arrive pas à me dire que ce que fait une ligne de commande, on ne pourrait pas le faire de façon graphique aussi efficacement ; j'ai surtout l'impression que pour l'instant, personne n'a cherché à obtenir un tel résultat, et que c'est là que réside le problème, plus que dans la "possibilité".

J'ai un exemple simple à ça : jusqu'ici, j'utilisais un script maison à lancer via la commande pour renommer des fichiers multiples, à travers un ensemble de sous-dossiers ou non, avec différentes options. C'est moi qui l'avait fait, mais je me perdais déjà dans mes options tellement il fallait prévoir de scénarios possibles... Au final, en fonction des besoins (chaque "renommage" pouvant être différent), je passais une heure à relire ma propre doc. Quant au résultat, hé bien je ne le voyais qu'après avoir lancé la commande. Puis, j'ai découvert Advanced Renamer, un logiciel graphique qui fait EXACTEMENT ce que je faisais jusque là, mais avec une interface... Plus besoin de fouiller dans mes notes, tout est labellisé, et je vois un aperçu du résultat avant de lancer le traitement. En sus, j'ai accès à beaucoup plus d'options que je n'aurais pu le prévoir moi-même.

Je m'égare un peu, je pense en effet que l'heure n'aide pas. Encore merci pour ta réflexion, n'hésite pas à la pousser plus loin !

a écrit :
Justement, je pense que c'est dans cette séparation que se trouve le cœur du problème : pourquoi est-ce que le logiciel graphique ne pourrait pas faire exactement ce processus d'installation, répétable à souhait, planifiable pour bosser en ton absence ?

Ca dépend toujours comment le logiciel a été conçu. Si c'est une simple surcouche graphique qui lance en fait des outils en ligne de commande, il y a moyen de le faire.
Sinon, eh bien, les macros et les langages de script qui commandent de cliquer là, de faire trois fois tab, deux fois enter et de double-cliquer trois fois de suite, ça existe, mais c'est tout de suite plus compliqué à concevoir et à gérer qu'un script de commandes texte.

Un des autres gros avantages à la ligne de commande que j'ai oublié hier soir, c'est la portabilité. très souvent ces outils marchent indifféremment sous windows, sous linux et sous mac, et le portage n'est pas si compliqué, d'autant plus si on utilise un langage multiplateforme comme Java, python, Node.js...

Les interfaces graphiques multiplateformes existent, p.ex. WXWidgets, QT, Java Swing ou SWT... mais c'est rapidement compliqué pour la portabilité. IL y a deux écoles qui s'affrontent.
1 - L'école du « je veux que mon app ait exactement le même look partout », et
2 - l'école du « je veux utiliser au maximum les composants natifs du système et que mon app s'intègre au maximum au système et à son look classique »
L'école n°1 est une catastrophe pour l'accessibilité et la lourdeur générale, tandis que l'école n°2 énerve les gens qui sont très visuels et/ou attachés à un affichage graphique irréprochable quelque soit le cas (graphistes, 3D et autres).
On pourrait faire le même parralèle entre print vs screen, ou entre PDF vs HTML/CSS.

a écrit :
J'ai un exemple simple à ça : jusqu'ici, j'utilisais un script maison à lancer via la commande pour renommer des fichiers multiples, à travers un ensemble de sous-dossiers ou non, avec différentes options. C'est moi qui l'avait fait, mais je me perdais déjà dans mes options tellement il fallait prévoir de scénarios possibles... Au final, en fonction des besoins (chaque "renommage" pouvant être différent), je passais une heure à relire ma propre doc. Quant au résultat, hé bien je ne le voyais qu'après avoir lancé la commande. Puis, j'ai découvert Advanced Renamer, un logiciel graphique qui fait EXACTEMENT ce que je faisais jusque là, mais avec une interface... Plus besoin de fouiller dans mes notes, tout est labellisé, et je vois un aperçu du résultat avant de lancer le traitement. En sus, j'ai accès à beaucoup plus d'options que je n'aurais pu le prévoir moi-même.

A chacun son système pour être efficace. Personnellement, dans ce genre de cas, mon réflexe c'est de faire rapido un petit script, par exemple en php ou en python. ON peut aussi utiliser perl ou faire du shell.

Pas plus tard qu'hier, pour un projet perso, j'ai fait un script de ce genre pour faire un remplacement multiple dans une centaine de fichiers :

<?php
foreach(glob('*.txt') as $file) {
$text = file_get_contents($file);
$text = preg_replace(......);
$text = preg_replace(......);
$text = preg_replace(......);
file_put_contents($file, $text);
}

Ca m'a pas pris plus que 5 minutes, il m'aurait probablement fallu plus de temps et plusieurs passes dans un logiciel graphique.
Modifié par QuentinC (08 Oct 2015 - 08:56)