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 :

Qui pratique la programmation spontanée ?


Sujet :

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

  1. #301
    Membre averti
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 329
    Points
    329
    Par défaut
    Citation Envoyé par zecreator
    ... pour quel type de projet doit t-on intégrer une cinquantaine de personnes ? Pour le jeu vidéo OK, je comprend car il y a diverses spécialisation (3D, audio, vidéo, gameplay, test...), mais pour une application de gestion, là je vois pas l'utilité d'une si grande équipe...
    Concernant les appli de gestion, je peux te demander de jetter un coup sur le code source de l'ERP Compiere, il est disponible sur sourceforge. une soixantaine de personnes y travailles dessus

  2. #302
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    1 363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 363
    Points : 3 498
    Points
    3 498
    Par défaut
    Citation Envoyé par zooro
    Eh bien... Je vois les applis télécom (pas toutes, mais si tu regardes un peu les standards 3GPP et autres protocoles télécom, tu te rendras compte que tout avoir dans la tête, même si on est "créatif", c'est impossible), des projets de refonte de SI dans les banques, des applis médicales, certains projets de la défense, des projets aéronautique (tu te vois coder tout seul tout le système informatique d'un Airbus ???)...
    Et je suppose que tout le monde a quelques exemples personnels à donner.
    Donc on est d'accord pour dire que les formalismes sont indispensables dans certains secteurs d'activités mettant en place de gros projets de gestion, mais que cela peut être optionnel dans d'autres secteurs plus ludiques, comme le jeu vidéo, les outils multimedia...

    Les formalismes de développement font apparaitrent surtout des projets utilisant des moyens financiers et/ou humains étendus.

    Comme je suis curieux, est-ce que ceux qui développent dans le domaine professionnels élaborent également des projets persos ? Et utilisent t-ils ses formalismes pour eux ?
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  3. #303
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 260
    Points
    1 260
    Par défaut
    Citation Envoyé par zecreator
    Comme je suis curieux, est-ce que ceux qui développent dans le domaine professionnels élaborent également des projets persos ? Et utilisent t-ils ses formalismes pour eux ?
    Oui. Moins ces dernières années, mais je compte m'y remettre.
    Je n'ai que rarement fait des docs, parce qu'en général mes projets étaient vraiment minuscules, et qu'un fichier readme suffisait à tout expliquer.
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  4. #304
    Membre éprouvé
    Avatar de _solo
    Profil pro
    Inscrit en
    juin 2006
    Messages
    889
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 889
    Points : 1 228
    Points
    1 228
    Par défaut
    Pour repondre au sujet initiale pour moi c'est oui , je fait de la programmation spontanee , mais sur des mini-projet tout aussi spontanee ( rarement plus de 5k lignes de codes mais presueq tous plus de 1k ), tout en sachant que bien sur moi je suis pas un devellopeur mais je suis admin .
    Qu'est-ce que j'entend par projet spontanee :: quand on se rend compte qu'il manque un utilitaire hop faut un machin pour dans trois jour parce que le client en a tout de suite besoin et qu'on veut pas payer 10 000 Euros pour 3h d'utilisation d'un logiciel , ou alors rajouter une fonctionnailte a un logiciel ).
    Soit moi sa n'a rien a voir avec vos projet de 4G de lignes de codes mais ca reste de la programmation .
    meme si je me souviens que fait le soft au bout d'un mois le code est commenter et permets a celui/celle qui passe par la de continuer ou de rectifier ce que j'ai fait
    voila c'etait mon avis

  5. #305
    Membre du Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    janvier 2004
    Messages
    61
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : janvier 2004
    Messages : 61
    Points : 56
    Points
    56
    Par défaut
    J'arrive peut-être un peu tard (ce fil est référencé par la newsletter d'octobre, félicitations !)

    Peut-être que l'avis d'un étudiant "contre" la programmation spontanée (je n'ai pas tout lu, peut-être ne suis-je pas le seul étudiant dans ce cas — je l'espère ! —) compte, puisque justement je n'ai pas l'expérience des "vieux" sur des projets de grande ampleur.

    Je suis en école d'ingénieurs, en informatique, après un DUT Informatique (pour placer les choses).

    D'abord, quel est le langage utilisé ? Nous avons eu la joie d'apprendre, l'année dernière, le Lisp. Qui veut faire de la programmation spontanée oubliera ce langage. Et ce n'est pas le seul à être dur à lire (quel doux euphémisme !). Ensuite, d'autres langages plus communs permettent, effectivement, de faire plus facilement du bricolage. Et encore, ils ne sont pas très nombreux, même si au premier abord on peut s'y tromper. C'est vrai qu'on peut "s'amuser" sur C++ (j'en connais qui ont commencé à programmer là-dessus, les pauvres), mais de là à faire quelque chose de professionnel et d'efficace, il y a un gouffre sans fond (infranchissable, garanti).

    Ensuite, comme d'autres l'ont dit, si le programme est repris par quelqu'un d'autre, il faut qu'il soit compréhensible. Je vais me baser sur ma propre expérience : à l'IUT, on m'a demandé de reprendre un logiciel existant en Delphi/Interbase, qui présentait "quelques" bugs (qui empêchaient néanmoins l'utilisation initialement prévue). Sur 1500 lignes de code (une bagatelle, assurément), il n'y avait que 6 lignes de commentaires. On peut se dire que 1500 lignes, il n'y a pas besoin d'être sorcier pour lire ça. Ben faut croire que si. Je n'ai gardé que l'interface. Et pourtant, quand un camarade avait un problème, il me demandait où était le bug. Ca ne ratait jamais (ou presque), je trouvait le bug, aussi sale fut le code. Je n'essaie pas de m'envoyer des roses, mais comme quoi, même en prétendant savoir lire le code des autres "facilement", on trouve toujours plus fort que soi.

    Par ailleurs, l'évolution du produit est essentielle. Dans les années 70, des programmeurs improvisés ont écrit en Cobol des logiciels de gestion pour des banques. La plupart n'avaient pas de formation professionnelle et ne se souciaient pas de fournir une documentation complète de leur produit. A l'approche de l'an 2000, beaucoup d'établissements bancaires ont payé une fortune pour mettre à jour leur système. Alors qu'avec une documentation (et sous réserve que le code soit bien structuré), on aurait presque pu continuer en Cobol, en mettant juste quelques détails à jour. Ensuite, il est vrai, pour coller au domaine précédemment cité, que beaucoup de jeux vidéos meurent très jeunes (les pauvres) et n'ont pas le temps de connaître le poids des années.

    Egalement, le travail en équipe. Nous avons récemment produit un compilateur en TP (de compilation, comme c'est étonnant !) dans le cadre de notre formation. Quelqu'un aurait pu s'en charger tout seul, éventuellement, mais l'objectif était aussi de travailler dans une équipe de 8 (ce qui n'est pas grand chose à côté de ce qui nous attend plus tard). Si nous n'avions pas utilisé une formalisation UML pour pouvoir tout faire fonctionner ensemble, on n'y serait jamais arrivés. D'ailleurs dans l'équipe voisine, ils ont pris les décisions sans rien noter, et chacun a fait en pensant qu'il respectait les consignes. Résultat : pour peu ils y seraient encore (ça fait 6 mois de ça).

    Enfin, essayons de faire la comparaison avec les autres secteurs de production. Est-ce qu'on a déjà vu des ingénieurs dans l'automobile construire une voiture, en corrigeant et en testant, avant de dire : "OK, vous pouvez en faire d'autres comme celle-là", sans faire une étude structurée, des modélisations 3D, des tests en simulations, ... A-t-on déjà rencontré des ingénieurs en aéronautique assembler des bouts de métal avant de réfléchir en projet et en commissions aux différents aspects de l'avion ? Ou encore, le viaduc de Millau a-t-il été construit au "feeling" ? Pourquoi l'informatique ne serait pas elle aussi rigoureuse ?


    J'ai sans doute répété ce que beaucoup d'autres ont dit précédemment, 20 pages ça faisait beaucoup à lire d'un coup.


    En bonus, un petit cadeau aux "programmeurs spontanés". L'énoncé du problème est le suivant : un voyageur de commerce doit pour son travail traverser un ensemble de N villes. Il doit toutes les traverser une fois et une seule. Le chemin choisi doit le ramener à son point de départ. Le problème est de trouver le ou les chemins les plus courts qui vérifient ces propriétés.
    (ceux qui connaissent la solution, ne la donnez pas )
    On s'amuse de rien en vieillissant, on vieillit quand on ne s'amuse plus.

  6. #306
    Membre expérimenté
    Profil pro
    Développeur en systèmes embarqués retraité
    Inscrit en
    mars 2006
    Messages
    934
    Détails du profil
    Informations personnelles :
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués retraité
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2006
    Messages : 934
    Points : 1 348
    Points
    1 348
    Par défaut
    Yo,

    Je suis actuellement dans une vraie équipe de développeurs, c'est que du bonheur! Par le passé, j'ai travaillé dans une boite où le mot d'ordre était "On est là pour gagner de l'argent." Résultat, on vendait des softs, et il fallait se dépêcher ensuite pour les coder. On y affectait un gars qui se débrouillait tout seul en programmation spontanée pour arriver à un résultat vendable, souvent sans avoir de vraie connaissance "métier" (compta, en l'occurence), et les stagiaires, c'était bien, ça coutait pas cher. Bref, un louable excercice de style, impeccable commercialement... C'était vendu avec le contrat de maintenance. Résultat des courses, plus de hotlineurs que de développeurs, 2 arrêts de travail dans l'encadrement pour dépression grave au passage à l'euro, et la boite quasiment sur les genoux. 1800 programmes avec chacun une gestion différente de l'euro, souvent écrite plusieurs fois dans le soft, la version informatique de la roulette russe... J'ai passé des heures a essayer de comprendre des sources sans commentaires et sans structure. Ca pousse vraiment à coder correctement. La meilleure de toute: Le dépannage en urgence chez le client, à se faire traiter de tous les nom pour un soft qu'on n'a pas écrit... La semaine suivante, le patch qu'on vient de faire est écrasé par une mise à jour automatique... Tout le monde dans son expérience scolaire devrait être confronté à ce genre de truc, ça évite par la suite de coder comme un boulet.

    Je n'ai rien contre les petits génies, ils sont là pour avoir des idée, mais il faut qu'ils se contentent de ça, c'est absolument incompatible avec une programmation professionnelle. Parce que j'en ai vu une paire commencer plein de choses pour les laisser finir par les autres, c'est ce qu'il peut arriver de pire mais c'est très fréquent. On est bon pour réécrire, et c'est très dur à justifer. Perso, je ne suis pas capable de dire à un chef de projet "c'est n'importe quoi, ton truc", même si c'est vrai.

    A+

    Pfeuh

  7. #307
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 260
    Points
    1 260
    Par défaut
    @pfeuh: un gros +1 !

    Pour un peu, je croirais que t'es dans la même boîte que moi !
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  8. #308
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    1 363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 363
    Points : 3 498
    Points
    3 498
    Par défaut C'est une évidence...
    pfeuh a dit : Je n'ai rien contre les petits génies, ils sont là pour avoir des idée, mais il faut qu'ils se contentent de ça, c'est absolument incompatible avec une programmation professionnelle. Parce que j'en ai vu une paire commencer plein de choses pour les laisser finir par les autres, c'est ce qu'il peut arriver de pire mais c'est très fréquent. On est bon pour réécrire, et c'est très dur à justifer. Perso, je ne suis pas capable de dire à un chef de projet "c'est n'importe quoi, ton truc", même si c'est vrai.
    Encore heureux, ils ne t'ont rien fait. Je pense que ceux qui pratiquent régulièrement la programmation spontanée, ne sont pas forcément des génies (que l'on ne voit pas là une insulte de ma part), mais on sûrement la capacité d'analyser rapidement un besoin et de concevoir une solution. Je pense aussi, je prend mon cas, que ceux sont des personnes qui aiment expérimenter des nouvelles techniques et qui peuvent passer beaucoup de temps sur un bout de code. Et pour finir, ceux sont des personnes qui ne manquent pas de resources et peuvent utiliser une large palette d'outils de développement différents.

    pfeuh a dit : Par le passé, j'ai travaillé dans une boite où le mot d'ordre était "On est là pour gagner de l'argent." Résultat, on vendait des softs, et il fallait se dépêcher ensuite pour les coder. On y affectait un gars qui se débrouillait tout seul en programmation spontanée pour arriver à un résultat vendable, souvent sans avoir de vraie connaissance "métier" (compta, en l'occurence), et les stagiaires, c'était bien, ça coutait pas cher.
    Maintenant, utiliser ce type de programmation lorsque tu as des clients qui paient des milliers €, c'est un peu sucidaire. C'est malheureusement très tendance comme pratique. Comme je le disais dans un ancien POST, les SSII sont tenues par des commerciaux qui sont là pour vendre, et qui ne se soucient pas des contraintes techniques. Perso, les SSII je les fuis comme la peste, ça tue l'épanouissement des développeurs dans leur métier.

    (J'ai jamais pû sentir les blaireaux en costard-cravate, avec un gros salaire, qui te considère comme un simple outil et qui viennent te dire comment tu dois bosser, alors qu'ils n'y connaissent rien...)

    Alain Dionne a dit : Ensuite, comme d'autres l'ont dit, si le programme est repris par quelqu'un d'autre, il faut qu'il soit compréhensible.
    Tu t'apercevras vite que beaucoup de développeurs aiment à garder secret leur codes sources (ce qui me semble légitime personnellement), et ne te faciliteront pas le travail de récupération. Y a aussi de l'orgueil chez les développeurs, et la volonté de garder l'exclu de son code...
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  9. #309
    Membre habitué Avatar de 5:35pm
    Profil pro
    Inscrit en
    avril 2006
    Messages
    201
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2006
    Messages : 201
    Points : 196
    Points
    196
    Par défaut
    Citation Envoyé par zooro
    @pfeuh: un gros +1 !

    Pour un peu, je croirais que t'es dans la même boîte que moi !

    Pareil dans ma boite!
    il y avait un genie qui nous a quitte, son code etait un peu brouillon, complexe, mais remarquablement intelligent.
    aujourd'hui son nouveau remplacant en souffre, il a herite d'un source complexe et non documente
    depuis, je me mets a documenter, il est clair que ca rendra service.


    Tu t'apercevras vite que beaucoup de développeurs aiment à garder secret leur codes sources (ce qui me semble légitime personnellement), et ne te faciliteront pas le travail de récupération. Y a aussi de l'orgueil chez les développeurs, et la volonté de garder l'exclu de son code...
    je crois que le centre de ce debat, c'est bien l'orgueil...
    vouloir garder son source secret, c'est vouloir trahir la boite qui t'emploie.

  10. #310
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 260
    Points
    1 260
    Par défaut
    Citation Envoyé par zecreator
    Tu t'apercevras vite que beaucoup de développeurs aiment à garder secret leur codes sources (ce qui me semble légitime personnellement), et ne te faciliteront pas le travail de récupération. Y a aussi de l'orgueil chez les développeurs, et la volonté de garder l'exclu de son code...
    Du coup si demain tu te fais écraser par une voiture, ton successeur risque de te maudire...
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  11. #311
    Membre à l'essai
    Inscrit en
    octobre 2004
    Messages
    14
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 14
    Points : 19
    Points
    19
    Par défaut
    Il y a peut-être un milieu entre la programmtion spontanée et la progrmmation "réfléchie.
    Je me suis remis à la programmation après 15 ans d'arrêt. Si les méthodes d'étude ne sont plus les mêmes, c'est parce que les langages ont évolué. J'ai donc choisi d'y revenir par le PHP qui me laissait une grande liberté.
    Mais maintenant, je travaille avec des classes et je commence à les étendre. Ce n'est pas pour ça que je modélise mon application de façon formelle. Je commence par "visualiser" les écrans dont j'ai besoin, puis les échanges nécessaires au fonctionnement et je déduis ainsi la structure des données que je pense optimale. Je fais cela en pensant toujours que mon application va évoluer, donc je sépare au maximum (parfois à l'extrème) les données "pures" des index.
    De plus, comme c'est de l'Open Source, je commente mon code le plus possible.

    La programmation spontanée telle qu'elle est définie au début de ce fil n'est envisageable que pour un prototype. Il faut ensuite reprendre le code et le structurer. Mais ça permet d'avoir une idée claire de ce que l'on veut faire.

    Bien sûr je suis loin des milliers de lignes de certains et je comprends que ce genre de situation nécessite des méthodes rigoureuses. Par contre, j'estime quelles "brident" l'imaginaire du développeur qui ne fait plus que chercher des solutions en appliquant des règles au lieu de se fier à son inspiration.
    Et c'est là quelque chose que j'ai constaté à de nombreuses reprises, avec des développeurs qui savent bien appliquer les méthodes modernes mais, à cause de leur manque de "projection", sont incapable de corriger un bug.

    Pour conclure, l'usage de la programmation spontanée ne doit être emplyée qu'au début d'un développement. Elle permet au développeur de se poser certaines questions et de ne pas se retrancher derrière une quelconque méthode d'étude. Il faut ensuite le structurer, ne serait-ce que pour l'optimiser. Car si tout le projet est géré de la même façon, on va droit dans le mur...

  12. #312
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 260
    Points
    1 260
    Par défaut
    Citation Envoyé par globule
    Par contre, j'estime quelles "brident" l'imaginaire du développeur qui ne fait plus que chercher des solutions en appliquant des règles au lieu de se fier à son inspiration.
    Et c'est là quelque chose que j'ai constaté à de nombreuses reprises, avec des développeurs qui savent bien appliquer les méthodes modernes mais, à cause de leur manque de "projection", sont incapable de corriger un bug.
    Pas trop d'accord. Les formalismes ne sont utilisées que pour décrire, pas pour chercher des solutions. Tu réfléchis, tu imagines une solution au problème, et tu la décris à l'aide des différents formalismes utiles.

    C'est sûr que les méthodes ne sont pas là pour résoudre le problème posé par le cahier des charges, mais pour encadrer le projet. S'il suffisait d'appliquer une méthode pour obtenir un programme, ça fait longtemps que les ordinateurs s'auto-programmeraient !

    Citation Envoyé par globule
    La programmation spontanée telle qu'elle est définie au début de ce fil n'est envisageable que pour un prototype. Il faut ensuite reprendre le code et le structurer. Mais ça permet d'avoir une idée claire de ce que l'on veut faire.
    Là, je suis plutôt d'accord avec toi. Pour faire rapidement un prototype, inutile de décrire pendant des jours ce qu'on va faire.
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  13. #313
    Membre averti
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 329
    Points
    329
    Par défaut
    Re salut

    J'ai l'impression que l'on fait un peu de mélange. Le thème parle de programmation (pas de conception, pas d'analyse) spontanée. Donc je me situe à la phase de programmation une fois que j'ai compris ce que doit programmer (je peux l'avoir compris en lisant un schéma UML, ou un cahier de charge). Pendant cette phase, on doit coder en ayant à l'esprit qu'on doit se faire comprendre aussi bien par un lecteur humain que par la machine et on peut y parvenir avec un minimum de commentaire/documentation. Car j'ai déjà vu à plusieurs reprises des commentaires, et des documentation ambigus. Si bien que c'est en lisant le code lui même que je comprend ce que le redacteur voulait dire dans ces commentaires/documentations.

    Et pour la maintenance d'un code source, si on programme "proprement" avec des noms de variables,methodes etc. non ambigus, avec une structure simple, un bon système de loging, l'utilisation en plus d'un IDE riche est largement suffisant pour permettre une bonne maintenance du code. (franchement je ne vois même pas l'aide que pourrait m'apporter en plus des docs externes ou des diagrammes UML)

  14. #314
    Membre expert

    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2006
    Messages
    1 363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : janvier 2006
    Messages : 1 363
    Points : 3 498
    Points
    3 498
    Par défaut
    vouloir garder son source secret, c'est vouloir trahir la boite qui t'emploie.
    Je vais jouer mon gars de gauche mais, vu le nombre de compétences demandées à un développeur et le refus par les employeurs de revaloriser les salaires, c'est de bonne guerre.

    N'oublions-pas que les développeurs, tout comme n'importe quel métier de création peuvent prétendrent à un droit intellectuel sur leurs productions, ce que les entreprises ont tendance à oublier.

    Bien sûr je suis loin des milliers de lignes de certains et je comprends que ce genre de situation nécessite des méthodes rigoureuses. Par contre, j'estime quelles "brident" l'imaginaire du développeur qui ne fait plus que chercher des solutions en appliquant des règles au lieu de se fier à son inspiration.
    Tout à fait d'accord sur le fait que les méthodes d'aujourd'hui brident trop le développeur et sa créativité. On fini par devenir des robots, comme à la grande époque d'IBM, mais en plus coloré.
    "La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"

  15. #315
    Membre régulier Avatar de siplusplus
    Profil pro
    Inscrit en
    septembre 2006
    Messages
    78
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : Belgique

    Informations forums :
    Inscription : septembre 2006
    Messages : 78
    Points : 107
    Points
    107
    Par défaut
    Bonjour,

    Je pense que l'on peut faire une analogie avec la littérature
    Lorsqu'on écrit de petits textes ou que l'on poste un message
    nous avons rarement besoin de faire préalablement un "brouillon".
    Maintenant lorsqu'il s'agit d'écrire un livre c'est une autre paire
    de manches...
    Dans ces deux cas, l'origine est la même. L'information est traîté
    par le cerveau puis en fonction de la taille du travail on utilise ou
    non un "brouillon".

    En ce qui concerne le domaine scientifique, dont l'informatique,
    nous sommes tenu à une démarche formelle,
    que ce soit avec un "brouillon papier" ou un "brouillon mental".
    Ces deux brouillons permettent d'arriver au résultat. La différence
    c'est la capacité du "brouillon mental". Personnellement, je m'efforce
    toujours de modéliser sur papier car cela me permet de revenir dessus
    bien longtemps après et cela me fait gagner du temps parcequ'il n'y a
    plus besoin de redevoir réfléchir à nouveau sur les bases.
    Pensez aux joueurs d'échec, ils réfléchissent à plusieurs coups
    à l'avance. Mais la partie n'est pas nécessairement un programme car
    cette partie ne sera pas forcément la même la fois suivante...

    Quand à l'art et la science, le premier se base plus sur l'unicité
    car il est rare de voir plusieurs oeuvre identiques si ce n'est des copies.
    Tandis que le second devra toujours réagir de la même manière obéir
    toujours aux mêmes lois, à la même logique comme le ferait la plupart des
    programmes.

    Pour ce qui est de transmettre l'information, c'est une autre question.
    Cela relève plus de projet de groupe pour lequel celui-ci devra utiliser un
    langage commun pour que l'ensemble puisse se comprendre sans ambiguïté.

    C'est un débat très vaste mais enrichissant.


    ps: pour ce message je n'ai pas utilisé de brouillon

  16. #316
    Membre du Club
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    60
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2006
    Messages : 60
    Points : 55
    Points
    55
    Par défaut
    Eh ben, quel débat !!!

    Je sens comme une odeur de chaussettes cramées au début de la discussion. le type, 'DOLOOP', invité de passage de surcroit, a les chevilles qui enflent
    Perso, je programme depuis plus de 10 ans dans différents langages (Delphi, VB, C++ principalement), et je n'ai que 2 mots à dire : CONNAISSANCE et PRATIQUE.
    Dans toute discipline scientifique (et oui l'informatique en est une), les bases et la pratique régulière sont obligatoires et indissociables. Dans ce forum, il y a beaucoup de personnes qui l'ont bien compris et l'ont cité à juste titre. Merci d'avoir fermer le clapet de cet einstein.
    Bon, il est vrai que la programmation spontanné est tout à fait logique avec la pratique. qui n'a jamais codé une routine en moins d'une heure sans dessiner le moindre UML, hein ? franchement.
    Soyons honnetes, nous somme tous capable d'en faire autant.
    D'un autre côté, et là je vais jeter un pavé dans la marre , l'utilisation excessive d'une modélisation peut provoquer ce que l'on pourrait appeler : la machine à gaz. Je sais, vous allez me dire : 'il est con celui là, c'est fait pour simplifier !!' . Oui je sais, mais dans bon nombre de cas, la modélisation apporte plus de contrainte qu'autre chose. La performance d'une programme ou d'une routine ne réside pas dans sa modélisation tip-top, mais dans son optimisation de codage.
    Eh oui, je suis un adepte des optimisations extrèmes, et je déteste le java pour cette raison.... bref, cela pourrait être un autre débat.
    je finirai là dessus : PERFORMANCE = OPTIMISATION / MODELISATION
    trop de modélisation tue la modélisation
    Salut

  17. #317
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 260
    Points
    1 260
    Par défaut
    Citation Envoyé par zecreator
    Tout à fait d'accord sur le fait que les méthodes d'aujourd'hui brident trop le développeur et sa créativité. On fini par devenir des robots, comme à la grande époque d'IBM, mais en plus coloré.
    Rien ne t'empêche de passer indépendant. Comme ça tu pourras bosser comme tu veux !
    Si les méthodes privaient vraiment le développeur de sa créativité, il n'y aurait plus besoin d'humain dans le cycle de développement.
    Il suffirait de donner l'expression de besoins à un ordinateur, et en suivant une méthode, il pourrait générer le code !
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  18. #318
    Membre éprouvé Avatar de zooro
    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2006
    Messages
    921
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : avril 2006
    Messages : 921
    Points : 1 260
    Points
    1 260
    Par défaut
    Citation Envoyé par Peck777
    je finirai là dessus : PERFORMANCE = OPTIMISATION / MODELISATION
    trop de modélisation tue la modélisation
    Salut
    La modélisation, c'est bien. En abuser, ça craint
    [alkama] quelqu'un est allé voir la guerre des mondes?
    [@Chrisman] j'espère pour spielberg
    --- bashfr.org

  19. #319
    Futur Membre du Club
    Profil pro
    Inscrit en
    septembre 2006
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2006
    Messages : 3
    Points : 6
    Points
    6
    Par défaut Vaste débat
    Au risque de reprendre certaines remarques déjà fournies au sein de ce débat, je suis en effet d'accord sur le fait que cela dépend de la taille de l'application et du nombre de personnes à travailler sur le projet. Pour un programme simple de quelques centaines de lignes, qq soit le langage, le développement peut être fait en programmation spontanée, ce que je fais régulièrement, avec un attachement tout particulier à commenter mes lignes de code (et là on s'y retrouve toujours plus tard...). Cette manière de programmer intuitive demande de la rigueur dans sa manière de penser le programme et quelques années (!) de métier et de connaissance mais elle a l'avantage de ne pas trop perdre de temps à une analyse pas toujours essentielle dans de pareils cas.
    Or pour des projets plus ambitieux, type gestion commerciale ou autre que j'ai l'habitude de développer, ou pour des applications où plusieurs programmeurs doivent intervenir, cela me semble essentielle de préparer le projet en effectuant une analyse précise préalable, en définissant évidemment un cahier des charges, et au besoin des algorithmes détaillés, UML,...etc, non seulement pour soi-même et éviter ainsi de se perdre dans une programmation douteuse, mais également pour les autres intervenants, car chaque programmeur a sa manière de penser et de programmer...
    Développeur indépendant depuis 13 ans et analyste-programmeur depuis 20, j'emploie donc les 2 méthodes, tout dépend du contexte comme je viens de le préciser ; mais il est vrai aussi que le temps est précieux pour tous, et qu'une analyse trop longue peut dissuader le Client d'accepter un projet. Ainsi avec le temps on acquiert une manière de travailler, non pas en baclant une partie du travail loin de là, mais en possèdant des automatismes de pensée et de programmation, mélant rigueur et savoir-faire, pour atteindre le but recherché : que l'application tourne parfaitement, avec un code optimisé, et le faire dans des délais raisonnables.
    L'analogie à la littérature d'une précédente remarque (excuse moi je n'ai plus ton nom en tête) me parait tout à fait bien trouvée. Certains auteurs ont besoin de structurer un récit et passer du temps à tout planifier, alors que d'autres peuvent passer à l'écriture directement, laissant libre cours à leur inspiration. Et dans l'un et l'autre des cas, il y aura des bons et des mauvais romans...
    Salut.

  20. #320
    Membre confirmé
    Avatar de FMaz
    Inscrit en
    mars 2005
    Messages
    643
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 643
    Points : 628
    Points
    628
    Par défaut
    Sans vouloir, par ce message, défendre un partie ou l'autre:

    Je pense que vous différenciez mal la DOCUMENTATION TECHNIQUE et l'ANALYSE DE PRÉ-DEV.

    Une personne qui ne fait aucune analyse prédev, met son truc en prod, puis se barre de la compagnie, s'il à fait une documentation technique adéquate, il ne met en rien l'entreprise dans la merde.

Discussions similaires

  1. Logiciel qui permet de programmer en Fortran ?
    Par lesvacances dans le forum Fortran
    Réponses: 2
    Dernier message: 05/11/2007, 21h53
  2. Tutorial bonne pratique du programmation avec JAVA
    Par menzlitsh dans le forum Langage
    Réponses: 10
    Dernier message: 02/07/2007, 11h56
  3. Script Shell qui lance un programme sur un ordi distant avec SSH
    Par bilibou dans le forum Shell et commandes GNU
    Réponses: 5
    Dernier message: 02/06/2007, 11h18
  4. Erreur qui bloque mon programme
    Par bugland dans le forum Langage
    Réponses: 6
    Dernier message: 21/12/2006, 22h32
  5. Réponses: 19
    Dernier message: 26/12/2005, 01h04

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