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 !

Devrions-nous écrire moins de code et plus de blogs ?
Selon plusieurs développeurs, le code n'est pas notre principale fonction

Le , par Amine Horseman

10PARTAGES

2  0 
Laura Klein, auteur du livre UX for Lean Startups avait écrit une lettre sur Medium destinée « aux Ingénieurs qui ne se soucient pas réellement de leurs clients » dans laquelle elle explique son point de vue concernant l'écriture du code dans le métier de développeur.

« Je sais, vous pensez que vous avez été embauché pour écrire du code. En fait, votre entretien d'embauche entier était centré autour de la façon dont vous pourriez écrire du code, et je suis sûr que vous le faites très bien. Mais ce n'est pas votre travail ». Elle rappelle ensuite que les clients ne sont pas tous équipés des derniers MacBook Air avec un écran haute résolution. « Beaucoup d'entre eux ont une version d'Internet Explorer vielle de quatre ans sur d'anciens PC, donc parfois, les choses que vous construisez ne fonctionnent pas bien sur leurs machines [...] alors s'il vous plaît assurez-vous que le code que vous avez écrit s'exécute dans un nombre raisonnable d'environnements ». Pour cela, elle déclare qu'il est nécessaire de tester son code en production et non pas seulement en local. Aussi, ce code devrait couvrir tous les scénarios d'utilisation possibles même en cas d'erreur et d'absence de données, ou lorsque par exemple « le client utilise le bouton retour ou crée deux comptes par erreur ».

Un autre point important selon elle est le fait de pouvoir mesurer la qualité du travail effectué, « si vous vous attendez que le code écrit va améliorer l'engagement des utilisateurs, alors vous devez avoir un moyen de savoir si vous avez réussi ou non ». Et elle conclut en précisant que ceci s'applique aussi aux Designers, aux Managers et même au directeur de l'entreprise puisqu'ils ont tous un point commun : améliorer le produit pour les clients.

Toutefois, Mike Grouchy aborde le sujet de l'écriture du code sous un autre angle. En effet, pour ce blogueur et contributeur à pycoders : un développeur doit écrire le moins de code possible. « Regardez vos outils et vos environnements, tous essaient de vous faire écrire moins de code », avait-il déclaré dans un billet de blog sur Medium. « Votre travail est de penser, il consiste à réfléchir sur le problème à portée de main, concevoir une solution élégante et puis convertir cette solution en logiciel », déclare Mike, avant de rappeler que l’écriture du code n’est qu’une des nombreuses étapes de la création de logiciels.

Aussi, un autre blogueur sur Medium avait écrit en décembre dernier que les ingénieurs en informatique devraient écrire plus souvent, non pas du code, mais plutôt écrire des blogs et des essais. Il attire notre attention sur les similitudes qui existent entre ces deux disciplines : les deux commencent avec une idée et une page vierge, on remplit cette page au fur et à mesure tout en suivant une certaine structure, on revient ensuite sur telle ou telle partie pour la modifier ou la corriger, jusqu'à ce qu'on obtienne un produit final destiné à un public bien ciblé. « Ce produit est une séquence d'instructions logiques groupées en unités modulaires, que ce soit des fonctions ou des paragraphes ». Aussi, il rappelle qu'un bon texte comme un bon programme doit être clair et concis.

« Les ingénieurs logiciels doivent écrire parce que notre métier est devenu de plus en plus collaboratif. Les projets open source invitent à une participation mondiale, tandis que les produits de l'industrie exigent souvent une armée d'ingénieurs. Bien écrire, que ce soit dans un commentaire GitHub, une révision de code, ou dans la documentation technique, facilite la communication dans les projets, et permettent d'aller de l'avant ». Il explique aussi que même dans les projets qui ne nécessitent pas de communication cela reste important en citant à titre d'exemple l'écriture de blogs, de tutoriels et de livres sur l'informatique qui sont plus faciles à aborder pour les débutants que la documentation technique.

Source : Article de Laura Klein, Article de Mike Grouchy, Article de Shubhro Saha

Et vous ?

Partagez-vous les avis de ces blogueurs ?

Pensez-vous que les développeurs devraient écrire moins de code et plus de blogs/essais/livres ?

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

Avatar de Jarodd
Membre expérimenté https://www.developpez.com
Le 30/01/2015 à 19:11
Pour cela, elle déclare qu'il est nécessaire de tester son code en production et non pas seulement en local.
Tester en production, non mais sérieusement

« s'il vous plaît assurez-vous que le code que vous avez écrit s'exécute dans un nombre raisonnable d'environnements »
Tester sur plusieurs environnements, ça c'est une idée de génie. Merci Captain Obvious, personne n'y avait encore pensé !

« Beaucoup d'entre eux ont une version d'Internet Explorer vielle de quatre ans sur d'anciens PC, donc parfois, les choses que vous construisez ne fonctionnent pas bien sur leurs machines [...] alors s'il vous plaît assurez-vous que le code que vous avez écrit s'exécute dans un nombre raisonnable d'environnements »
Merci pour cette nouvelle vérité. Mais apparemment nous n'avons pas les mêmes clients. Pourquoi j'irai me casser le fondement à assurer une compatibilité IE7 si le client n'en veut pas ? C'est quoi ce conseil moisi, il y aurait donc une seule règle pour les gouverner tous ?

« Votre travail est de penser, il consiste à réfléchir sur le problème à portée de main, concevoir une solution élégante et puis convertir cette solution en logiciel »
Oui, donc au final il faut quand même écrire du code...

Cette personne travaille chez Lapeyre pour enfoncer autant de portes ouvertes ?

Allez, next
12  2 
Avatar de
https://www.developpez.com
Le 30/01/2015 à 19:30
Des portes ouvertes surement, malheureusement dans les faits les codes non testés correctement et passés en production sont encore légions
6  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 30/01/2015 à 18:56
A en juger par les citations de cette Laura Klein, je lui décernerais volontiers la palme de l'enfonçage de portes ouvertes...
5  1 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 02/02/2015 à 17:25
Citation Envoyé par Zirak Voir le message
(.../...)
La plupart des devs (malgré le cliché du ronchon qui code tout seul dans son garage), aimeraient bien être plus proche des utilisateurs métiers et essayer de coller au plus proche de leurs besoins, c'est bien pour cela, (enfin c'est mon impression), qu'avant on était "analyste" - programmeur / développeur, alors que maintenant, on a des devs + AMOA + MOE + etc etc, le même boulot s'étant dilué en plusieurs pour des soucis "d'efficacité" et de "rentabilité" (et de devoir justifier le salaire de certains ).(.../...)
Je vais partir de là et m'éloigner du sujet, mais difficile de ne pas te donner raison.

Une des racines de ce problème, je crois, c'est le manque de formation industrielle des managers. J'ai un diplôme d'ingénieur, un vrai, je suis formé pour concevoir des moules de tableau de bord de voiture, pas pour concevoir des tests automatiques de logiciels médicaux. Pendant ma formation, on m'a matraqué avec "le fordisme, c'est obsolète, c'est de la merde, fuyez-le". C'était il y a 20 ans, et ça doit toujours être comme ça(enfin j'espère).

Pourtant, le mythe de la division du travail persiste de manière majeure parmi nos managers. Parce qu'au final, ils n'ont pas eu ma cure de désensibilisation au fordisme et au taylorisme. Le vieux Ford lui-même disait qu'il n'avait poussé la division du travail à l'absurde que parce qu'il avait 50 langues dans l'atelier et un turnover annuel de 480%. Dans toute situation plus stable, cela aurait été aberrant à ses yeux. Mais lui, il avait besoin d'un travailleur opérationnel en 1 heure parce qu'il n'allait pas rester longtemps. Nos livres d'histoire sont à ce titre trompeurs. Ils présentent comme ultime ce qui n'a été qu'un accident de l'histoire. Et nos managers baignent dans cette culture erronée. Et donc, dans leur esprit, découper le travail, c'est bieeeeeeeeeeeeeeeennnnnn.

C'est d'autant mieux dans leur esprit que ça facilite le WBS, panacée du management de projet tel qu'il est enseigné de nos jours. Qui est un outil d'ailleurs utile, mais qui ne devrait pas être l'alpha et l'oméga du management comme il l'est souvent. Donc, plutôt que de comprendre le boulot de leur subordonnés(tâche difficile, et don ont leur à appris qu'elle était difficile), ils préfèrent(et après leur lavage de cerveau façon MBA, c'est inévitable) de découper le travail en cases ridiculement petites, pour être surs de tout maitriser.

Ce qu'on ne leur a pas appris, c'est que le développement informatique, c'est une tâche fluide, avec d'innombrables dépendances invisibles, avec une exigence forte de savoir-faire, et un poids de la communication très fort. Si un découpage minimal en WBS est généralement utile(toi tu fais la prescription, toi tu fais les urgences, toi tu fais le bloc, et toi tu testes), quand on pousse trop loin la logique, ça devient vite n'importe quoi. Les doctrines industrielles modernes poussent à donner plus de pouvoir aux ouvriers(des gens qui ont parfois bac-2 mais qui connaissent leur boulot) et font la fortune de groupes comme Mercedes. Le gars chargé de monter les rétroviseurs peut proposer toute amélioration concernant son poste, et les ingénieurs, généralement, suivent(ils veulent leur prime, eux aussi). C'est ça, l'industrie moderne.

Et, en informatique grands comptes, le bac+5 recruté assez cher a moins de pouvoir que le gars qui monte les rétroviseurs chez Mercedes. Il est considéré comme un bête manœuvre du XIXème siècle, un ignare analphabète qui doit être opérationnel en 1 heure, et donc on va le cantonner à un rôle ridicule. J'ai vu un client(qui m'a jeté, Dieu merci), qui avait :
_un intervenant qui écrivait l'expression de besoins.
_un autre qui faisait le cahier des charges.
_un autre qui se fadait les specs fonctionnelles générales.
_un autre qui pondait les specs fonctionnelles détaillées.
_un expert technique(poste pour lequel ma SSII me positionnait) qui se farcissait les specs techniques générales, et faisait le suivi du prestataire, et les tests.
_un prestataire hors-site qui imaginait les specs techniques détaillées.
_un autre prestataire hors-site qui codait
_et derrière, je ne sais même pas.

donc, pas loin d'une dizaine d'intervenants. C'est évidemment une catastrophe - toutes les infos sont perdues en permanence, et personne ne comprend ce qu'il faut faire. Mais c'est logique - le management a appris que son métier était la science du contrôle. Et découper les équipes, ça permet d'empêcher ces connards de grouillots de prendre des initiatives non approuvées.
4  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 02/02/2015 à 10:41
Pour cela, elle déclare qu'il est nécessaire de tester son code en production et non pas seulement en local.
Moi, je comprend cette phrase plutôt dans l'idée de tester dans des environnements similaire à nos utilisateurs finaux (pas réellement en production).
Les machines développeurs ne sont pas des environnement réalises.

J'encourage aussi les développeurs à faire des visites chez leurs utilisateurs pour voir comment ils utilisent l'outil.
J'ai eu à le faire 2 fois dans un contexte d'un logiciel de pilotage d'instrument d'analyse pour l'industrie:
  1. Dans un labo d'une raffinerie, les PCs étaient coincés entre 2 appareils d'analyse sur des grandes paillasses de chimie avec à peine la place pour le clavier et la souris, les opérateurs utilisant le logiciel debout.
    J'ai alors compris qu'il fallait une interface très simple, privilégier les boutons de raccourcis type F1 ... F12 et d'avoir une interface graphique qui tiens sur du 15 pouces (800x600)
  2. Dans un labo de contrôle de production, le client nous laissait le serveur 2h pour: faire les sauvegardes, appliquer la mise à jours, tester la nouvelle version et revenir en arrière si cela n'était pas satisfaisant. Chaque heure d’interruption du labo coûtait plusieurs milliers d'euro au client.
    Dans ce cas, les procédures de mise en production et de validation doivent être hyper soignées, on n'a pas le temps et le droit d'hésiter dans cette situation.

Donc, en effet, les développeurs ne sont pas fait pour coder bêtement mais pour participer au développement d'un produit logiciel dont des utilisateurs ont des besoins et des contraintes parfois critiques.
Il est très important que l'on fasse évoluer nos métiers vers plus de "pourquoi" que du "comment" on réalise nos produits informatiques.

Pour cela, il faut être à l'écoute de nos utilisateurs.
L'utilisation d'un blog est une idée à creuser.
Mais dans d'autre cas, il faudra plutôt mettre en place des rencontres physiques entre utilisateurs et développeurs.
Soyons ingénieux pour imaginer comment répondre à cette mutation de nos métiers.
3  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 02/02/2015 à 14:25
Ces billets de blog n'ont rien à voir entre eux.

  • Le premier, c'est de la provoc' ("Your job is not to write code"... aussi crédible que dire à un boulanger que son métier n'est pas de faire du pain) pour attirer l'attention sur des aspects souvent délaissés du cycle de réalisation d'une application, comme tester aux limites, déployer et tester sur plusieurs environnements/configurations, etc.

  • Le but du deuxième est de distinguer qualité et quantité, réflexion et pissage de code, il dit lui-même que ce n'est pas tout à fait vrai qu'il faut écrire moins de code :


When I said earlier that your job was to write less code, I was fibbing a little bit. Really your job is to think
  • Le 3ème ne dit absolument rien sur la quantité de code à taper, il fait un parallèle entre l'écriture "littéraire" et le développement. Il préconise d'écrire plus de billets de blog, de documentation, etc. ce qui va affûter nos compétences rédactionnelles et notre capacité à organiser un écrit, ce qui est aussi utile pour programmer.


Je pense personnellement qu'il faudrait écrire non pas moins mais plus de code, peut-être pas dans un même projet mais de manière générale. C'est en s'entraînant qu'on s'améliore, donc tout ce qui est projet perso/open source, hackathon, veille techno sur des langages, etc. est bénéfique. Je me méfie aussi des gros frameworks "all inclusive" qui certes permettent d'écrire moins de lignes de code mais nous assistent et nous prennent par la main jusqu'à parfois nous faire totalement oublier qu'il y a mille façons de résoudre un problème en programmation, ce qui fait perdre sur le long terme une certaine autonomie et une capacité d'adaptation.
2  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 02/02/2015 à 16:10
Mouais...

  • Write less code --> Keep it short and simple. Rien de neuf.
  • Ecrire en plus de faire du code, car cela requiert les mêmes compétences : ce n'est pas parce qu'on a les compétences pour écrire qu'on a quelque chose à dire. Si je parlais de mon boulot, je pense que mon employeur, qui ne met pas son code en open-source, ne serait pas content. Et si c'est pour ouvrir un blog sur les chats, autant ne pas le faire.
  • Your job is not to write code --> il est vrai que le boulot doit être avant tout d'améliorer le logiciel dans le sens du client, comme elle le dit, mais le reste n'est que lapalissades


Pour moi, ces trois personnes s'adressent avant tout à des gens qui écrivent du code, mais qui n'ont pas une réelle formation de développeurs, c'est à dire des gens à qui il manque forcément des bases ; et dans ce contexte, alors oui, il peut être utile de rappeler certaines bases.
2  0 
Avatar de Zirak
Inactif https://www.developpez.com
Le 02/02/2015 à 16:25
Citation Envoyé par Laurent 1973 Voir le message
Moi, je comprend cette phrase plutôt dans l'idée de tester dans des environnements similaire à nos utilisateurs finaux (pas réellement en production).
Les machines développeurs ne sont pas des environnement réalises.

J'encourage aussi les développeurs à faire des visites chez leurs utilisateurs pour voir comment ils utilisent l'outil.
J'ai eu à le faire 2 fois dans un contexte d'un logiciel de pilotage d'instrument d'analyse pour l'industrie:
  1. Dans un labo d'une raffinerie, les PCs étaient coincés entre 2 appareils d'analyse sur des grandes paillasses de chimie avec à peine la place pour le clavier et la souris, les opérateurs utilisant le logiciel debout.
    J'ai alors compris qu'il fallait une interface très simple, privilégier les boutons de raccourcis type F1 ... F12 et d'avoir une interface graphique qui tiens sur du 15 pouces (800x600)
  2. Dans un labo de contrôle de production, le client nous laissait le serveur 2h pour: faire les sauvegardes, appliquer la mise à jours, tester la nouvelle version et revenir en arrière si cela n'était pas satisfaisant. Chaque heure d’interruption du labo coûtait plusieurs milliers d'euro au client.
    Dans ce cas, les procédures de mise en production et de validation doivent être hyper soignées, on n'a pas le temps et le droit d'hésiter dans cette situation.

Donc, en effet, les développeurs ne sont pas fait pour coder bêtement mais pour participer au développement d'un produit logiciel dont des utilisateurs ont des besoins et des contraintes parfois critiques.
Il est très important que l'on fasse évoluer nos métiers vers plus de "pourquoi" que du "comment" on réalise nos produits informatiques.

Pour cela, il faut être à l'écoute de nos utilisateurs.
L'utilisation d'un blog est une idée à creuser.
Mais dans d'autre cas, il faudra plutôt mettre en place des rencontres physiques entre utilisateurs et développeurs.
Soyons ingénieux pour imaginer comment répondre à cette mutation de nos métiers.

Je suis d'accord avec ça, bien qu'il ne faut pas oublier également, que suivant la structure de la société, le développeur n'est pas forcément en contact avec l'utilisateur / le client et qu'il ne fait que suivre des spécifs / un cahier des charges.

La plupart des devs (malgré le cliché du ronchon qui code tout seul dans son garage), aimeraient bien être plus proche des utilisateurs métiers et essayer de coller au plus proche de leurs besoins, c'est bien pour cela, (enfin c'est mon impression), qu'avant on était "analyste" - programmeur / développeur, alors que maintenant, on a des devs + AMOA + MOE + etc etc, le même boulot s'étant dilué en plusieurs pour des soucis "d'efficacité" et de "rentabilité" (et de devoir justifier le salaire de certains ).

Quant à la tenu d'un blog, pour des développements perso, pourquoi pas, après niveau pro, encore faut-il avoir le temps... Quand il y a déjà moins de jours vendus au client que de jours nécessaires à la réalisation du projet, on a pas le temps d'aller écrire des pavés sur le web pour expliquer le pourquoi du comment, à peine le projet est-il fini qu'il faut enchainer sur le suivant...
2  0 
Avatar de Galdon
Membre du Club https://www.developpez.com
Le 02/02/2015 à 17:49
Je n'ai réussi à lire au premier degré que les deux premières phrases. C'est magique, Laura Klein défonce les portes ouvertes avec autant de classe qu'un quarterback dopé aux stéroïdes le soir de la finale du superbowl au Michigan Stadium !
2  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 02/02/2015 à 23:09
Des codeurs devraient écrire plus de blogs, et des blogueurs devraient écrire plus de code... c'est l'équilibre entre théorie et pratique. Pour ma part je compte faire les deux
2  0