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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Le développeur s'éloignerait de plus en plus de son activité principale : le codage !


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2011
    Messages : 283
    Points : 18 071
    Points
    18 071
    Par défaut Le développeur s'éloignerait de plus en plus de son activité principale : le codage !
    Le développeur s'éloignerait de plus en plus de son activité principale : le codage !
    Voilà le constat amer d'un passionné de programmation

    « 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 ?

  2. #2
    Membre extrêmement actif
    Avatar de benjani13
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    février 2010
    Messages
    615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant en sécurité

    Informations forums :
    Inscription : février 2010
    Messages : 615
    Points : 2 814
    Points
    2 814
    Par défaut
    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.

  3. #3
    Expert éminent

    Avatar de deusyss
    Homme Profil pro
    Expert Python
    Inscrit en
    mars 2010
    Messages
    1 659
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Expert Python
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2010
    Messages : 1 659
    Points : 8 438
    Points
    8 438
    Par défaut
    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.
    "La connaissance appartient à tout le monde" (Film Antitrust)

    Tout le nécessaire pour Python:
    *News/Accueil *Cours/tutoriels *FAQ
    *Forums *Outils dédiés *Mon espace personnel avec mes Articles, Cours et Tutoriels

  4. #4
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    août 2003
    Messages
    6 471
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 6 471
    Points : 18 979
    Points
    18 979
    Par défaut
    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.
    C'est tellement plus cool, de passer sa journée à taper des lignes de code sur une console , sans possibilité de revenir facilement à une version antérieure, sans se rappeler qui s'occupe de tel bug et d'écraser le code de son collègue parce que on à modifié le même code au même moment ...
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 785
    Points : 9 698
    Points
    9 698
    Par défaut
    Ç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...
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  6. #6
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2003
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 298
    Points : 476
    Points
    476

  7. #7
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    février 2013
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2013
    Messages : 88
    Points : 448
    Points
    448
    Billets dans le blog
    1
    Par défaut
    Le titre "Just let me code" et tellement mal choisi ...
    Il aurait du choisir "Just let me do my job".

    Si une équipe a un administrateur système et que les développeurs doivent mettre la main dans le système, c'est une erreur.
    Le rôle de développeur n'est pas de lancer des builds. Si possible, on séparera les parties d'une application en modules qui seront regroupés dans un projet parent, le développeur n'a pas à se charger de ça (sauf si la personne a reçu ce rôle aussi).
    De même le système de versionnement n'est pas géré par le développeur, ce dernier ne fait que des commit sur la branche sur laquelle il travail.
    Un développeur Java ou .NET ne voudra pas nécessairement développer des interfaces en HTML5.

    Après il faut voir la taille de l'équipe. Sur un projet à 2 personnes, et bien désolé pour lui mais il va cumuler 50 rôles et ne codera pas autant qu'il le voudra ou comme il le voudra. Cependant sur un projet à 50+ personnes, si il a le simple rôle de développeur sur des services J2EE et qu'il se charge des builds et déploiement de son module, alors c'est une faute du chef de projet.

  8. #8
    Membre du Club
    Inscrit en
    juin 2012
    Messages
    31
    Détails du profil
    Informations forums :
    Inscription : juin 2012
    Messages : 31
    Points : 65
    Points
    65
    Par défaut
    Je pense que cette personne est restée bloquée avec l'image du développeur des années 70/80.
    +1. Comme quoi même des développeurs, pourtant supposés être un type de personne ouvert aux nouvelles techno, peuvent être conservateurs jusqu'a vouloir régresser.

    Comme si bien dit :
    C'est tellement plus cool, de passer sa journée à taper des lignes de code sur une console , sans possibilité de revenir facilement à une version antérieure, sans se rappeler qui s'occupe de tel bug et d'écraser le code de son collègue parce que on à modifié le même code au même moment ...
    S'il tient tant a être libre de coder comme il en a envie (sans controle de source, ou controles de performances visiblement, probablement du pas très beau), il n'a qu'a lancer son studio... Ah ben non ; il n'a pas envie de le gérer, je présume.

  9. #9
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 311
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 311
    Points : 3 660
    Points
    3 660
    Billets dans le blog
    12
    Par défaut
    Aujourd'hui il faut forcément effectuer un suivi, on ne peut pas se permettre de coder comme on le veut, il faut suivre le cahier de charges (en espérant qu'il y en ait un et qu'il soit bien fait), vérifier la qualité du code, mettre en place des tests de non régression et j'en passe, donc ces outils de gestion de projet sont nécessaires même si cela donne l'impression qu'on prend un billet d'avion pour un trajet qu'on pourrait effectuer en vélo.

    Je propose quelques solutions pour améliorer le processus :
    • Pour chaque catégorie, utiliser un outil : connu, répandu, documenté, à jour. Surtout éviter les frameworks fait maison.
    • Donner des formations sur l'outil : installation, utilisation, compréhension des bugs.
    • Ne pas négliger dans l'implication du projet : les nouveaux développeurs, les séniors, la MOA.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  10. #10
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    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.

  11. #11
    Membre confirmé

    Profil pro
    Inscrit en
    octobre 2003
    Messages
    298
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2003
    Messages : 298
    Points : 476
    Points
    476
    Par défaut
    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".

  12. #12
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 149
    Points
    2 149
    Par défaut
    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.

  13. #13
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    juillet 2010
    Messages
    422
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : C#,PHP,MySQL,Android...

    Informations forums :
    Inscription : juillet 2010
    Messages : 422
    Points : 1 057
    Points
    1 057
    Billets dans le blog
    1
    Par défaut
    Quand t'es informaticien dans une boîte avec un chef de projet qui a fait ses études en ressources humaines ne vous attendez pas à ce qu'on vous fasse les yeux doux.
    Je dis cela parce vous travaillez pour des personnes qui n' en n'ont rien à cirer des contraintes auxquelles vous serez confronté,quand bien même vous aurez a cœur de coder le plus proprement possible.L'essentiel "faut que ça marche" et ils empochent le magot le reste on s'en tape même si c'est une usine à gaz.
    Dommage mais voila le milieu dans lequel nous vivons et ça c'est pas du tout bon

  14. #14
    Membre chevronné
    Avatar de free07
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2005
    Messages
    850
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ardèche (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2005
    Messages : 850
    Points : 1 767
    Points
    1 767
    Par défaut
    Citation Envoyé par landry161 Voir le message
    Quand t'es informaticien dans une boîte avec un chef de projet qui a fait ses études en ressources humaines ne vous attendez pas à ce qu'on vous fasse les yeux doux.
    Je dis cela parce vous travaillez pour des personnes qui n' en n'ont rien à cirer des contraintes auxquelles vous serez confronté,quand bien même vous aurez a cœur de coder le plus proprement possible.L'essentiel "faut que ça marche" et ils empochent le magot le reste on s'en tape même si c'est une usine à gaz.
    Dommage mais voila le milieu dans lequel nous vivons et ça c'est pas du tout bon
    Ce genre d'attitude ne date pas d'aujourd'hui, cela a toujours existé et c'est pour cette raison que je ne pense pas que l'auteur soit resté bloqué avec l'image du dev des années 70/80, même à cette époque les dangers de créer une usine à gaz étaient aussi présent qu'aujourd'hui.

    Il me semble qu'il dénonce surtout la compléxité et la multiplicité de certains outils d'aujourd'hui qui au lieu de simplifier le codage, peut au contraire le rendre plus complexe et plus difficile à maintenir, ce qui peut effectivement amener petit à petit à construire une véritable usine à gaz.

    Sans vouloir dire que c'était mieux avant ( bien au contraire ), trouver et utiliser les bons outils et technos pour certains projets peut s'avérer être un choix difficile à faire de nos jours et au regard de la multiplicité des technos mis à notre disposition.
    Ce choix est devenu trés important, voir même primordial pour certains projets.

  15. #15
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 862
    Points : 31 511
    Points
    31 511
    Billets dans le blog
    4
    Par défaut
    Faut distinguer les vrais problèmes des faux.

    L'utilisation d'un serveur de versionning c'est du tout bon. Tomber dans une équipe de mecs qui jurent que par la ligne de commande pour utiliser Git en est une autre.
    En tant que programmeur, il m'est arrivé d'utiliser Git, et ça m'énervait énormément au début, j'avais vite installé un petit truc pour avoir une GUI et pouvoir faire mes commits. Je suis développeur, pas bidouilleur de Git et mettre 5mn pour faire un commit non merci. A ce niveau j'y préfère nettement Mercurial, mais c'est pas le débat.
    Mais la gestion du serveur Git ne me revient pas, c'est quelqu'un d'autre qui a ces attributions et compétences.

    On dirait qu'il parle du développeur de SSII, en tous cas j'y retrouve des traits, où l'évolution "normale" du développeur c'est chef de projet. Soit bien loin du développement. Et où en plus de tes compétences en développement, on te demandera toujours tout un tas d'extras. Je peux comprendre que ça soit gonflant à la longue.


    Les outils doivent rester ce qu'ils sont : des outils, des aides.
    S'il faut commencer à développer des compétences particulièrement pointues pour les utiliser, ils deviennent finalement des freins.
    Se plaindre du langage/API d'un outil par contre, c'est un peu gros je trouve.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  16. #16
    Membre du Club
    Profil pro
    Inscrit en
    avril 2007
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2007
    Messages : 35
    Points : 62
    Points
    62
    Par défaut
    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.

  17. #17
    Membre chevronné

    Homme Profil pro
    Mentaliste
    Inscrit en
    mars 2008
    Messages
    872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Mentaliste
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2008
    Messages : 872
    Points : 1 802
    Points
    1 802
    Par défaut
    Citation Envoyé par spidetra Voir le message
    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".
    A ma connaissance, il n'y a que vim que tu peux transformer en véritable studio sans qu'il devienne une usine à gaz.

    Citation Envoyé par landry161 Voir le message
    .. des personnes qui n' en n'ont rien à cirer des contraintes auxquelles vous serez confronté, quand bien même vous aurez a cœur de coder le plus proprement possible.L'essentiel "faut que ça marche" et ils empochent le magot le reste on s'en tape même si c'est une usine à gaz...
    Voici ce qu'il y a marqué sur les murs de Facebook : "Done is better than perfect"... Véridique, cherchez sur google.
    Autrement dit "tant que ça marche et qu'on se fait des thunes sur votre dos, on s'en fout de comment vous le faites".
    Imaginez une petite étoile juste après avec l'alinéa en bas de page : "en plus si vous êtes débutant ça tombe bien : on pourra vous exploiter encore plus pour beaucoup moins cher".

    Bienvenue dans le monde réel.
    .I..

  18. #18
    Candidat au Club
    Homme Profil pro
    Ressources humaines
    Inscrit en
    février 2014
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ressources humaines
    Secteur : Conseil

    Informations forums :
    Inscription : février 2014
    Messages : 2
    Points : 3
    Points
    3
    Par défaut Une opportunité pour les jeunes BTS en informatique...
    En tant que coach de carrière informatique et recruteur de profils ingénieurs en informatique, je crois pouvoir
    annoncer une évolution rapide dans le recrutement des informaticiens développeurs.
    Celle-ci sera favorable aux diplômés BTS spécialisés en développement (codage) car les
    RH des entreprises constatent elles aussi le phénomène décrit dans cette juste chronique.
    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
    (INSA par exemple). Jacques GUYAMIER JG CONSEIL RH www.jgconseilrh.frhttp://www.jgconseilrh.fr

  19. #19
    Expert éminent sénior
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    mars 2004
    Messages
    6 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : mars 2004
    Messages : 6 142
    Points : 16 475
    Points
    16 475
    Billets dans le blog
    12
    Par défaut
    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.

  20. #20
    Nouveau membre du Club
    Homme Profil pro
    Inscrit en
    janvier 2013
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Secteur : Transports

    Informations forums :
    Inscription : janvier 2013
    Messages : 18
    Points : 38
    Points
    38
    Par défaut
    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
    Je plussoie totalement, c'est exactement ça !!!!!

    Pour faire des choses simples on nous demande d'utiliser des outils et frameworks tous plus complexes les uns que les autres.
    Au final les délais et coûts explosent, le code devient imbitable (pour les nouveaux arrivants sur le projet) et les performances de l'application produite ne sont pas au rendez-vous.

    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)
    +1 ça fait plaisir à lire.

Discussions similaires

  1. Windows Azure : plus simple, plus flexible, plus ouvert
    Par Gordon Fowler dans le forum Microsoft Azure
    Réponses: 2
    Dernier message: 08/06/2012, 22h44
  2. Réponses: 2
    Dernier message: 01/07/2011, 15h18
  3. Windows Phone 7 de plus en plus populaire auprès des développeurs
    Par Hinault Romaric dans le forum Actualités
    Réponses: 7
    Dernier message: 25/02/2011, 18h08
  4. Réponses: 7
    Dernier message: 26/01/2011, 12h46
  5. Réponses: 13
    Dernier message: 18/12/2009, 16h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo