IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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 !

Le développeur s'éloignerait de plus en plus de son activité principale : le codage !
Voilà le constat amer d'un passionné de programmation

Le , par Arsene Newman

27PARTAGES

10  0 
« Laissez-moi juste coder ! » voilà donc le titre du billet d’Andrews Binstock, éditeur en chef de chez Dr.Dobb’s qui estime que le développeur s’éloigne de plus en plus de la tâche la plus basique, la plus ludique et créative de son travail: coder.

Coder est l’activité la plus satisfaisante pour le développeur, car elle lui permet d’exercer sa créativité et son génie, elle permet aussi de lui donner ce sentiment de joie, de satisfaction et d’achèvement si chers à lui, lorsque son application répond parfaitement aux cahiers de charge et aux souhaits du client.

Toutefois, le développeur tend actuellement à s’éloigner de plus en plus de cette activité et pour Benstock : « Ce qui pouvait se rapporter à conduire une simple bicyclette est devenu l’équivalent de voyager avec un avion de ligne avec tout ce que cela implique comme : retards, inspections, limitations sur les choix personnels et des annulations inexpliquées, le tout à un coût sensiblement plus élevé. » Alors où est la joie et la satisfaction dans tout cela ?

Aux premiers abords, Benstock pourrait attribuer cette complexité au développement logiciel moderne, mais une lecture plus raffinée dévoile un autre facteur plus important que celui cité précédemment : « La complexité grandissante dans la maîtrise et la manipulation des outils nécessaires au développement logiciel »

A titre d’exemple, un simple projet de développement d’application mobile nécessite plusieurs outils de nos jours, allant de l’outil de gestion de versions (VCS ou SCM) aux outils dédiés à la traque de bugs en passant par l’IDE, les outils de tests spécifiques à chaque plateforme ou encore ceux utilisés pour vérifier la conformité et l’éligibilité de l’application sur les différents stores mobiles.

Ces différents outils cités précédemment ont beaucoup évolué au fil de la dernière décennie, afin d’atteindre l’apogée « du passage à l’échelle, de l’évolutivité, de la compréhension ou encore de la performance, bref tout sauf la simplicité ».

Il n’est donc pas rare de voir certains outils se doter de leur propre API, ou de leur propre langage qu’il faut apprendre et maîtriser. Un autre exemple fort intéressant serait le cas du VCS Git, ce dernier est un outil très puissant largement utilisé de nos jours et connu pour ses différentes qualités, toutefois « Le problème avec Git, c’est qu’il représente tout un monde à lui seul », sa prise en main initiale peut se faire avec un simple tutoriel, mais si le développeur souhaite utiliser certaines opérations, une compréhension approfondie du VCS est nécessaire, ce qui comporte un surcoût important.

Ainsi, l’expertise du développeur ou encore la direction entreprise importe peu, « la complexité tend à être une réalité insistante prête à emmener le développeur loin de l’activité de base : le codage ».

Alors, que faut-il faire pour y remédier ? Faut-il s’accommoder de cette nouvelle tendance ? Y a-t-il des solutions pour contourner cette situation ? Nul doute que des réponses existent, reste à connaitre si elles sont de réelles solutions, ce qui nous amène au point suivant : ce qui ne devait être qu’un simple constant débouche sur une foule de questions aux réponses incertaines.

Source : Billet d’Andrew Binstock

Et vous ?
Qu’en pensez-vous ?

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

Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 01/08/2014 à 13:40
Citation Envoyé par deusyss Voir le message
Sinon, je suis assez d'accord avec le fond de l'article. On nous met tellement de softs dans les roues pour avoir indicateurs, rentabilité, performance, ... qu'au final cela nous plombe plus qu'autre chose. On passe plus de temps à renseigner les logiciels qu'à vraiment coder.
Disons qu'il y a de bonnes et de mauvaises choses qui nous empêchent de coder. On ira difficilement se plaindre du contrôle des sources !

En revanche il y a nombre de pratiques de nature administrative qui pourraient être souvent supprimées : documentation systématisée du code (la doc XML c'est le mal), tests systématisés et extensifs de chaque parcelle du code, tickets systématiques, certains outils d'analyse de code avec 90% de faux positifs et 10% de mouaisbof, refactorings idiots et contre-productifs guidés par une lecture aveugle d'indicateurs de qualité, hooks de dépôt contrôlant l'agencement des interlignes et autres guidelines d'écriture ultra-rigides, etc. Il y a des équipes dans lesquelles 50% de la charge de travail pourrait être virée et, surtout, ce temps mieux utilisé.

Comme partout certains sont obsédés par ces bonnes pratiques (ou soi-disant bonnes pratiques pour certaines) et deviennent des zélotes, jurant leurs grands dieux contre tous les faits que la qualité du projet en est ainsi améliorée (et quand ce n'est pas le cas c'est qu'il faut pousser plus loin). C'est le pouvoir sacré et mystérieux des dashboards, capables de transformer l'individu le plus rationnel qui soit en abruti courant après des loupiotes vertes.
7  0 
Avatar de rawsrc
Expert éminent sénior https://www.developpez.com
Le 09/08/2014 à 11:52
Citation Envoyé par jgconseilrh Voir le message
Du côté des ingénieurs ou diplômés en informatique, c'est la capacité d'abstraction, d'intégration
et de gestion de la complexité qui fera la différence ...à mon avis, un juste retour au métier d'ingénieur
Ouais des comme j'en ai vu pleins. Des mecs en béton sur les mathématiques et autres jolies théories mais infoutus de coder ne serait-ce que leurs propres idées.
Le pompon, c'est une réunion technique (sur un problème informatique) à laquelle j'ai assistée : des X, des centraliens et leur délire c'était à celui qui pondrait le concept le plus abstrait en espérant larguer leurs petits camarades. Des dingues !
Aucun sens des réalités. Ça c'est terminé sans solution pratique. C'est un prestataire externe qui a apporté la soluce.

Conception et codage vont de pair, sinon ça n'a aucune utilité et dans les deux sens :
- concevoir sans être apte à appréhender la difficulté de mise en oeuvre au codage
- coder sans être apte à concevoir une architecture minimaliste (vision d'ensemble)

Les deux voies mènent directement dans le mur.
6  1 
Avatar de rawsrc
Expert éminent sénior https://www.developpez.com
Le 13/08/2014 à 19:04
Cette organisation bien séparée est tout à fait possible mais la contrepartie c'est d'avoir une communication en béton entre les différents niveaux.
Et accessoirement les niveaux supérieurs doivent obligatoirement savoir de quoi ils parlent tant du point de vue théorique que pratique (denrée de plus en plus rare...), sinon c'est direct le règne du yapuka, fauquon et consorts...

Il est plus simple de mon point de vue d'avoir un système où les différents intervenants soient ouverts sur plusieurs strates que de les cloisonner trop et d'en faire des ermites.
Dans nos métiers de l'informatique, outre la compétence, c'est la communication qui vient en deuxième position et c'est bien elle qui fait le plus souvent défaut à tous les niveaux (manager, développeur) (client, prestataire) (commerciaux, managers)...

On aura beau pondre ou suivre toutes les organisations possibles, sans une bonne maîtrise du facteur humain, point de salut à long terme et vous vous retrouvez un jour prestataire sur des missions où votre seule tâche consiste à intégrer une "super" équipe qui vous a mis de côté (rien que pour vous) tout ce que ses membres n'ont pas voulu faire pour des tas de "bonnes" raisons.

La principale raison des projets qui capotent, c'est du côté de la comm entre intervenants qu'il faut chercher. A un moment ou un autre, un ou plusieurs participants n'ont pas pu vider leur sac, soumettre le fond de leur pensée et du coup les décisions n'ont pas été prises en "toute connaissance de cause". Ça devient vite un jeu de hasard...
5  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 01/08/2014 à 13:53
Dans cette réflexion, je me permet de rappeler les 4 valeurs de l'Agilité:

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
=> Voir http://agilemanifesto.org/iso/fr/

Je m'étendrais dans notre cas sur la première valeur.
L'important, ce n'est pas le outil que l'on utilise pour faire notre métier, mais le but et le besoin que l'on en a.

Par exemple, dans le cas d'un outil "bug tracking", l'important n'est pas forcement d'avoir de jolie liste de "bugs" qu'un manageur pourra extraire et classer dans un jolie rapport mensuel.
L'important c'est de répondre à un besoin d'un client ou d'un utilisateur qui nous remonte un défaut ou un nouveau besoin.
Bien prendre en compte cette remarque et la mémoriser.
Autant que faire ce peu, faire en sorte qu'un développeur fasse évoluer le code en conséquence.
Et bien sur, valider la modification.

On peux pour cela utiliser un bug-tracking avec un workflow bien détaillé
On peux aussi noter le problème sur un post-it ou un tableau blanc à la vu de tous avec le titre "à corriger".

Les processus et outils utilisés sont différents, mais le but premier est le même: améliorer la qualité de notre logiciel dans l’intérêt du client.
Le choix d'un tel ou tel, dépendra de la taille du projet et de sa criticité.

Là ou je rejoints la remarque de cette article, c'est que l'on a tendance, dans nos entreprises, à utiliser des outils ou d'appliquer des processus d'organisation en oubliant nos objectifs initiaux: développer des logiciels de qualités.
4  0 
Avatar de Jay13mhsc
Membre du Club https://www.developpez.com
Le 08/08/2014 à 17:39
lorsque son application répond parfaitement aux cahiers de charge et aux souhaits du client.
Depuis quand une application qui répond parfaitement au cahier des charges (pluriel à l'envers) réponds aussi aux souhaits du client ?
Depuis quand une application qui répond aux souhaits du client est utile ?
(OK, je trolle un peu :p, mais Henry Ford a dit : "si j'avais demandé ce que souhaitaient les gens, ils m'auraient répondu des chevaux plus rapides"

Sinon, non, ça me parait logique.
Le métier de développeur ne consiste pas à s'asseoir, pisser du code, et se barrer.
Son objectif est justement de transformer une idée en incrément logiciel, codé proprement, et (pléonasme) qui marche en prod.
Donc oui, il faut maitriser plein de techniques et d'outils, et oui c'est difficile.
Mais c'est notre TAF, et c'est la vraie vie.
5  1 
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 01/08/2014 à 8:46
Ça c'est le problème de tous ces logiciels sensés nous "simplifier la vie".

Généralement, cela ce passe comme ça :
1. il existe un problème récurrent
2. pour palier à ce problème (ou une partie de ce problème), on invente un outil (ou ensemble d'outils appelés "framework"
3. des gens utilisent cet outil car il répond à leur besoin
4. d'autres gens utilisent cet outil parce qu'ils croient que c'est la panacée
5. l'outil en question amène des problèmes nouveaux (parfois plus durs à résoudre que le problème original...)
6. maintenant il faut à tout prix que les dévelopeurs soient "experts" dans l'outil sensé simplifier la vie

Et encore, ça c'est rien (on demande à un dévelopeur d'utiliser des outils spécifiques à un problème ou un environment, c'est toujours mieux que de réinventer la roue... ).

Le pire, c'est quand on demande à un développeur d'accomplir des tâches qui n'ont absolument rien à voir avec son métier. L'auteur prend comme exemple la publication d'applis sur un store (et toute la partie administrative associée) mais il y a bien pire : par exemple quand on demande au développeur de jouer les commerciaux auprès d'un client potentiel (mais avec en plus tout un tas de formulaires à la con à remplir, sinon ça serait pas drôle... ). Parfois c'est tellement lourdingue que ça en deviendrait presque comique...
4  1 
Avatar de spidetra
Membre confirmé https://www.developpez.com
Le 01/08/2014 à 13:42
Son premier billet est excessif.
Le second billet (Getting Back to Code) nuance le propos.
Ce qu'il remet en cause, ce n'est pas tant les outils eux-mêmes, que leurs tendance naturelle à l'obésité.
Nous avons surement tous en tête un outil que nous apprécions et qui au fil du temps devient une véritable "usine à gaz".
3  0 
Avatar de landry161
Membre éprouvé https://www.developpez.com
Le 18/08/2014 à 22:44
Citation Envoyé par Jay13mhsc Voir le message
Depuis quand une application qui répond parfaitement au cahier des charges (pluriel à l'envers) réponds aussi aux souhaits du client ?
Depuis quand une application qui répond aux souhaits du client est utile ?
(OK, je trolle un peu :p, mais Henry Ford a dit : "si j'avais demandé ce que souhaitaient les gens, ils m'auraient répondu des chevaux plus rapides"

Sinon, non, ça me parait logique.
Le métier de développeur ne consiste pas à s'asseoir, pisser du code, et se barrer.
Son objectif est justement de transformer une idée en incrément logiciel, codé proprement, et (pléonasme) qui marche en prod.
Donc oui, il faut maitriser plein de techniques et d'outils, et oui c'est difficile.
Mais c'est notre TAF, et c'est la vraie vie.
Cette vie je l'aime énormement
3  0 
Avatar de benjani13
Membre extrêmement actif https://www.developpez.com
Le 01/08/2014 à 0:37
Coder est l’activité la plus satisfaisante pour le développeur, car elle lui permet d’exercer sa créativité et son génie, elle permet aussi de lui donner ce sentiment de joie, de satisfaction et d’achèvement si chers à lui, lorsque son application répond parfaitement aux cahiers de charge et à aux souhaits du client.
Je ne suis pas sur que le développeur qui ne fait qu'attendre un cahier des charges, le respecte mot pour mot sans rien dire, et passe au cahier des charges suivants soit très épanouie. Personnellement c'est ce que je fait, et j'aimerais pouvoir avoir un peu plus de poids dans la rédaction du cahier des charges (ou du moins dans son interprétation), pouvoir discuter de la façon dont la fonctionnalité voulu sera implémenté (UI, choix donnés à l’utilisateur, etc). Quand tu fais, parfois, des choses que tu semble pas forcément pertinent pour l'utilisateur (par ce qu'on chef t'a dit de faire ça et pas autre chose), je ne pense pas que ce soit très épanouissant.
De plus, tout dépend de ce que tu code. Quand tu es le petit nouveau à qui on dit "tel équipe à codé de supers algos, tu peux mettre tout ça bout à bout avec une jolie UI?", ce n'est pas très motivant je vous le promet.

A titre d’exemple, un simple projet de développement d’application mobile nécessite plusieurs outils de nos jours, allant de l’outil de gestion de versions (VCS ou SCM) aux outils dédiés à la traque de bugs en passant par l’IDE, les outils de tests spécifiques à chaque plateforme ou encore ceux utilisés pour vérifier la conformité et l’éligibilité de l’application sur les différents stores mobiles.
Je n'ai pas bien compris si c'était une critique ou non. Si c'est le cas, je ne comprend pas pourquoi.

Il n’est donc pas rare de voir certains outils se doter de leur propre API, ou de leur propre langage qu’il faut apprendre et maitriser.
Et le jour ou tu change de boites tu dois prendre en main de nouveaux outils, de nouveau langage, une nouvelle plateforme, de nouveaux framework. C'est le propre du développeur de s'adapter et d'apprendre de nouvelle technos non? Dans ma boite on m'a dit que la monté en compétence prend 2 ans (le temps de prendre en main la plateforme de dev, les framework, etc).

Je finis par une citation de l'article original:
For a long time, I've attributed this frustration to the complexity of today's software. The simple programs of a few hundred lines of C++ long ago disappeared from my experience.
Je pense que cette personne est restée bloquée avec l'image du développeur des années 70/80.
5  3 
Avatar de deusyss
Expert éminent https://www.developpez.com
Le 01/08/2014 à 7:39
Citation Envoyé par benjani13 Voir le message
Je pense que cette personne est restée bloquée avec l'image du développeur des années 70/80.
+1 . Ou alors il se contente de coder des calculatrices .

Sinon, je suis assez d'accord avec le fond de l'article. On nous met tellement de softs dans les roues pour avoir indicateurs, rentabilité, performance, ... qu'au final cela nous plombe plus qu'autre chose. On passe plus de temps à renseigner les logiciels qu'à vraiment coder.

Cela me rappelle un ancien travail, ou le support n'arretais pas de la journée. Un nouveau chef est arrivé et a sorti "on va mettre en place des outils de tickets, de suivi de demande, de statistique, ..." (ça partait d'une bonne volonté). Sauf, que mauvais choix, et chaque technicien passait 10 mn (oui oui, véridique) à remplir un ticket, meme quand la resolution prenait 30s. Au bout de deux mois le chef est arrivé et à dit qu'il n'y avait pas tant de ticket que ça, qu'on lui avait menti, et la moitié de l'équipe à disparu. Et on parle pas des demandes en attente sur post it...

Bref juste pour confirmer que certains logiciels peuvent effectivement appporter un réel plus (les gestionnaires de versions par exemple, ou certaines fonctionnalité ide tel la completion), mais d'autres sont vraiment superflus et ne font que nous plomber.
2  0