Certes, mais sans doc du tout (les commentaires ne remplacent pas une doc. Sinon, autant les mettre dans un document Word...), c'est déjà plus risqué :Envoyé par FMaz
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
Discussion :
Certes, mais sans doc du tout (les commentaires ne remplacent pas une doc. Sinon, autant les mettre dans un document Word...), c'est déjà plus risqué :
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
Bonjour,
Il me semble que l'on y arrive à cet état de fait
A+
Peux-tu développer tes arguments?
les rad par exemple
Bonjour C++
Il faut me renseigner plus en détail!
Mais, certains logiciels (typés automatisme industrielles) semblent apporter des solutions dans cette voie ( à confirmer).
Ce type d'applicatif utilise UML voir des outils propes de création de partie d'application ou fonctions réutilisables.
J'ai bien mis du conditionnel et je dois me renseigner pour plus d'infos.
a++
Oui, mais ce qui requiert de l'intelligence, dans le cycle de développement, c'est la spéc/conception (réflexion pour réaliser les diagrammes UML par exemple), et le développement (pour coder les algos décrits par la spéc de façon adaptée au contexte).
Les outils dont tu parles (par exemple Rational Rose) utilisent les diagrammes de classe pour générer les squelettes des classes, avec les prototypes des fonctions que tu auras préalablement décrits dans les diagrammes. En fait, ils se chargent de la partie "bête" du travail.
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
C'est déjà une avancée.
Entre les FPLA et les outils d'aujourd'hui, il a y un monde d'écart.
Au vue de l'évolution rapide des outils, il est fort à penser que, la partie "bête" du travail étant dévolue à des outils existants, la partie demandant une 'intelligence' particulière soit elle aussi intégrée au fur et à mesure!
Néanmois nous sortont de la question de base de ce fils
A++
Le jour où cela se produira, l'ordinateur sera capable de comprendre le langage naturel, et de faire preuve de créativité. On pourra alors parler de véritable intelligence artificielle ! A mon avis, ce n'est pas pour les années à venir...
Mais comme tu disais, c'est un autre débat.
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
Sans négliger le fait que le langage naturel n'est pas parfait d'un point de vue formel et n'est pas exempt d'ambiguïté... Nous autres humains en savont quelque chose.
FAQ XML
------------
« Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
Giacomo Leopardi
Bonjour,
Ces RAD ne font-ils pas référence aux environements de développement
tels que Builder, Visual, etc ... ?
Justement cela résoud-t-il la question de la programmation spontanée?
Je ne connais pas bien le FLPA, est-ce que cela concerne l'architecture
d'optimisation de consomation pour systèmes portables et embarqués?
Presque d'accord, entre comprendre et faire preuve de créativité, il n'y
a pas forcément de liens.
Pourtant ce doit être ce type de lien qu'on essaye d'établir ici ...
Pensez à un enfant qui fait un dessin imaginaire, comprendra-t-il
forcément le sens de son résultat?
Oui, c'est notre travail que de trancrire d'un langage naturel vers un
langage formel.
Le tout est de savoir si on prend des chemins intermédiaires (UML, XP,
...) ou non (spontané) pour arriver au programme.
Si on y arrive sans chemin intermédiaire, cela voudrait-il dire que seul
l'humain est capable de programmer?
Si non l'autre cas est envisageable...
Effectivement, il n'y a pas forcément de lien.Presque d'accord, entre comprendre et faire preuve de créativité, il n'y a pas forcément de liens.
Pourtant ce doit être ce type de lien qu'on essaye d'établir ici ...
Pensez à un enfant qui fait un dessin imaginaire, comprendra-t-il
forcément le sens de son résultat?
Mais en l'occurrence, dans le cas dont on parle, pour concevoir et développer un logiciel répondant à un besoin exprimé par un non informaticien en langage naturel, il faut d'abord comprendre le besoin, et ensuite imaginer la solution, puis la coder. Pour l'instant (et dans les années à venir non plus, sans doute), aucune machine n'en est capable.
Pour en revenir à ton exemple de l'enfant et du dessin, il n'y a pas forcément un "sens" dans un dessin. Ses traits ne sont peut-être que celà: des traits !
[alkama] quelqu'un est allé voir la guerre des mondes?
[@Chrisman] j'espère pour spielberg
--- bashfr.org
Dans mes études, on m'a toujours dit de tout sortir sur papier, surtout les algorithme.
Alors, la spontannéité est-elle une question de culture ? J'aime à dire que je suis auto didacte, et que par conséquent je n'apprend ou ne fait que ce dont j'ai besoin moi-même pour développer.
L'écriture spontanné je l'ai, c'est comme ca que je programme. Mais par contre, je n'oublie pas après succès de mes développements, d'écrir ce que j'ai fait, commenter, "guider" un développeur qui prendrait ma place.
Pour un développeur, je pense que le plus difficile est d'anticiper l'avenir de ses développements, ainsi je prend ces précautions pour le futur (on ne sait jamais....
Je suis pour la spontannéité des écritures, mais aussi pour la réflexion qui amène à décrire ce que l'on fait, ou qu'on a fait....
Veni Vidi Vici
-------------------------
Mes articles : developpez.com ou bien vbview.net
-------------------------
Et SURTOUT ne pas oublier la bible PHP : --> php_manual_fr.chm!!!
Et aussi : --> pear_manual_fr.chm!!!
Ou encore : --> Les tutoriaux & cours PHP de Développez.com
-------------------------
La différence entre un programme commenté et un programme non commenté est de la même nature que celle pouvant exister entre un homme et un compilateur. Dans la mesure où un homme est capable de lire un programme non commenté comme un livre, il s'apparente à un compilateur, et ce grâce à sa capacité d'abstraction.
C'est de cette capacité d'abstraction que découle la capacité d'un être humain à concevoir des programmes et des algorithmes. Je n'ai pas d'expérience sur les projets vastes, projets d'envergure, mais il est certain que lorsque plusieurs êtres humains travaillent ensemble sur un même logiciel, il est essentiel qu'ils puissent communiquer entre eux afin d'organiser le processus de création de la meilleure manière possible.
Si cette capacité d'entente est supprimée, ce serait comme de faire jouer une équipe de foot composée de joueurs non-voyants.
On peut donner l'exemple de n'importe quelle bibliothèque de fonction. Quiconque voudrait développer une application gtk se doit d'apprendre quelles sont les fonctions dont il dispose, en commençant par les plus basiques pour aller vers les plus spécifiques.
Peut-on imposer à un programmeur de lire l'ensemble du code de la bibliothèque afin qu'il sache comment s'en servir ? Là est toute la question. Je ne pense pas que ce soit la meilleure manière de faire la popularité d'une bibliothèque.
JE découvres que j'ai posté dans ce sujet...
Et en ce moment justement.....
Je suis en train de reprendre une application que j'ai dévellopé...
Pour reprendre l'historique notre application principale est en perpétuel évolution...
Mais c'est davantage par prudence et aujourd'hui les évolutions se font à des intervalles de moins en moins importants... de quelques jours à une certaines époques j'en suis à environs 1 an sur les dernières...
Toutefois une des grosses évolutions historiques a été le passage d'une application tournant en local sur un PC, à une application réseau avec des Sockets et effectuant des sauvegarde sur le serveur de fichiers de la boite tous les soirs.
Un jour, on m'a demandé de fournir notre programme pour une installation dans des SAV... J'ai répondu, voici la version d'il y a un an c'est la meilleure pour une utilisation non réseau (tous les SAV n'avaient pas le réseau)
Depuis les deux applications ont évolués chacune de leur coté avec quelques évolutions communes.
Au bout de quelques mois, il est devenu nécessaire, qu'une modification ou évolution soit universelle, c'est à dire dans les deux applications... Dés lors les dévellopements et évolutions ont commencés à se faire avec des fiches communes. Mais ces dévellopement se sont fait dans ce que j'apelles "boîte vide", la fiche principale n'était pas la même et c'est elle qui effectues % du boulot...
Alors dernièrement j'ai fait le point sur ce qui nous empêchait d'avoluer plus loin dans la fusion des deux versions du logiciel... J'ai fait des propositions sur ce qui me semblait délicats... Et j'ai eu le feu vert...
Et bien c'est typiquement dans ce sujet!
Un certains nombre d'évolutions se sont fait en programmation spontannées... Alors aujourd'hui, je dois faire le boulot que j'avais remis à plus tard: mettre sur le papier les différentes fonctionnalité/ leur rôle et leur ordonnancement...
tous les échanges par sockets doivent pouvoir être traités sans connection socket dans certains SAV...
Et bien il y a du boulot!!!
En clair: comme certains l'on déjà dit, la programmation spontannée, c'est bien (sur le coup), c'est rapide, Il y a "souvent" des résultats "rapides" mais quand il faut reprendre ou réintervenir ultérieurement.... Bonjour!
Mattetfamilly.
on aura tout vu...
Mais où est-ce???...
------------------------------------------------------
n'oublies pas les balises [code ][/code ]
et le Tag
Sur un petit projet PERSONNEL (j'insiste) la programmation spontannée est parfois plus sympa qu'un développement dans les règles de l'art... Quitte à galérer et à faire du code sale... Mais passe encore...
Pour un gros projet, plus compliqué, et impérativement lorsqu'on travaille en équipe ou que quelqu'un d'autre devra reprendre le projet, il est indispensable de développer proprement l'application et de rédiger correctement les dossiers d'analyse, conception, et tout ce qui s'ensuit...
Je programmais à l'arrache avant... Maintenant je fais le plus rigoureusement possible mes diagrammes de classes, puis diagrammes de séquence système puis détaillés pour aboutir à mes classes participantes... le programme se code tout seul et je peux revenir sur le logiciel un an après je saurais ce que j'ai fait et pourquoi...
J'applique la "programmation spontanée" pour mettre au point des petites
fonctions ou des méthodes.
Mais en aucun cas sur un projet entier.
j'ai un peu l'impression que ce debat tient plus d'un topic de presentation de chacun et de sa facon de travailler qu'un reel echange d'arguments.
Pour ma part, n'ayant que peu d'experience en programmation professionnel (3 ans) mais une dizaine d'annees en projets personnels, je soutiens totalement le parti qui defend une bonne documentation. Pourtant, de la programmation spontannee, j'en ai fais des tas et j'en fais encore pour des trucs evidents. Mais lorsque j'ai compris en entreprise que les magnifiques codes que je leur pond seront jetes si personne d'autre ne les comprend lorsque je pars, j'ai, par orgueil, tout fait pour m'assurer que mon code sera repris apres moi. Et en meme temps, j'ai appris que l'UML m'evite de pondre un livre de 500kg de litterature et j'ai pris gout a la modelisation. Comme quoi, l'orgueil peut servir.
Bref, maintenant, je modelise plus par plaisir que par necessite (sans pour autant tomber dans la modelite aigue. des bouts de code sans subtilite ne meritent qu'un minimum de doc).
Mais comme j'ai vu quelque part sur le net un conseil pour l'open-source: meme pour le plus petit et jetable bout de code, codez le bien. Car ca vous donne l'occasion de faire un exercice de style et ca vous donne l'habitude de bien coder. Et pour moi, un bon bout de code est un bout de code qui reste, qu'on ne jette pas apres 2 ans.
PS:desole pour les accents. je n'ai qu'un clavier US.
Tout récemment inscrit sur le forum de Developpez.com, je me suis fait "accrocher" par ce sujet, " Qui pratique la programmation spontanée ?". Je reconnais qu'il m'a fallu deux jours pour tout ingérer, la multiplicité des interventions rendant de temps en temps confus le sujet initial. Mais par contre, celui qui a initié ce sujet me semble être soit un peu décalé quoi que je pense plutôt qu'il affabule ses compétences qu'autre chose.
Je n'ai pas les compétences de la plupart d'entre vous, n'ayant mon diplôme de développeur informatique que depuis octobre 2007 (via l'AFPA, un an de formation).
Mon expérience professionnelle est tout autre, le domaine de la comptabilité. Chef-comptable durant quinze ans (j'ai travaillé aussi bien en groupes - Air Liquide par exemple, DAMART - ou PME de moins de 50 salariés), j'ai toujours été attiré par la programmation. Il y a 5 ans, j'ai franchi le pas en achetant la licence C++. Errreur fatale pour un débutant, m'en suis rendu compte relativement vite.
Bénéficiant (si on peut dire) de la fermeture de la société qui m'employait, j'ai pu obtenir la possibilité d'apprendre la programmation, avec cette formation diplômante.
Et maintenant, un an après avoir obtenu mon diplôme, tout en travaillant maintenant comme consultant en entreprise dans le domaine de la gestion/management (entre autre), ces nouvelles compétences informatiques m'apportent un réel plus dans mon métier.
Mais je vais en venir au sujet de ce thread, c'était le plus de cette précédente disgression.
Moi-même (en tant que débutant dans le domaine de la programmation), je peux implémenter de maniére "spontanée". Mais ce n'est qu'un moment d'illumination, qui se répétera sans cesse tout au long des différentes phases du projet en développement.
Ce qui important (et c'est ce que j'en ai tiré de bénéfique de ma formation), c'est de préparer son travail, ce qui a été répété à juste titre plusieurs fois précédemment. Sans cahier des charges réalisé, on va droit au mur, c'est l'évidence même. Surtout quand il faut faire survivre le produit fini, le maintenir et aussi le faire évoluer. Car les coûts initiaux sont tels qu'il est inenvisageable pour un décideur de se dire : "dans deux ans, on change tout et on prend un nouveau produit".
Combien de fois dans ma carriére de chef-comptable j'ai été en rapport avec des SSII que nous pressentions pour développer un logiciel-maison ? Et combien de fois une trop vite étude préalable (donc baclée) a fait que lors de la conception même du produit des retards importants sont apparus.
C'est pour ces évidences qu'il est indispensable de bien préparer son analyse, du moins dans les grandes lignes (ne pas non plus passer un an à le peaufiner en théorie), pour ensuite commencer module par module à créer un premier programme de base qui sera l'ossature du définitif.
Bien entendu, certains pourront me rétorquer (à juste titre) que je n'ai jamais travaillé en SSII. Mon inexpérience en tant que programmeur (je ne fais que des petits programmes personnels) peut aussi jouer contre moi dans mon raisonnement.
Mais je mets en contre le fait que pendant mes quinze années de chef-comptable, il m'est arrivé plus d'une fois de devoir travailler comme le "candide" pour des informaticiens chevronnés - qui pour un nouveau logiciel - qui pour une maintenance ou refonte d'un logiciel interne existant. Donc, j'ai la casquette du client, tout en ayant maintenant (en théorie), la casquette du fournisseur.
Programmation spontanée, oui, à tout moment pendant la phase de l'implémentation, quand on crée le squelette (en fonction de l'analyse pertinente faite précédemment, ce sacré algorithme). Mais pouvoir faire une application compléte - du genre par exemple la gestion des clients d'une société de retraite - d'un coup d'un seul sans poser les bases sur le papier de où on veut aller - comment on veut y aller - avec qui on veut y aller, c'est de l'utopie.
Bref, pour conclure ce qui n'est qu'un avis de débutant, il faut toujours penser à ceux qui vont suivre derriére. Dans ma formation d'un an, j'ai eu un stage en entreprise d'un mois. Le chef de projet de la société m'a sorti un listing énorme, avec du code, du code, du code. Aucun commentaires, rien, même pas un petit dossier présentant le produit. Il a été relativement gêné en me passant ce truc et il m'a dit : "C'est pour vous faire une idée de ce qu'on peut défois récupérer comme travail à faire.". Et en fin de compte, je regrette pas, car j'ai appris pas mal par cette expérience.
Tous mes futurs développements seront étayés par une documentation (succinte sûrement) et des commentaires idoines dans le code même. Déjà rien que pour moi si je dois y retourner quelques mois après l'avoir terminé.
la doc, c'est tres bien. la doc normalisee, c'est encore mieux. Sun a eu la brilliante idee d'avoir developpe l'outil javadoc pour java car tout le monde de java l'utilise, et je tente de trouver pareil pour les autres langages que j'utilise.
Toujours interessant d'avoir un point de vue de l'autre coté de la lorgnette.
En ce qui me concerne, je dirais qu'il y a 2 parties dans un code :
1)les entrées-sorties
2)la patée codistique(au milieu de laquelle sont noyées les entrées-sorties, si vôtre code n'est pas impeccable).
Quand on est un tant soit peu doué, il est facile de faire rapidement une patée codistique compléte, efficace, lisible et maintenable. En bref : un code propre, agréable à lire, et compréhensible même par un type qui ne devrait pas faire ce job. En pure programmation spontanée. En ce qui me concerne, je dessine quand même quelques schémas, mais point trop n'en faut.
Pour ce qui est des entrées-sorties, je suis nettement plus circonspect. Si vous êtes spontané, alors les gens qui vont vous appeler - ou que vous allez appeler - vont vite être en décalage. Et les emm****ts commencent.
Par entrée-sortie, je cite tout ce qui entre et sort du code : fichiers, bases, données transactionelles tapées par l'utilisateur, etc..... Dès que l'on ne bosse plus seul(et même si on bosse seul, dans certains cas), une documentation est obligatoire pour gérer ces trucs-là. D'ailleurs, si un jour j'ai assez d'energie pour me lancer dans un projet personnel, j'éssaierai de me mettre à UML(là ou je bosse, y connaissent pas). Pour cette partie là. Pour le code à l'interieur, je sais faire propre et net tout seul, merci(même si d'autres préfèreront une approche plus adaptée à leur style).
J'ajouterais à celà qu'àprès 7 ans d'expérience, mon dada est de faire un code qui se lise au maximum comme la spec. Ca facilite grandement la relecture et les évolutions. Si les types font des specs comme un grand texte, je code pareil(avec juste des modules pour les trucs qui n'apparaissent pas dans les specs, comme l'implicite ou la technique). Si ils font un tas de petits pavés, mon code sera plein de petits pavés.
Après, il ne faut PAS oublier de emttre tout ce qui est commun dans des modules spécialisés(l'euro, la TVA, les calculs d'arrondis), sans quoi il ne sert pas à grand chose de faire de l'informatique
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager