Je suis quasiment certain que même mis en page plus simplement ce code resterait obscur !du commentaire pas necessairement, de la mise en page ( espace, saut de ligne ) plus surement
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 :
Je suis quasiment certain que même mis en page plus simplement ce code resterait obscur !du commentaire pas necessairement, de la mise en page ( espace, saut de ligne ) plus surement
Il est surtout obscur du fait du nommage des variables et de l'utilisation d'astuces CEnvoyé par pgibone
Nous sommes donc d'accord : un code mal formé, mal nommé, mal commenté est inutilisable en entreprise, où l'on a toujours besoin de maintenir le code parce que les spécifications évoluent.Il est surtout obscur du fait du nommage des variables et de l'utilisation d'astuces C
Au risque de choquer beaucoup de gens je suis même un adversaire de l'astuce (je crois que cedricgirard aussi), car une astuce n'est que l'exploitation, éventuellement intelligente, d'une situation à un instant précis au détriment de la nature profonde des objets et de leurs relations. Il est facile de prendre le contre pied de ce que je viens de dire, parce que la frontière entre "nature profonde" et "situation a un instant précis" est fluctuante. Et puis l'astuce est satisfaisante, on se sent tellement malin quand on en trouve une (moi aussi).
Je suis de la génération qui a dû utiliser en permanence des astuces, soit pour économiser des octets (XOR AX, AX à la place de MOV AX, 0 par exemple) soit pour économiser du temps de traitement (écrire 16 fois les mêmes 15 lignes de codes à la place d'une boucle, parce les tests et les sauts prennent trop de temps), nous étions contraints d'utiliser des astuces, maintenant que ce n'est plus le cas on peut se permettre de penser à la vie du logiciel qui ne s'arrête pas le jour de la livraison
Je pense en effet que les astuces sont bonnes pour les envirronements qui en ont besoin, mais en dehors pas vraiment utiles. La clarté est plus importante que le millioneme de seconde économisé.
oui, maintenant, "l'astuce" pour gagner du temps se positionne plus au niveau de l'optimisation d'algorithme complexes et lourd qu'au niveau de l'astuce de programmation.
Après, en ce qui concerne des applications nécéssitant des calculs temps réels (je pense aux jeux), là l'utilisation d'astuces de programmation peut être necessaire. Néanmoins, les moteurs graphiques sont en général des gros monolithes de code très difficile à maintenir car il a été optimisé de tous les cotés...
Je dirais que le véritable gain de temps sur les algos lourds vient d'une refonte meilleure de l'algo que sur des optimisations locales. Souvent quand c'est lent c'est que l'algo est mauvais.
Le cycle en V est descendu en flammes au profit de l'X programming. Soit.
Mais il éxiste d'autres cycles de vie adapter au fait que souvent les spécifications de départ sont incomplètes : cycle en spirale, cycle itératif (succession de petits cycles en V).
J'ai personnellement utiliser le cycle itératif sur un projet ou on ne savait pas trop où on allait, de petits cycles en V de 1 à 3 mois : on garde la maîtrise de l'architecture, les spécifications d'interfaces et logicielles sont à jour, on avance pas à pas. Avec une bonne gestion de configuration, he trouve ce cycle très bien adapté au "on verra après si c'est possible".
Pas descendu en flamme, simplement XP propose autre chose et argumente sur l'interet de l'alternative. XP prone de fait un cycle itératif court (une à deux semaines), et XP ne revendique pas d'avoir inventé des pratiques.
Les cycles itératifs sont bien connus, on fait du TDD dans les années 50. Simplement de les avoir assemblé en un tout cohérent et d'amener une vision du développeur comme un artisan, et non pas un ouvrier.
Je suis tout à fait partisan de la vision programmeur = artisan, et même artiste parfois, au sens où un joueur d'échec peut être un artiste ; c'est tout à fait évident quand on peut reconnaître le code d'un programmeur comme on peut reconnaître un joueur rien qu'en regardant une partie (ce qui n'arrive jamais avec les petits joueurs (pas d'offense, je suis un nano-joueur d'échec)).
C'est pas faux: un bon joueur d'echec possède une très bonne méthodologie ainsi qu'une vue stratégique de sa partie : un plan, qu'il décompose en autant de sous-problèmes qu'il y a de phases de jeux.
Ceci dit, la comparaison s'arrête là : aux echecs, on ne peut pas faire marche arrière, si on voit que l'on se trompe, ce qui devrait toujours être le cas en informatique!
Je ne suis pas d'accord, le programmeur est plus proche de l'ouvrier. En entreprise on ne lui demande pas de "laisser sa trace" mais de programmer.
Je préfère qu'un programmeur s'y retrouve dans n'importe quel code (normalisation, structuration, dictionnaire de données etc...) plutôt que reconnaitre un programmeur en ouvrant un code.
Les astuces et autres ruses de sioux, même si elles peuvent faire plaisir au développeur lors de la programmation, ce ne sont que des futurs pièges. Elles sont à proscrire en entreprise.
Pour ma part, j'assimile programmation spontannée avec programme jetable (à usage unique même). Ca peut arriver en entreprise mais c'est l'exception.
Bien sûr, je parle là du boulot, car à la maison faire un script Perl de la mort pour tracer, sniffer, browser les malotrus qui osent s'approcher du firewall... ahhhh ca fait du bien
Et une coding partie ca défoule
JefdeBourges
Je ne vois pas la contradiction !En entreprise on ne lui demande pas de "laisser sa trace" mais de programmer.
ditoJe préfère qu'un programmeur s'y retrouve dans n'importe quel code (normalisation, structuration, dictionnaire de données etc...) plutôt que reconnaitre un programmeur en ouvrant un code.
C'est exactement ce que j'ai dit, et n'est en aucun cas incompatible avec une vision artisan/joueur d'échec de ce métierLes astuces et autres ruses de sioux, même si elles peuvent faire plaisir au développeur lors de la programmation, ce ne sont que des futurs pièges. Elles sont à proscrire en entreprise.
Comme tout le monde y va de son avis, pourquoi pas moi !
Je dirais juste que je pense que l'on doit adapter la façon de programmer à l'activité, au besoin, à la taille de projet. Exemple :
1) Un gros projet en entreprise, avec un cahier des charges (evoluant), et plusieurs developpeurs : il faut etre tres structuré, coder les fonctions deja predefinies dans l'analyse, avoir des jeux de tests, des commentaires... Enfin le plus propre possible, disons de façon tres scolaire dans le bon sens de terme.
2) un mini programme (à usage interne par exemple) devant servir rapidement et ayant un fonctionnalité tres precise, comme par exemple transformer un document au format A --> format B. Ici on peut se lancer dans la programmation directement.
3) Celui que je connais un peu plus : faire des programmes où l'on connait vaguement (voir tres vaguement) le cahier des charges, comme dans la recherche. Les desiderata des scientifiques sont tres evolutif (de part leur facon de penser et des evolutions techniques et scientifiques). C'est pourquoi la plupart des progs liés à la recherche que j'ai vu, sont un empillage de morceaux differents (souvent en fortran), tenant comme un chateau de cartes... mais tenant quand meme. Mais apres pour aller toucher une carte, faut s'accrocher pour pas faire tout tomber.
Pour le point 3, meme en y mettant de la bonne volonté, comme ces programmes sont maintenus pendant 10 ou 20 ans, ils ont été ecrit par plusieurs personnes en ADA, puis traduit par plusieurs personnes en Fortran, puis retraduit et modifé en C... Ici le contexte de developpement fait qu'il y a une difference entre la theorie et la pratique.
Bon quand à moi je retourne à mes jeux de tests.
pas complétement d'accord, meme un gros projet en entreprise n'est pas borné et l'analyse initiale de résoud rien; d'accord sur le fait qu'il faut une méthode pour orienter la collaboration
Je dirais plutot : un programme qui va tourner un mois et on jette : on peut se passer de techniques et de sécurités; un programme même minuscule mais qui doit rester à son poste et évoluer longtemps, alors il faut des jeux de tests, une analyse minimum, etc...
pas sur, on a le cas de projets tres evolutifs qui restent parfaitement stables et strucurés, mais à condition que tout le monde s'attache à respecter qq regles. C'est le coeur de cible d'Extreme programming, les projets qui passent leur temps à bouger. Mais les projets ont ces projets qq soit le domaine, pas que dans la recherche.
Ca, ya pas de doute que les jeux de tests sont la meilleure maniere de diriger le projet vers la bonne voie, mais il faut avoir le temps de les faire si on les fait après le code, alors autant les faire avant
la programmation spontannée est liée aussi à une génération : ceux qui ont commencé dans les années 80 sur des z80 parcequ'on ne pouvait faire que cela ...
c'est une excellente méthode pour tester un concept une méthode une classe, etc ... ou pour du fun... Mais dans le cadre professionnel, si c'est encore fait c'est souvent un risque majeur ... Sauf à avoir des outils costauds et une méthode parfaite ... En final je suis totalement contre dans un cadre pro ... sauf si on aime ajouter des correctifs spontannées à des softs spontannées, et finir par plus pouvoir facturer (sauf l'avocat) ...
Un excellent livre "programmation professionnelle" argument de manière scientifique sur le sujet
A+
Jérôme FORTIAS
ma fois la programmation spontanné existe est cela est un faite...
en gros tu fait l'algorithme dans ta tête et tu tappe sur ton clavier.
seulement voilà imagine que tu veulent explique ton programme a une personne qui n'y comprend rien en informatique !
comment va tu faire, puisque après avoir codé tu a vidé l'algorithme qui était dans tête n'étant plus util vu que ton programme fonctionne.
c'est le principale problème de la programmation spontanné, cela ne passera pas en milieu proffessionnel je vais dire a l'emboche, bien que cela fasse toujours sourire,
dans un projet cela ne passera pas non plus.
! faut mettre sur le papier l'algorithme que tu a dans la tête
d'un point de vu personnel on poura toujours retrouver l'algorithme de celui qui a fait de la programmation spontanné en lisant le code.
la logique qui veut que l'on réfléchise avant de faire une action et là même que celle qui veut qu'on fasse des algorithmes (voir des cahier des charge pour un projet) avant de coder.
si tu n'avait pas pensé avant a vouloir faire un feu tu n'irait pas chercher du bois....
tu vera que mettre tes pensée sur le papier, mettre le raisonnement que tu a avant de faire le programme t'aportera beaucoup plus de rapidité que tu ne peut l'imaginer, et cela sera très aprécier par ton entourage.
La programmation spontanée c'est bien en dessous de 100 lignes de code. Au dessous tu t'embrouille.
Le 3e commandement du programmeur :
A méditer...Jamais un papier et un crayon tu n'oublieras
En mathématiques, avant de commencer à chercher une solution, on démontre qu'il existe une solution. C'est quelque chose que beaucoup d'étudiants considèrent inutile je pense.
De la même façon, en prog, avant de coder quoique ce soit du même genre que mon histoire de maths, la moindre des choses serait d'étudier si oui ou non ça vaut le coup de se lancer dans la conception d'un algo de ce genre.
L'intuition ne remplacera jamais une vraie reflexion.
Pas faux, seulement les maths sont un univer limité, propre, absolu, ce que n'est pas la programmation. En math on peut avoir la certitude qu'il existe ou non une solution, en prog jamais dans un cas réel.
Je ne suis pas spécialement pour la "programmation spontannée" mais je pense que parfois pour vérifier un truc, il est plus réaliste de le tester sur un programme qui sera jeté après, que de se dire que en théorie peut être et si on a pas fait d'erreur cela doit se faire.
Les entreprises sont pleines de projets qui sur le papier étaient parfaits, mais qui n'ont jamais fait qu'engloutir de l'argent parce que le calcul initial était faux. Et il était faux parce qu'il n'est pas possible de tout prendre en compte, comme cela est possible en math.
Programmation spontanée
DOLOOP a écrit, et je cite...
Je souhaiterai savoir s'il y a beaucoup de personne qui programme de manière spontanée comme moi.
J'ai déjà posé des questions à des personnes du domaine et ce n'était pas le cas pour eux. Cependant sur ce forum et d'autre, il y a des posts qui me semble confirmer que oui.
La question de Doloop ainsi que les réponses apportées par les divers intervenants sont très intéressantes.
Je suis en partie d'accord sur le fait que l'on ne soit pas obligé de passer par des cahiers de charges volumineux ou des organigrammes fastidieux pour pouvoir programmer sous Visual Basic.
Mais quel est l'enjeu final ?
Si la finalité est de réaliser des applications pour se faire plaisir comme s'est mon cas, je ne pense pas que cela soit indispensable.
Par contre, la ou je ne suis pas d'accord c'est de négliger les commentaires sous prétexte que le compilateur n'en tient pas compte.
Il m'arrive souvent de commencer une application, qui reste en souffrance pour diverses raisons et que je reprends après plusieurs jours(mois) avec la satisfaction de comprendre ce que j'ai voulu réaliser grâce aux nombreux commentaires que je dispense à profusion.
Visual Basic est un jeu de mécano et l'on peut récupérer des instructions ou fonctions déjà écrites dans d'autres programmes, ce qui facilite grandement l'écriture du code. (on ne réinvente pas la roue)
Avec l'évolution ainsi que l'expérience acquise au fur des années on constate que l'on écrit parfois différemment certaine routines.
J'ai commencé avec GWBasic et je suis passé au Visual Basic 3.0, lorsque j'ai décidé de' évoluer et de passer à VB6.0 j'ai gardé (peut être un peu par flaimardise) certaines instructions de VB3.0 tout simplement parce que
je me suis rendu compte que VB6 les prenaient en charge sans problème.
De temps en temps j'utilise les nouvelles instructions de VB6.0 (j'évolue)
Je ne me catalogue pas comme étant un programmeur, puisque mes études ainsi que mon parcours professionnel a été orienté dans l'ingiénérie électronique et je suis venu à l'informatique par vocation.
Tous les programmes que je réalise(à part quelques exceptions) sont écrits de manière spontanée, désolé de vous décevoir, mais c'est la vérité.
Je suis en train d'écrire un programme de gestion d'une brocante. Tout simplement parce que j'organise une brocante chaque année et que j'en ai marre de faire manuellement toujours la même chose.
Disponibilité courant 2005
Mais rassurez vous, je ne travaille que pour moi, je n'ai pas de contrainte et mes programmes ne sont pas à la vente(sauf un) mais je n'en ai vendu que trois ou quatre, et je n'attend pas après ça pour vivre.
Je tenais à donner mon point de vue, sans aucun esprit de polémique, chacun fais ce qu'il veut ou ce qu'il peut, mais le débat est sympathique et puis la critique n'est elle pas nécessaire lorsqu'elle est constructive ?
Bien cordialement à tous
Gilmir
Répondre avec citation
Partager