Au Pied Levé - À Main Levée
5. LadyWasy
par , 01/04/2022 à 10h30 (694 Affichages)
■ Avant-proposForum -► Général Développement -► Débats sur le développement – Le Best Of
■ ■ ■ SOMMAIRE ■ ■ ■
- Avant-propos
- Accroc du développement
- Rien n'empêche d'être structuré
- C'est à la fin du bal que l'on compte les musiciens
- Méthode "Académique" ou non, on en a AB-SO-LU-MENT rien à faire !
- Conception mentale d’un algorithme
- Trois profils de codeurs
- Certaines idées préconçues ont vraiment la vie dure !
- Documenter : comment, avec quels outils ?
- Deux définitions du terme « spontané »
- Formalisme "conventionnel" ou "personnel"
- Incrédules et obtus !
- L’objectif étant connu, sa structuration mentale est immédiate
- Quelques règles élémentaires
Parmi les adeptes de la programmation spontanée, certains membres se sont particulièrement investis dans cette discussion pour développer leur perception du concept révélé par Doloop.
Ce billet rassemble et met en forme tous les messages de LadyWasy. L’ordre chronologique de ses messages a été respecté. Chaque message est identifié par sa date, son lien vers la discussion et un titre, rappelé dans le sommaire.
Le texte original a été à peine adapté pour en faciliter la lecture.
Les adeptes y retrouveront beaucoup de similitudes avec leur propre expérience, les dissemblances ne tenant qu’à des contextes professionnels différents. L’essentiel est la convergence d’intentions.
Quant-aux détracteurs bornés, leurs diatribes infondées auront eu le mérite de faire parler les adeptes de leur savoir-faire. Les informaticiens sont génétiquement peu communicants. Qu’ils expriment leur ressenti et transmettent pédagogiquement leur talent constitue un témoignage bienvenu de ce qui ne s’enseigne pas dans les salles de cours.
C’est parce que je sens/comprends l'ensemble du programme que je me passe de l'algorithme. Je commence en "structurant" de façon globale mon programme, puis petit à petit je descends dans les détails. En gros je crée mon algorithme avec le langage de programmation que j'utilise.
« Impossible d'appliquer ça sur un gros projet ou sur du travail en équipe ou chacun est chargé d'un morceau du programme ? »
Ben si, j'y arrive aussi (18.000 lignes de code environ, ça m'est déjà arrivé).
Cela dit, ça ne m'empêche pas de bien documenter après (procédures, structure des fichiers utilisés, reprise des annotations et croquis sur mon bloc-notes, etc.). Sinon, je comprends que ça puisse être difficile de comprendre ce que j'ai fait pour ceux qui passent après moi.
Enfin, je suis aussi un accroc du développement.
Rien n'empêche d'être structuré dans ce style de programmation. Tout comme dans la façon "académique" de le faire, si tu ne suis pas certaines règles, tu ne risques pas d'aller bien loin.
En fait, je ne pense pas que le problème soit la façon de faire, de programmer, de développer mais plutôt un problème de rigueur dans le style que tu choisis.
Bien souvent, les mauvais résultats donnés par les "pisseurs de codes" proviennent du fait qu'ils ne connaissent pas, ne se fixent pas, nient ou rejettent la rigueur nécessaire à un développement correct.
Il ne faut donc pas, selon moi, s'enfoncer dans un "absolutisme 100% comme ça" qui n'existe pas.
Personnellement, j'estime avoir la chance d'avoir les facilités qui me permettent de me passer d'un algorithme, mais ça ne m'empêche pas d'être rigoureux dans mon travail et d'obtenir, malgré le scepticisme que je comprends, des résultats appréciés de tous (les utilisateurs, et ceux qui passent derrière moi). C'est tout ce qui compte à mes yeux. C'est à la fin du bal que l'on compte les musiciens, pas vrai ?
Hephaistos007 : « La programmation spontanée c'est pour ceux qui ne savent pas que le développement est un cycle. C'est pour les pisseurs de code quoi ! »
Rien n'empêche d'être structuré dans ce style de programmation. Tout comme dans la façon "académique" de le faire, si tu ne suis pas certaines règles, tu ne risques pas d'aller bien loin.
En fait, je ne pense pas que le problème soit la façon de faire, de programmer, de développer mais plutôt un problème de rigueur dans le style que tu choisis.
J'ai vu des projets abominablement codés et documentés aussi bien chez les "pisseurs de code" (on est d'accord là dessus), que chez les (appelons les comme ça) "Académiques" (si, si je vous le jure, livré à la DGAC par une boite très connue - j'ai peur de fâcher en donnant le nom de l'entreprise. Ne m'en voulez pas si vous travaillez chez eux : GFI), ou à contrario des codes magnifiquement documentés dans les deux camps.
Cela dit, il faut être honnête et reconnaitre que le style "Académique" conduit à un tout (Expression du besoin/Cahier des charges/Code/Documentation/Formation/Maintenance) acceptable plus souvent qu'avec "l'Extreme Programming" (je n'aime pas ce terme, mais bon).
Bien souvent, les mauvais résultats donnés par les "pisseurs de codes" proviennent du fait qu'ils ne connaissent pas, ne se fixent pas, nient ou rejettent la rigueur nécessaire à un développement correct.
Il ne faut donc pas, selon moi, s'enfoncer dans un "absolutisme 100% comme ça" qui n'existe pas.
Personnellement, j'estime avoir la chance d'avoir les facilités qui me permettent de me passer d'un algorithme, mais ça ne m'empêche pas d'être rigoureux dans mon travail et d'obtenir, malgré le scepticisme que je comprends, des résultats appréciés de tous (les utilisateurs, et ceux qui passent derrière moi) ; Et c'est tout ce qui compte à mes yeux. C'est à la fin du bal que l'on compte les musiciens, pas vrai ?
Quelque soit l'ampleur du projet je n'ai absolument aucun mal à raisonner de manière abstraite, à passer par l'une ou l'autre méthode (classique ou spontanée). L'essentiel dans tout développement, c'est :
- Il faut que ça marche,
- Que quelqu'un puisse reprendre le bébé derrière.
Le reste, la méthode "Académique" ou non, on en a AB-SO-LU-MENT rien à faire !
La meilleure des méthodes, c'est celle avec laquelle on arrive le mieux au résultat voulu. Après, affirmer qu'un algorithme est indispensable ce sont des conneries que je laisse aux bien-pensants.
Ce qui est clair, c'est que lorsqu'on conçoit un algorithme, on ne fait ni plus ni moins qu'écrire du code avec son propre "langage de programmation que l'on a inventé tout seul dans sa tête".
L'algorithme était indispensable au temps des cartes perforées, une erreur de codage et c'était la cata, juste un caractère manquant et c'était l'horreur ; mais plus depuis l'apparition des éditeurs de codes et les possibilités de débogage et de traçage qui les accompagnent.
Après, on ne se lance pas forcément à corps perdu dans du code sans trop savoir où l'on va, ni comment on y va, c'est sûr. Mais une idée en tête suffit la plupart du temps.
Lorsqu'on conçoit un algorithme, on ne fait ni plus ni moins qu'écrire du code avec son propre "langage de programmation que l'on a inventé tout seul dans sa tête".
En gros, écrire :
Ça n'apporte rien de plus que de coder directement :
Code : Sélectionner tout - Visualiser dans une fenêtre à part TANT QUE blabla FAIRE blablabla
En fait, ça revient à écrire le code deux fois, de façon différente. Je vous laisse juge de l'utilité de la chose et du temps perdu.
Code : Sélectionner tout - Visualiser dans une fenêtre à part While blala do blablabla
À la relecture du code, pour quelqu'un qui passe derrière, la documentation est indispensable (commentaires, flowchart, description des formats de fichiers, etc.), mais là, ça n'a rien à voir avec un quelconque algorithme.
On ne se lance pas forcément à corps perdu dans du code sans trop savoir où l'on va, ni comment on y va, c'est sûr. Mais une idée en tête suffit la plupart du temps.
Sur internet : http://www.scp.byu.edu/software/idl/ipolster.pro, je suis tombé sur un code écrit en Fortran et qui était la retranscription exacte d'un algorithme :
C'est un code qui est censé calculer l'inverse d'une projection stéréographique polaire.
Pour les novices en la matière, vous avez des coordonnées latitude et longitude pour un point sur la planète et vous désirez par exemple dessiner le pôle sud sur votre écran : vous projetez ce point sur votre carte en effectuant une projection stéréographique polaire qui vous transforme votre couple latitude/longitude en coordonnées X/Y ou en coordonnées R/Theta (au choix).
Le code ci-dessus est censé effectuer la transformation inverse.
C'est un code très sérieux, mis au point par un éminent professeur et est actuellement utilisé pour traiter des données en provenance d'un satellite de la NASA (ERS-1 en l'occurrence).
En le décortiquant, vous vous apercevrez que c'est du flan et que ça ne fait rien du tout !
Au lieu de suivre ce processus :
Algorithme --> codage --> je m'en lave les mains
Le type qui a pondu ça aurait mieux fait de suivre celui-là :
Je code en BASIC direct --> je teste --> si ça marche pas j'affine, sinon, je mets sur internet et à disposition de la NASA.
Le mieux, c'est quand on voit les corrections apportées :
Heureusement qu'il y a relecture et modification, parce que ce code ne marche toujours pas.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
J'ai codé ma propre procédure en Delphi, sans algorithme et je peux vous dire que cela fonctionne à merveille !
Examinons trois profils si vous le voulez bien
- L'artiste (Virtuose pour certains, fou pour d'autres) :
À l'instar de l'artiste-Peintre qui crée sa toile sans avoir fait de croquis avant, certains d'entre nous sont capables d'imaginer l'œuvre finale jusqu'au dernier coup de pinceau avec toutes les étapes intermédiaires globales nécessaires avant même d'avoir commencé, puis ensuite capables, à main levée de réaliser l'œuvre. On sent bien qu'il y a une méthodologie particulière qui consiste à traiter la toile par zones elles mêmes subdivisées en sous-zones etc., un peu comme si nous construisions, par programmation, l'arborescence d'un disque dur.
D’autres personnes sont aussi capables d'écrire un roman d'une traite, en commençant par la conclusion et en terminant par le chapitre du milieu, sans même avoir posé sur une feuille les différentes caractéristiques de leur œuvre : protagonistes, antagonistes, lieux, rencontres, adjuvants, etc.
Ici on touche au personnage qui à "ça" dans le sang, pas forcément le génie, mais celui qui a une facilité et une aisance telle qu'il peut se le permettre. Quand on l'a, c'est dans les tripes, il faut que ça sorte de suite pour être exprimé. Et le résultat, contre toute attente est là, sans coup férir, les ratés sont franchement rares.
Je pense que la spontanéité est là, et qu'il faut considérer et accepter ce genre de "programmation spontanée".
Par contre, l'artiste qui oublie de noter ses "recettes de cuisines" progressera peu dans son art, ses découvertes auront du mal à être comprises si quelqu'un passe derrière pour restaurer sa toile.
- Celui qui ne sait pas encore s'y prendre, l'apprenti à qui on a oublié de dire qu'une méthode pouvait aider ou bien l'obtus (le boulet ?) qui ne veut rien savoir de ceux qui ont acquis l'expérience en croyant qu'il va y arriver tout seul comme un grand.
La "programmation spontanée" du débutant est identique à celle du peintre qui ne maitrise pas les techniques de pinceaux, couteaux, brosses, crayon, fusain, mélange de couleurs et se retrouve rapidement à buter sur un problème technique, au mieux à devoir prendre un temps de réflexion pour aller plus loin, au pire à faire le mauvais choix et à pondre une "croute" comme résultat final.
Le problème en programmation, c'est que rien ne distingue, jusqu'au résultat final, le boulet de l'artiste. Il y en a un qui fait de l'ombre, l'autre se fait fusiller à vue par ceux de la troisième catégorie décriés ci-après, qui le traitent de fou.
Personnellement, je trouve que la spontanéité n'a pas sa place à ce niveau, c'est à dire dans l'illusion ou l'errance.
- Les techniciens, "les gens du métier" :
Et puis il y a celui qui connais ses limites, se sent plus ou moins à l'aise dans la maîtrise de certaines techniques, qui s'il ne sait pas encore comment il va les appliquer, saura qu'il faut utiliser telle ou telle technique plutôt qu'une autre aux vu des circonstances et des problèmes à résoudre.
Ce dernier, déjà échaudé par la méthode précédente, examinera le problème initial sous formes de croquis, validera ses essais, etc. Bref, il forgera son/ses algorithmes sur le papier pour se donner une idée claire du processus de création qu'il choisira. Ce troisième profil est un technicien, pas un artiste (sans être péjoratif).
C'est souvent laborieux mais le résultat est souvent là. Par contre, une démarche trop rigide peut nuire à l'innovation. Il est donc bon, si vous faites partie de ceux-ci, de se réserver des moments "aventureux" et d'exploration de l'inconnu : c'est le coté recherche.
Le problème c'est que certains professionnels n'acceptent pas (ou ne veulent pas accepter) les qualités de l'artiste et considèrent leur méthode comme absolue et unique, parce que celle de l'artiste n'est pas carrée. Grave !
Conclusion :
La "spontanéité" engendre t-elle la médiocrité ? Non, il ne faut pas exagérer. Je suis certain que dans une équipe, un artiste et un technicien en binôme apprendront énormément l'un de l'autre, l'un temporisant les ardeurs de l'autres par exemple, l'autre trouvant une source d'inspiration dans des problèmes qui lui sont difficilement surmontables. Le résultat sera au delà de toute espérance.
Un peu différent mais pas tant que ça :
Il y en a qui ont besoin de suivre des cours pour apprendre une langue étrangère et faire des exercices, réviser leur grammaire, d'autres non, un mois en immersion et c'est acquis. Qu'est-ce qu'un langage de programmation si ce n'est une forme de communication ?
Je me considère comme un artiste qui documente. (Où ça un algorithme ?).
Côté facilités, si j'ai une mémoire désastreuse pour retenir quoi que ce soit, quand ça parle d'informatique, m'expliquer un concept, une idée, une fois suffit pour que je comprenne, que sache l'utiliser, quoi en faire et le retenir par cœur et durablement (je ne peux absolument pas vous expliquer comment je fais, c'est comme ça).
Par exemple, à l'époque du Basic, Pascal, C, Forth, Fortran, Ada, etc. : il me fallait une semaine pour maîtriser un langage de programmation, pas plus. Maintenant, avec les différentes bibliothèques, les API, etc. Bien motivé, j'en ai pour un mois pour maîtriser la bête et en faire à peu près ce que je veux ou ce qu'on me demande d'en faire. Je pense que c'est pas mal.
Et vous ? Vous faites partie de quelle catégorie ?
Un projet de 15.000 lignes de code documenté "au fil de l'eau", ça oui, j'ai fait tout seul : il tourne depuis 7 ans sans planter, sur un parc hétérogène (de Windows 95 à XP en passant par NT4 et Millenium) avec 8 modules différents répartis sur 3 sites distants dans un rayon 50 km et une vingtaine de PC avec SGBDR, communications réseau et serveur intranet.
Je suis tombé sur des obstacles non prévus, c'est sûr, mais le résultat est là : ça marche et les compliments aussi.
L'algorithme, ce qu'il t'apprend, c'est à savoir découper ton problème complexe, en sous-problèmes. Quand tu sais faire, tu t'en passe. Par contre, rien n'empêche de documenter pour quelqu'un qui reprend la "bête" derrière toi, comme il a été dit plus haut, mais je n'ai pas l'impression que tu aies pris la peine de tout lire.
OUI, on peu documenter et expliquer APRÈS avoir codé, et ce n'est pas une hérésie. Ne pas documenter du tout ou mal documenter, là, oui c'est pendable. Et c'est autant l'apanage des développements que certains qualifient de pros (pro en quoi ? parce qu'un illustre bonhomme a dit qu'il fallait faire comme ci et que tout le monde dit Amen comme si c'était l'unique façon valable de faire ?), que des développements spontanés (j'inclue dedans l'extreme programming).
Décidemment, certaines idées préconçues ont vraiment la vie dure !
Envoyé par Hephaistos007 : « Qu'utilises-tu pour documenter et expliquer APRÈS avoir codé ? (c'est une simple question) »
Pour documenter, j’utilise Word, Excel, des outils de dessin (Paint, et un que j'affectionne particulièrement qui s'appelle Grids) pour les outils et en utilisant toutes mes notes de développement comme base de travail.
J'évite les outils qui font tout automatiquement, je n'aime pas trop le résultat.
Ce que j'essaie de faire dans mon développement, c'est de bien séparer certaines catégories : IHM, Traitements, Fonctions utilitaires, Données.
Du coup, au niveau doc, elle sera constituée en 4 parties :
- Des diagrammes de flux sur les interactions utilisateur/traitement (Cliquer sur tel bouton, engendre quel traitement)
- Les Traitements spécifiques de l'application : c'est la partie algorithme.
- Si le traitement est simple (un tri) je n'expliquerais que la procédure/la fonction effectue un tri (de quel genre : Quicksort, tri de shell, par insertion), paramètres en entrées, paramètres ou résultat en sortie.
- Si le traitement est complexe, je me fendrais plus d'un bon diagramme pour "visualiser" le code plutôt que d'un algorithme en pseudo-français.
- Les fonctions utilitaires seront classées par ordre alphabétique avec diverses informations : que fait la fonction, paramètres en entrée, en sortie, exemple de code d'une dizaine de lignes maxi.
- La structure des données : diagramme UML (si base de donnée il y a), description des champs de chaque table/fichier.
Quand je dis après, c'est clair que je ne m'aventure pas à documenter du code que j'ai écrit 6 mois avant.
Ce que je fais, c'est que, lorsque je développe, je code du Lundi au Jeudi, en prenant des notes sur un carnet, et le Vendredi je documente ce que j'ai fait et je classe soigneusement. Comme ça, même trois mois après, je peu revenir sur une "étape" de mon développement.
Et lorsque le projet est terminé, il ne me reste plus que la doc utilisateur à faire, la doc de développement étant déjà rédigée et classée.
Le seul moment ou je réfléchi avant de faire, c'est lorsque je modélise la partie structure de données (Base de données, format de fichiers utilisés).
Bref, j'attache tout de même une grande rigueur à la documentation.
Pour les développements perso à la Maison (pour moi même), je suis un vilain canard, je ne documente pas autant.
D'abord je code à partir d'une idée, d'un schéma que j'ai "en tête", puis lorsque cela me parait convenable et fonctionnel, je documente. En général, "ça marche" du premier coup. Oh, bien sûr, il m'arrive de faire marche arrière, parce que sur telle ou telle portion de code, j'ai trouvé mieux, ou plus clair, ou plus optimisé, ou les utilisateurs m'ont fait part de leur avis dont je tiens compte : continuer coûte que coûte sur une idée fausse ou un modèle erroné, c'est suicidaire.
C'est ce que je reproche à la méthode, "j'écris d'abord sur le papier, et ce qu'il y a sur le papier, je le développe jusqu'au bout, puis je passe ensuite à l'étape suivante, etc." : Pour moi, ça s'appelle foncer la tête droit dans le mur, et à l'arrivée ça donne peut-être quelque chose, mais complètement bancale et inadapté.
À contrario d'autres disciplines (Bâtiment, Aéronautique), en informatique, c'est une réalisation que l'on documente, pas un projet. C'est comme ça que je le vois.
Voilà, voilà !...
Le terme "Spontané" est franchement ambigu :
- Définition 1 : sans idée, même floue, de comment on va aboutir au résultat.
- Définition 2 : sans avoir pris soin, au préalable, d'avoir écrit un algorithme sur le papier.
La première définition est suicidaire, je me demande même si c'est possible de réaliser quelque chose avec ce genre de spontanéité ! La deuxième est, avouons le, franchement plus concevable.
"La programmation spontanée", ce n'est pas développer sans avoir tout planifié ou sans avoir un but précis, c'est impossible de se lancer dans un programme si on n’a pas une idée de ce qu'on veut faire ni même d'aboutir à quelque chose de sérieux si on ne sait pas comment on va s'y prendre, que ce soit déjà écrit sur le papier ou non.
Le programmeur spontané part d'une idée de base. Il visualise l'application finale, son utilisation et éventuellement pense déjà aux technologies qui seront utilisées.
C'est quelqu'un qui n'aime pas être dépendant de méthodes, de contraintes (temps, techniques, etc.) et qui n'applique que les siennes. C'est quelqu'un de créatif, qui possède une bonne expérience des NTIC et est un "touche-à-tout".
Souvent étiqueté de "bidouilleur" ou de "pisseur de code", car ne suivant que très rarement les formalismes du métier, il en est pas moins productif et compétent.
C'est aussi quelqu'un qui rencontre des difficultés à formuler les aspects d'un projet car il lui manque souvent du vocabulaire technique (quelque chose dont il ne trouve que rarement l'utilité).
Voilà ma définition en ce qui concerne la programmation spontanée et le profil que j'ai souvent rencontré par ceux qui la pratique.
Avant de me lancer : La documentation dont je pars, c'est l'expression des besoins, le cahier des charges, le résultat souhaité par les futurs utilisateurs. Mais ça je ne le catalogue pas dans la partie codage du projet.
Quand je me lance :
- Je réalise une maquette dans mon IDE.
Effectivement, je ne pars pas dans le codage sans idées. D'ailleurs, je ne pense pas si, sans idée de comment faire quelque chose, on puisse le faire.
- L'analyse du code et de l'idée qui y a conduit, je la fais "à posteriori".
Les idées peuvent arriver à n'importe quel moment, aussi bien lors d'une étude préliminaire que lors du développement à proprement parler.
Je conçois tout à fait l'utilité des formalismes officiels, pour certains, mais je maintiens qu'ils ne sont pas toujours utiles. Des formalismes, pour un développement "durable", il en faut, certes, mais je ne parle pas forcément des formalismes et méthodes de développement officiellement reconnues : on peut très bien se forger ses propres formalismes et ses propres méthodes. Il n’existe pas UNE méthode universelle.
Pour le travail en équipe, c'est autre chose : dans le formalisme, il faut que tous les intervenants parlent "le même" langage. Dans une petite équipe, cela peut prendre la forme de formalismes "maison", mais pour une équipe de 100 développeurs, le formalisme "officiel" devient une nécessité absolue, même s’il n’est pas toujours ni très souple, ni très adapté.
Je ne suis pas catégorique et en tant que développeur "fou" je saurais toutefois très bien m'adapter. J’utilise aussi des formalismes officiels : c'est souvent utile et indispensable dans ce cas (je n'ai pas dit que ça l'était toujours). Bref je n'ai pas dit qu'il fallait tout mettre à la poubelle, loin de là.
Vous êtes vraiment obtus !
Quand je me lance dans le code, j'ai en général déjà l'idée d'utiliser une chaîne de Markov cachée, une Distance de Levenshtein, un polynôme de tchebitchev, un mappage conforme pour simplifier les calculs dans un autre repère spatial, etc., que ça vous plaise ou non. Les ajustements et optimisations se font en quelques traçages et tests. Bref, j'ai déjà un plan.
Non seulement vous êtes des incrédules mais en plus vous êtes obtus.
Je n'ai jamais dit que c'était sans réfléchir. J'ai dit qu'il n'y avait pas besoin de réfléchir avec du papier, le cerveau suffit.
Avant de passer par le papier, j'espère que ton idée passe par ton cerveau, non ? Après, certains ont besoin de "formaliser" leur réflexion sur le papier, qui leur sert de support pour marquer leurs idées, d'autres non.
Rédiger un minimum de spécificités, on appelle ça le cahier des charges, l'expression des besoins. D'accord ça conditionne le développement mais ce n'est pas ça qui permet de coder. Les spécificités permettent juste de donner un objectif mais elles ne te disent pas comment tu vas l'atteindre.
Dans 98% des cas, à partir du moment où je sais quel est le but que je poursuis, j'ai déjà tout structuré en tête : TOUT. Et je t'assure que ça, je n'ai pas besoin de le coucher sur le papier pour m'y retrouver six mois après. Et je ne dois certainement pas être le seul comme ça.
Après, pour les formalismes, il me semble en avoir déjà parlé si le développement lui-même impliquait une équipe de plusieurs personnes. Pour ce qui est de la documentation, des explications de code et d'algorithme, rien n'empêche de le faire au fil de l'eau, après avoir pissé le code. Je ne vois absolument pas où est le problème.
Sans objectif, on ne développe rien. Si on se lance à développer quelque chose, c'est que l’on a déjà une idée de ce que l’on veut faire.
En général, pour ce qui est de la documentation du code lui même, même si je suis capable de m'y retrouver dans un code sans commentaires, quelque soit le nombre de lignes de celui-ci, même si le code est un peu tordu, je suis tout de même assez pointilleux sur ces quelques règles élémentaires :
- Un nom "parlant" pour chaque variable, procédure/fonction ou objet : au moins, on sait de quoi parle la variable, pas besoin de commenter à quoi elle sert si le nommage à été bien réfléchi.
- sauf pour quelques noms de variables génériques :
- i, j, k et index pour des compteurs entiers (utilisés pour des boucles),
- a, b, c, d pour des coefficients dans une fonction mathématique,
- e ou epsilon pour une tolérance,
- s : pour une chaîne de caractères fourre tout ou temporaire,
- p pour un pointeur fourre tout ou temporaire,
- r pour un réel // // //,
- trouve : pour un booléen indiquant que l'on a trouvé ce que l'on cherchait,
- x, y, z pour des coordonnées 2D/3D ou u, v, pour le résultat d'une projection ou un second système de repère,
- W pour une largeur (Width), H pour une Hauteur,
- Commenter, même succinctement un bloc de codes, en particulier :
- si le bloc représente un algorithme connu, le nom de cet algorithme (exemple : "tri à bulle", "tri de shell", "quicksort",
"projection de Mercator", "distance de Levenshtein"),
- Si la description de la procédure ne tient pas en moins de 3 mots, ou si le nombre de paramètres > 3. Par exemple : pas besoin de commenter ChargeFichier(), on sait à quoi ça sert.
- Éviter les blocs de codes qui font plus d'une page de lecture à l'écran, les subdiviser si possible en sous blocs.
- Séparer le code en plusieurs blocs de codes dons les buts sont différents : Interface utilisateur d'un côté, manipulation des données de fichiers d'un autre, accès aux bases de données dans un autre, bibliothèque d'utilitaires ailleurs, etc. Ça évite de se mélanger les pinceaux et du coup ont sait localiser assez facilement où apporter une évolution ou corriger un bug.
La première chose dont je m'occupe quand je développe, c'est la structure des données (leurs hiérarchies, qu'elles sont elles, les évolutions possibles de cette structure, que ce soit pour un fichier binaire, texte ou une base de données), où les placer sur le disque dur, sous quelle forme.
À partir de là, si cet aspect à été bien réfléchi, 50% du boulot est fait, "y'a plus qu'à...". Personnellement, je me passe de papier pour cette étape, parce qu'il y a toujours des ajustements à faire, mais dans un groupe j’admets qu'un certain formalisme, quitte à reboucler par la suite, est nécessaire pour que tout le monde parte sur la même base solide.
Que la documentation soit faite avant ou après le projet, ce n'est pas la question, le tout est que la documentation soit faite à un moment ou à un autre, et BIEN faite : c'est à dire détaillée et décrivant les fonctionnalités une fois le projet terminé. Même dans des grosses boites où les formalismes officiels sont soit disant de rigueur (je cite carrément GFI ou Cap Gemini), j'ai vu des documentations abominablement scandaleuses à ce niveau. Bref on se fout de la méthode, c'est ce avec quoi vous vous retrouvez entre les mains une fois le projet achevé qui compte : que ce soit fait avec telle ou telle méthode (UML par exemple), on s'en tape, ça doit être du français clair, net, précis, carré, assorti d'un gros schéma mettant en valeur les relations entre les différents fichiers ou tables si nécessaire, avec les noms exacts utilisés dans le code, point final.
Puis c'est la question de comment y accéder (sécurité (login, mot de passe), cryptage, routines de chargement, de sauvegarde, de mise à jour). C'est une phase assez "relax".
Puis les routines qui décrivent l'interaction entre les différentes données, les algorithmes qui les manipulent, les procédures qui permettent au code de l'interface d'y accéder où aux données de renvoyer leur état (événements).
À partir de cette première étape, on peut s'accorder le droit de retoucher les structures de données, sans oublier d'adapter le code de la seconde étape, ni (et surtout) de mettre à jour la doc de la première étape si elle à déjà été faite.
C'est à l'issue de cette seconde étape que je documente ma première étape, cela me permet de prendre du recul par rapport au projet en faisant un break dans le développement proprement dit. Une fois terminé, c'est "peanuts" pour la suite. De là découle l'écriture des classes objets.
À cette étape, je me fais mes propres composants réseau, graphiques, etc. J’évite comme la peste les composants tierce partie, même freeware ou Open-Source (à l'exception de quelques uns que j'ai testés en long en large et en travers). Ca demande du temps, mais on est jamais aussi bien servi que par soi-même : mon expérience me l'a démontré plus d'une fois --> au moins, si bug il y a, on sait d'où ça vient (et d'une). Un composant développé spécifiquement ne comporte pas 10.000 paramètres inutiles (et de deux), si il y a une évolution à faire sur le composant, il n'y a pas de problème de droit d'auteur, de boite qui à coulé, d'abandon de la boite qui l'a développé, etc.
Ah, c'est sûr, ça rallonge le cycle de développement, mais il faut savoir ce qu'on veut : vite fait mal fait, ou béton maison.
L'interface utilisateur est soignée et fignolée en dernier lieu en rebouclant avec les utilisateurs, en leur demandant leur avis (certains préfèrent des gros boutons, d'autres de la couleur, des alertes). L'accent est mis ici sur la facilité de prise en main, pas la peine d'embarrasser l'utilisateur avec une interface où les menus se déroulent au kilomètre : l'utilisateur DOIT pouvoir s'y retrouver sans se plonger dans une doc. Contre exemple dans mon administration : Lotus Notes, belle merde !
Au final, il y a un CD d'installation, une doc utilisateur papier, une doc utilisateur électronique, la doc qui va bien pour reprendre le bébé derrière, les sources, (l'outil de développement qui à servi est conservé précieusement à cet effet), et roule ma poule.
Je vous garantie que cette approche permet un développement "au-fil de l'eau" vraiment efficace. Je ne m'embarrasse effectivement pas de formalismes "officiels", mais j'ai quand même les miens, que je me suis forgé sur ma propre façon d'aborder le développement, ma personnalité, mon tempérament, etc.
Encore une fois, on s'en moque de savoir comment cela à été fait, ce qui compte c'est le résultat non ? TOUT formaliser sur le papier AVANT de se lancer peut en rassurer certains, tout le monde n'en a pas besoin. Moi je n'en ai pas besoin et j'ai une trentaine de logiciels (réseau, système, bases de données, graphismes, cartographie, scientifique, sécurité, etc.) qui tournent sans bugs, sans planter depuis, pour certaines, 12 ans ! Et pour la plus ancienne qui à tourné sur Win95, elle a été testé sur la béta de vista sans anicroche, on l'a juste recompilée avec 2-3 modifications pour avoir un look à la XP : 1 heure de boulot !
Plus ton code est clair moins tu as besoin de documentation, mais de la documentation c'est toujours utile, même si ton code est nickel, il faut l'admettre. (Sans en produire des tonnes inutiles, non plus).
J’ai déjà "lu" comme un bon bouquin des codes sans aucun commentaires mais tellement bien écrits, structurés, etc. que ça a été un régal. Par contre, c'est sûr, tout le monde n'est pas capable de "lire" du code comme ça, il faut aussi penser à eux. Je me souviens d'une époque où certains pestaient contre le C en disant que le code était illisible, vraiment n'importe quoi : ça dépendait surtout de comment c'était structuré au niveau du code.
Le formalisme, c'est une méthodologie, pas un outil de communication :
- pour les équipe > 10 personnes : notations standardisées
- pour les équipe <= 10 personnes : ça dépend si l'équipe est formée de gens qui se connaissent bien ou non. Rien n'empêche d'utiliser des formalismes maison.
- pour un développeur seul : les formalismes "officiels", on n’en a rien à faire. De la rigueur, être méthodique et ça suffit.
La phase conception est inutile mais ne passe pas forcément par le papier.
Par contre, à un moment ou à un autre, exprimer cette conception sur le papier est important : toi tu préfères cette étape avant de coder pour avoir un base documentaire, d'autres comme kisitomomotene ou moi-même préférons l'exprimer d'abord en lignes de code. Ca n'empêche pas de le faire après, ni de le faire bien.
Et arrêtez d'être pointilleux sur chaque mot choisis par chacun parce que je suis absolument sûr de ceci :
- Sur ce fil de discussion, vous êtes (je n’ose pas dire nous, j'ai peur qu'on dise que je me prends pour un génie ou que j'ai les chevilles qui gonflent) tous des développeurs d'excellent niveau.
- Chacun a sa ou ses méthodes de développement qui lui conviennent et conviennent à l'organisation pour laquelle on travaille (sinon on serait déjà chômeurs).
- Nous avons au moins un point en commun : le souci de bien faire (ça c'est important).
- Les formalismes, il en faut, de la doc aussi, mais en ce qui concerne les formalismes, ils peuvent prendre des formes très variées : ça dépend d'un contexte (tout seul, en équipe), de l'expérience et du tempérament de chacun, ils peuvent passer par le papier, pas toujours.
- C'est le résultat qui compte, il faut que ce soit impeccable, pour que n'importe qui, même 20 ans après, puisse reprendre le code sans s'y perdre.
- L'XP en équipe, moi non plus, je n'y crois pas trop. Pourtant mes méthodes s'y apparentent, c'est dire.
Conclusions :
- le problème n'est pas l'utilisation ou non d'un formalisme "officiel" ou non, mais plutôt comment celui-ci est utilisé lors de la programmation : celui qui programme comme un pied, avec ou sans formalisme, avec ou sans phase de conception avant de se jeter dans la programmation proprement dite, n'arrivera à rien du tout.
- le papier est un support de réflexion pour certains, pas pour d'autres : ça n'empêche pas ces derniers de sortir des programmes monstrueux (par le volume de lignes de code et leur complexité), mais pourtant maintenable, évolutifs, etc.
il n'y a pas une façon de faire ou que les méthode officielles : je ne cherche pas à vous faire changer de méthode de développement, mais à vous faire admettre que ce qui n'est pas fait comme vous faites, peut tout aussi bien être valable. Avant qu'UML (par exemple) ne soit un formalisme officiel, était-il pour autant mauvais ?
Consulter le profil
Marquer ce blog comme lu
