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

Actualités Discussion :

L'informaticien, artisan des temps modernes ?

  1. #21
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    Novembre 2004
    Messages
    1 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 224
    Points : 2 373
    Points
    2 373
    Par défaut
    La dessus je te retourne l'argument, c'est bien de travailler sur le terrain (c'est ce que j'ai fait et que je continues à faire) mais si tu ne peux pas prendre du recul pour réfléchir au process c'est dommage ^^

    En l'occurrence réfléchir au process c'est aussi analyser pourquoi on fait quelque chose et comment on pourrait éventuellement s'améliorer.

    Ensuite je reviens sur un point

    si tu essaies de démontrer sur chaque exemple pourquoi il vaut mieux être industriel qu'artisanal
    Mon propos n'est pas compris je crois, je ne cherche pas à démontrer pourquoi il vaut mieux être l'un que l'autre. Je donne mon avis sur ceux qui pensent faire de l'artisanat dans le monde du logiciel et je rappelle d'où viennent les méthodes que l'on utilise.

    D'ailleurs le but de ce post c'est de voir ce que d'autres en pensent et non d'imposer mon point de vue (par contre je vais quand même le défendre un peu ^^). Et je constate que beaucoup ont cette vision d'après les posts que je lis.

    Pour info sur mon background et pour éviter de penser que je ne fais que de la théorie. J'ai bossé en C, C++, Java, Php etc... Et aujourd'hui je m'intéresse plus en profondeur aux pratiques projets notamment les méthodes agiles, les tests, les bonnes pratiques (refactoring etc...). Je ne suis malheureusement plus qu'un demi développeur, sniff, mais je compte bien y revenir un peu plus ^^

  2. #22
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par highleaf Voir le message
    (.../...)Et non, construire un logiciel ce n'est pas construire une voiture ou un téléphone, un logiciel fait appel à de l'intelligence, c'est comme une oeuvre littéraire. C'est dingue de tout réduire à un monde d'objets que l'on doit consommer pour soutenir notre chère croissance en mousse. Quand est-ce qu'on parle de l'industrie littéraire et de l'industrie de la santé ? Je sais ça choque mais on y aussi
    Construire un logiciel, c'est concevoir une voiture ou un téléphone. C'est du même niveau. Pour avoir bosser dans l'automobile, je peux faire un parralèlle. Et, encore une fois, comparer le kanban industriel au kanban scrum, c'est de l'étirage de mots.

    Que le théoricien se soit inspiré de certains principes, soit. Mais chercher à faire un parralèlle, c'est induire le lecteur en erreur. La manière de penser est fondamentalement différente. Il faut 120 secondes pour injecter un pare-chocs. Ni plus, ni moins. De même qu'il faut 10 minutes à un agent pour enregistrer un contrat assurance auto. Mais le délai pour concevoir le pare-chocs, outillage compris, n'est pas garanti, car il faut faire appel à de l'intelligence. C'est pareil pour le développement. Et, dans les deux cas, quelles que soient les bonnes pratiques, l'echec est toujours possible. Le taux de rebut chez les équipementiers, il y a 10 ans, c'était 10ppm. Ca a du encore s'améliorer.

    Mais des projets qui partent dans le décor, il y en a, des deux cotés. Fréquemment. Et même en scrum(il suffit d'avoir un utilisateur bien psychopathe couvert par sa direction, ou d'une équipe de bras cassés en dev).

    J'insiste donc : si on peut s'inspirer de ce qui se fait ailleurs, croire qu'il s'agit d'un copier-coller est générateur d'erreurs. D'excellentes méthodologies, qui s'appliquent bien à certains sujets(pour une évolution majeure d'un SI bancaire liée à une évolution reglementaire, je ne vois pas comment éviter le waterfall), dans d'autres circonstances, c'est suicide de les utiliser(je fais un site web, j'ai 500 concurrents, et un seul survivra).

    Et puisqu'on parle de point de vue, je pense que la méthodologie est moins importante que les compétences. Parceque, comme en R&D industrielle(cf mes posts ci-dessus pour une définition précise), si on met 10 tanches, aucune n'aura l'idée du pare-chocs intégré ou de l'airbag. Même avec une méthodologie du feu de Dieu.
    Ca ne disqualifie pas le discours sur les méthodes, un free-to-play en waterfall, c'est casse-gueule, autant qu'une modif reglementaire en scrum. Choisir la bonne méthode, sans être la clef de tout, peut eviter bien des arrachages de cheveux. En ce sens, ta démarche est positive.

    Mais, ce contre quoi je m'insurge(et je ne pense pas être le seul), c'est la dictature de la méthode et du pilotage. L'illusion qu'il suffit d'avoir un bon pilote pour arriver à tout. L'illusion que quand tout va mal, il suffit de foutre un flic derrièrre chaque programmeur. L'illusion, aussi perverse, que la méthode qui a si bien marché ici est la réponse à tous les problèmes.

    Et bien non. La principale réponse à un problème est d'y foutre des gens de talent. Une bonne méthode est un gros plus. Mais ça n'est pas l'alpha et l'oméga.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #23
    Membre du Club
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    66
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 66
    Points : 63
    Points
    63
    Par défaut
    Moi je compare généralement mon métier de tous les jours à celui d'architecte - maçon. Oui, je sais, un architecte - maçon c'est pas courant pourtant je trouve qu'un informaticien c'est ça. On pense, on dessine, on modélise, puis on conçoit, brique après brique.

    Ça marche aussi très bien pour expliquer au client qu'on ne peut pas construire des étages en béton armé sur une base en carton platre

  4. #24
    Nouveau membre du Club
    Inscrit en
    Mars 2008
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : Mars 2008
    Messages : 28
    Points : 28
    Points
    28
    Par défaut
    "free-to-play en waterfall" j'adore ces nouveaux termes qui ne veulent rien dire typique des gens hypes de Paris .

    Les gars, il faut savoir rester pro-actifs et effectuer des synergies pour un meilleur reporting et une campagne de benchmarking efficace , je voudrais pas vous mettre en kick off et provoquer une spiel krieg, et oui moi aussi je traîne avec des merdeux.

    En un mot c'est tout de la merde ce verbiage de marketeux informatique.

  5. #25
    Invité
    Invité(e)
    Par défaut
    j'ai été un peu abrupt ci avant, par contre, en reformulant la question,

    L'industrie a des normes qui dépassent le stade de la bidouille, même si certains pseudo gourous pervertissent cette règle, elle reste exacte

    Il y a une confusion dans la question entre "informatique industrielle" et "industrie du logiciel" , je faisais référence à cette dernière ce matin comme plusieurs posts ici d'ailleurs

    Le ton rebelle de highleaf m'a fait réfléchir

    Y aura-t-il toujours de la place dans ce métier pour les méthodes empiriques et pour la RD ou peut on imaginer que les méthodes aux noms d'oiseaux suppriment la recherche au profit d'application pure et dure , un peu comme certains ERP dont je me suis toujours demandé si c'était une farce et dont le concept marketing a accouché le fameux Chorus qui est en train de mettre le pays à genoux. Il fait pourtant des profits record et vient de racheter sybase. OK un developpeur ERP ne fait pas de recherche mais plutot des audits, il prend peu de risque et excelle en conversation transparente.

    Peut on imaginer qu'un jour, les majors du logiciel "mangent" tout le gâteau, qu'on se retrouve sous les ponts ou pire : en complet veston, et que l'informatique devienne exclusivement une affaire d'hommes d'appareil ? Un peu comme les "technos" dans l'Incal Noir si qqun connait (ils finissent par éteindre l'univers !!)

    Ma réponse est NON

    Je crois que ce métier porte en lui le germe de l'imagination et de l'astuce qui coiffe au poteau le modèle industriel

    A la loyale si on a du capital, à la hussarde si on a la rage ou encore en combat de versions plus ou moins destinées à mettre les logiciels concurrents en panne (je pense à un éditeur en particulier là)

    Dans le top ten des majors qui règnent sur ce landerneau, c'est Google qui a le mieux intégré et exploité cette composante créative. Et hélas, aucun français ne fait partie des grands qui font ce marché et ça a toujours été comme ça zut.
    Dernière modification par Mejdi20 ; 27/05/2010 à 11h22.

  6. #26
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par highleaf Voir le message
    "free-to-play en waterfall" j'adore ces nouveaux termes qui ne veulent rien dire typique des gens hypes de Paris .

    Les gars, il faut savoir rester pro-actifs et effectuer des synergies pour un meilleur reporting et une campagne de benchmarking efficace , je voudrais pas vous mettre en kick off et provoquer une spiel krieg, et oui moi aussi je traîne avec des merdeux.

    En un mot c'est tout de la merde ce verbiage de marketeux informatique.
    Free-to-play : jeu internet gratuit, financé par la ventes de bonus(genre une meilleure arme, plus de points de vie......); y'en a plein.

    waterfall : cycle en V. Un projet ou, dès le départ, on définit tout ce dont on a besoin. Puis on fait, en une seule passe. Méthode très courante, appliquée un peu partout, parfois de manière très rigide.

    A ce sujet, j'ai vu, au cours de mon passage chez un éditeur de logiciel, une guerre absolue des "anciens" contre les "nouveaux", avec une mauvaise foi totale des deux cotés. Mon équipe était clairement du côté des "nouveaux". Le discours était : "le cycle en V c'est de la daube. Argument : la dernière fois, ils ont refusé de nous allouer des moyens avant d'avoir fini la conception; comment on vérifie techniquement que notre archi marche?" : ma réponse : ce n'est pas parce que les anciens appliquent la méthode sans réfléchir que la méthode est toujours mauvaise. Pareil dans l'autre sens, le seul "ancien" critiquait : "bon, les méthodes agiles, c'est gentil, mais un seul projet occupe tout le tableau avec ses post-its. Comment on fait si d'autres équipes passent en agile?" Ma réponse : en ajoutant un tableau, peut-être?

    Conclusion, toujours la même : la méthode, c'est important, mais tant que c'est appliqué par des gens qui ne comprennent rien, en fait, c'est juste du blabla. Je suis tout à fait d'accord avec UnBonGars à ce sujet, ceux qui privilégient la méthode sur la compétence vont à l'échec. Et c'est la grosse tendance, pourtant, chez les décideurs modernes : quand on parle de "ressources humaines", c'est que le travailleur a autant de valeur qu'une caisse de minérai de fer. Et surtout qu'il est indifférencié. La grande imposture des RH modernes, c'est que l'on croit que choisir des gens beaux, jeunes et communiquants garantit le bon succès du projet, quel que soit leur niveau de compétences. Ben non. Quand on a une appli abominable à maintenir et à faire évoluer, et que le seul gars qui accepte(et qui aie les compétence pour) est une ordure autiste nazie de 50 ans, eh bien c'est le bon choix - même en comptant l'impact négatif de ses commentaires criminels sur la bonne ambiance de l'équipe.

    Après, si le management sait l'encadrer, c'est un gros plus. Si la méthode choisie est adaptée, c'est bien(en l'occurence, on faisait de l'agile sans le nommer, et ça fonctionnait très bien). Mais l'essentiel, c'est d'avoir quelqu'un qui fait le boulot avec compétence, et sans rechigner. J'imagine que c'est celà, highleaf, que tu souhaites dire(à ta manière).
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #27
    Membre éclairé
    Profil pro
    Inscrit en
    Février 2010
    Messages
    412
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2010
    Messages : 412
    Points : 807
    Points
    807
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    waterfall : cycle en V. Un projet ou, dès le départ, on définit tout ce dont on a besoin. Puis on fait, en une seule passe. Méthode très courante, appliquée un peu partout, parfois de manière très rigide.
    Je souhaiterai juste indiquer que waterfall et cycle en V, on ne m'a jamais dit que c'était pareil. Pourtant j'ai eu plusieurs profs venant d'endroits et cultures différentes.

    Citation Envoyé par el_slapper Voir le message
    la méthode, c'est important, mais tant que c'est appliqué par des gens qui ne comprennent rien, en fait, c'est juste du blabla.
    Pour ça que dans les méthodes agiles ils disent qu'ils faut des gens compétents. Ils se mouillent pas trop...

  8. #28
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Rams7s Voir le message
    Je souhaiterai juste indiquer que waterfall et cycle en V, on ne m'a jamais dit que c'était pareil. Pourtant j'ai eu plusieurs profs venant d'endroits et cultures différentes.
    j'ai péché par imprécision. Le cycle en V est une forme de waterfall. Comme je n'ai jamais pratiqué les autres.....

    Citation Envoyé par Rams7s Voir le message
    Pour ça que dans les méthodes agiles ils disent qu'ils faut des gens compétents. Ils se mouillent pas trop...
    Jamais lu ça, mais ça ne m'étonne pas. Parceque bon, évidemment, si on prend une tanche en waterfall et un génie en agile, bizarrement, l'agile sera supérieur
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  9. #29
    Membre régulier
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2008
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2008
    Messages : 73
    Points : 122
    Points
    122
    Par défaut
    Une Tanche restera une tanche ... quoi qu'on lui demande ...nan ?

  10. #30
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    Novembre 2004
    Messages
    1 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 224
    Points : 2 373
    Points
    2 373
    Par défaut
    Pas toujours, parfois c'est juste qu'on les emploie pas pour la bonne chose.
    J'ai déjà vu des gens bons dans un contexte et moins dans un autre.

    Bon mais des fois c'est vrai que...

  11. #31
    Membre régulier
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2008
    Messages
    73
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2008
    Messages : 73
    Points : 122
    Points
    122
    Par défaut
    Moi , j'appelle cela un Boulet ...

    Mais comme on est toujours le Con de quelqu'un ... on peut toujours etre aussi le Boulet de quelqu'un ..?

  12. #32
    Membre éprouvé
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    764
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 764
    Points : 909
    Points
    909
    Par défaut
    Le tour qu'a pris cette discussion me fait assez penser à celle-ci, et particulièrement à ce message.

    Les génies seront toujours des génies.
    Les boulets seront toujours des boulets.
    Pour les moyennement bons et moyennement motivés sans prétentions, le fait d'être encadrés par une "école" ou par un "processus qualité" peut grandement aider...

  13. #33
    Membre actif
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    333
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 333
    Points : 295
    Points
    295
    Par défaut
    Je me sens obligé de réagir là

    Conclusion, toujours la même : la méthode, c'est important, mais tant que c'est appliqué par des gens qui ne comprennent rien, en fait, c'est juste du blabla.
    Pas vraiment d'accord ... je suis plutôt :

    Pour les moyennement bon et moyennement motivé sans prétention, le fait d'être encadrés par une "école" ou par un "processus qualité" peut grandement aider...
    Quand on arrive dans le monde du travail on est pas prêt à bosser à un niveau professionnel, heureusement que l'on peut s'appuyer sur des méthodes et des processus qui peuvent nous encadrer...

    Ah oui je vois le genre d'informaticien industriel : celui qui parle comme dans les services commerciaux et marketing et se prend pour un trader, celui qui utilise des frameworks de 300 Mo pour livrer un utilitaire de 2Mo, celui qui utilise les usines à choucroute Java pour faire un hello world et enfin ceux qui construisent des applications en ligne sans même savoir ce qu'est du HTML ou encore ceux qui modélisent de la base de données en UML, oui je vois le genre d'informatique industrielle qui se profile.
    Ce n'est pas parce qu'on connait des concepts que l'on est obligé de les suivre à la lettre, tandis que si tu ne les connais pas ... pas de risque...
    Par exemple : ce n'est pas parce que tu utilises une modélisation UML pour générer ta base ou ton code que tu ne sais pas faire du java ou du sql ...


    A ce sujet, j'ai vu, au cours de mon passage chez un éditeur de logiciel, une guerre absolue des "anciens" contre les "nouveaux", avec une mauvaise foi totale des deux cotés.
    La vérité est .... souvent entre les deux
    Tu oublies ceux qui refusent toute méthode entre le petit jeune "nan mais c'est clair là ma variable x elle fait ça et couplée avec i,e,f on obtient r" qui refuse de faire des efforts et le vieux de s'adapter "nan mais c'est pourris ton svn ça marche pas ... je t'envoie un zip en te disant ce qui a changé et tu copies/colles ..."


    On a introduit des méthodologies pour pouvoir travailler à plusieurs selon différents contextes. Une méthodologie n'est qu'un regroupement de "best practice" pour un contexte particulier le tout guidé par une orientation générale ....

    Il n'y a pas de mauvaises méthodologies seulement des choix inadaptés aux besoins

    Un artisan par définition travail seul, tandis que l'industriel mis sur la masse ... il suffit de compter avec combien de personnes vous travaillez au quotidien pour savoir de quel bord on est !!

  14. #34
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Moi j'ai déjà exprimé souvent mon opinion, et je pense qu'on est (et devrait) être plus proche de l'artisanat que de l'industrie...

    Un débat de référence dans lequel beaucoup de points sont soulevés (et d'intervenants se sont exprimés) est :

    Projets informatiques : Les Bonnes Pratiques

    et ce post où j'expose mon point de vue.

    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  15. #35
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    Novembre 2004
    Messages
    1 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 224
    Points : 2 373
    Points
    2 373
    Par défaut
    C'est amusant mais ton point de vue rejoint les méthodologies lean et agiles. Même si tu n'aimes pas le mot "méthodologie", qui pourtant n'est rien d'autre qu'une recette de cuisine ou un pattern, ce que tu évoques :
    - la reconnaissance des connaissances (ne pas parler de ressources humaines comme si elles étaient interchangeables)
    - prendre des bons (ou tout du moins leur donner les moyen de le devenir)
    - faire des équipes pluridisciplinaires
    - inclure le métier dans l'équipe

    fait partie intégrante des méthodologies agiles/Lean.




    En tout cas pour ce que je lis des personnes qui ont réagi ici, plusieurs partagent ce même point de vue, c'est avant tout les compétences personnelles qui font un projet réussi. C'est en partant de ce constat que vous comparez l'informatique à l'artisanat. C'est bien ça ?

    Autre point que je crois comprendre en lisant les avis ci-dessus, la réussite d'un projet étant lié aux qualités des personnes, les standards ne sont pas importants (ou pas primordiaux en tout cas).


    Pour ma part je ne suis pas sûr que la qualité individuelle fasse partie de la définition de l'artisanat. On peut être bon quelque soit la façon de bosser. On peut être bon dans un contexte et pas dans un autre, d'où la nécessité d'être employé à bon escient comme le souligne souviron34.
    En tout cas le fait de dire "les projets qui marchent reposent sur les individus", je partage largement. Mais ce n'est pas pour autant que je fais la liaison avec la façon de bosser.

    Quant aux standards (méthodologies, normes, etc...) partant du simple fait que la majeure partie des appli passe 80% de son temps en maintenance et reste rarement aux mains de son/ses créateurs, je pense qu'ils sont importants. Comme dit plus haut :

    Pour les moyennement bons et moyennement motivés sans prétentions, le fait d'être encadrés par une "école" ou par un "processus qualité" peut grandement aider...
    Ça vaut aussi pour les bons qui débarquent sur un projet et qui aiment y trouver une structure qu'ils ont déjà vu.

  16. #36
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par hugo123 Voir le message
    (.../...)

    Quant aux standards (méthodologies, normes, etc...) partant du simple fait que la majeure partie des appli passe 80% de son temps en maintenance et reste rarement aux mains de son/ses créateurs, je pense qu'ils sont importants. (.../...)
    Sur ce point, parce que sur le reste, on se répète tous.....(sans être à des kilomètres, d'ailleurs)

    Le truc, c'est que je ne vois pas comment une méthodologie peut préparer à faire un code maintenable. Je n'ai pas dit propre (ça , c'est faisable), j'ai dit maintenable. Celui qui n'a jamais fait de maintenance ne peut pas savoir quel effet ça fait de déterrer un code de 35 ans d'âge. Et d'y voir la fière structure du fier développeur qui croit avoir fait un truc maintenable, et en fait a pondu une horreur intouchable. Parce qu'il ne savait pas. Moi aussi, je suis passé par là, j'ai fait de la surencapsulation pour faire plus propre, et j'ai rendu illisible un programme de même pas 150 lignes(avec 6 niveaux d'encapsulation).

    Le bon niveau d'encapsulation(parmi d'autres), il ne se définit pas, il se sent, avec l'expérience. L'expérience de la maintenance. Tant qu'on fait du projet, on se prend(à tort, et j'ai pratiqué) pour le roi du monde.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  17. #37
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    Novembre 2004
    Messages
    1 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 224
    Points : 2 373
    Points
    2 373
    Par défaut
    Tout a fait d'accord, la notion de maintenable n'est pas évidente, surtout qu'on a tous la désagréable habitude de pester sur le travail des mecs précédents ^^

    Mais maintenable des fois c'est juste faire preuve de bon sens, c'est avoir une norme de codage standard (les normes SUN par exemple en JAVA), l'utilisation de design pattern standard avec un nom qui correspond bien à ce que ça fait (une classe qui s'appelle une factory doit fabriquer des objets et pas faire autre chose). C'est aussi avoir un logiciel d'intégration continue qui tourne avec un bon harnais de test, c'est d'avoir des procédures qualité (revue de code par exemple) etc...
    Un truc tout bête, j'arrive sur un projet JAVA, ils utilisent Maven et ont donc respecté le SDL (standard directory layout), je sais tout de suite comment monter mon projet sous eclipse, où sont les sources, où sont les tests et mes informations de builds. Ça ne veut pas dire que je suis autonome, mais ça aide grandement.

    Quant à la méthodologie, dans une méthode itérative vu qu'on retouche souvent aux mêmes trucs, si on n'automatise pas les tests, le build et qu'on oublie les tests où qu'on ne maitrise pas les outils de refactoring de son IDE préféré, c'est vite difficile. Du coup on apprend à le faire, poussé par la méthode.

Discussions similaires

  1. Réponses: 21
    Dernier message: 20/04/2013, 11h52
  2. [Outil]Simulation de dégradation des temps de réponse
    Par Laurent Dardenne dans le forum Développement
    Réponses: 4
    Dernier message: 07/06/2006, 17h23
  3. Réponses: 4
    Dernier message: 03/03/2006, 17h03
  4. [Oracle 8i]Sommer des temps
    Par venusiafalls dans le forum Oracle
    Réponses: 15
    Dernier message: 19/07/2005, 11h09

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