Envoyé par SimonDecoline
Wouahooo... Autant de mauvaise foi requiert généralement d'invoquer la mauvaise période du mois pour l'excuser.
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 :
Wouahooo... Autant de mauvaise foi requiert généralement d'invoquer la mauvaise période du mois pour l'excuser.
Je dois avouer que j'ai rarement lu un tel ramassis de connerie. Je trouve ça profondément inquiétant que tu puisses être développeur et que tu travailles éventuellement en équipe. L'exemple que tu prends fait 3 lignes et n'importe qui peut comprendre ce qu'il fait en un coup d'oeil. On ne parle pas d'un petit projet de quelques milliers de lignes là quand même, et même si ce n'est pas le cas, avoir des explications et de la documentation ça n'a jamais tué et ça fait toujours plaisir. D'ailleurs :
Mention spéciale là ! Tu es vraiment le genre de développeurs que j'exécre par-dessus tout. Va faire un tour dans n'importe quel gros projet et reviens me dire ça qu'on rigole un peu. Le code c'est la doc est sans doute le pire comportement qu'on puisse avoir et démontre un manque certain d'expérience de travail en équipe.Pour les commentaires... si ton code en a besoin, c'est qu'il n'est pas propre. Ton code doit être explicite sans avoir besoin de commentaires pour sa compréhension, sauf points très particuliers un peu tricky.
A la limite, c'est juste un retournement d'argumentaire utilisé par les "anti-java" qui en critique la "verbosité" et en font son principal (unique ?) défaut.
Moi au moins mon code est lisible et compréhensible au premier coup d’œil...
Et je trouve vraiment inquiétant que tu considères que la base pour écrire du code lisible soit un ramassis de connerie... je plains ceux qui reprendront ton code...
J'espère bien que tes fonctions font moins de quelques milliers de lignes ! Parce que là ça serait vraiment inquiétant !
Oui, l'exemple fait 3 lignes, c'est un exemple. De manière générale, tes fonctions doivent rester courtes.
Mais il n'empêche que l'exemple est parlant, dès que tu te tape des lignes à rallonges ça devient incompréhensible.
J'ai eu un collègue qui faisait une opération très simple, vraiment simple, une simple addition de deux éléments de deux tableaux du type : t1[k1][k2] = t2[k3][k4] + t3[k5][k6]. Avec bien évidemment des noms de variables très explicites à rallonge...
Je mettrais quiconque au défi de comprendre ce qu'il a écrit tellement c'est illisible, avec des noms de variables très proches et des gros blocs de codes qui prennent tout l'écran... Cela prend un temps fou rien que pour comprendre ce qu'il additionne.
Impossible de réécrire son code (de 30 lignes à peine), parce qu'on y pige que dalle. J'ai du faire un refactoring étape par étape en renommant les variables petit à petit, en factorisant quelques bouts de codes.
Ah pour être explicite, c'est explicite, tellement explicite qu'on y comprenait rien.
Si t'as besoin de commenter ton code, c'est que ton code c'est de la merde. Va te payer des commentaires obsolètes ou erronés... tu verras comme tu rigoleras... tu repasseras ton temps à relire le corps des méthodes pour savoir ce que fait réellement la fonction... en ignorant les commentaires qui seront inutile et qu'une perte de temps, pire nuisant à la qualité du code...
D'ailleurs, c'est assez révélateur de ton niveau... tu ne fait pas la différence entre documentation et commentaires...
La documentation, c'est bien plus que des commentaires... Tes diagrammes de classes et autres, c'est pas des commentaires... et tu peux les générer automatiquement, ou pire récupérer ceux que tu as fait lors de la conception. Et déjà si t’arrive à bien structurer ton code, rien que l'arborescence des fichiers, t'aide déjà à comprendre l'architecture du code, c'est sûr que si tu mets tout dans le même fichier ou dossier, t'es pas prêt de t'y retrouver...
Lorsque tu génères la doc, la description de la fonction ne fait que 95% du temps paraphraser la signature de la fonction... Dans les 5% restant, ouais, tu peux rajouter quelques commentaires pour préciser des points de nuances comme je l'ai précisé dans ma réponse.
Pour le reste, t'as les tests unitaires, et des tests de recettes, qui permettent de se faire une idée de la manière dont ton code doit être utilisé.
Et sinon, comme je l'ai dit, tu peux ajouter de la doc sur tes API publiques figées, e.g. avec des exemples. Mais si tu t'amuses à mettre à jour tes exemples au moindre commit... t'es pas prêt de t'en sortir...
Tu es le pire genre de développeur quand il faut reprendre son code. Ah oui, du code très scolaire, des commentaires parfois à chaque lignes (merci, mais je sais encore lire du code)... mais aucun effort sur la qualité du code, des copié/collé un peu partout, des optimisations inutiles et illisibles, des fonctions à rallonge, etc. etc. a mais au moins on a les commentaires... tellement bien écrit qu'on se retrouve à devoir tout réécrire from scratch...
Passe donc le temps que tu perds à écrire et maintenir tes commentaires, à améliorer la qualité du code... tu verras ce qui sera plus simple à reprendre...
Et si maintenir les commentaire ça "tue", ça prend un temps fou, et ce temps on l'a pas parce qu'on te demande des chose aujourd'hui pour hier.
En principe il faudrait écrire des tests unitaires au lieu d'écrire des commentaires.
Parfois on modifie une fonction et on oublie de mettre à jour le commentaire, alors qu'on oublie pas de mettre à jour le test unitaire puisqu'il ne va pas passer.
Il y a des histoires d'intégration continue, quand quelqu'un commit son code, le projet est reconstruit et testé et si un test échoue ça se voit.
Keith Flint 1969 - 2019
Le whitesllist/ blacklist vient d'une opposition ombre/lumière.
On voit ce qui est a la lumière, on ne voit pas ce qui est dans le noir .
Si des personne voit une quelconque référence à une couleur de peau, oui ça me gène car c'est profondément raciste.
Pour le terme maitre / esclave , c'est comme ci changer le terme mettrais fin à ce principe.
Le principe d'esclavage a toujours existé et (hélas) existera toujours (il suffit de voir l'esclavage moderne avec le principe de stage non rémunéré <_< ).
Non, juste non.
Mettre au même niveau les stages non-rémunérés de 1 mois avec l'esclavage, c'est juste indécent.
En plus même pas moyen de faire aller chercher le café au stagiaire ><, à se demander à quoi ils servent?
Pour rappel, l'esclavage existe toujours bel et bien de nos jours. Pas besoin de faire une comparaison douteuse avec les stages non-rémunérés.
Eh beh quelle bataille de langue de bois...
C'est un peu de la mauvaise foi de partir dans des interprétations digne d'un film américain... N'importe qui en relisant sa phrase ne comprend pas ce que tu écris.
Personne n'a dit le contraire... Et en effet c'est plus que conseillé.
Eh beh... Tu ne dois pas travailler sur de gros projets avec des millions de fonctions...
Suivre le cheminement du code et le comprendre, même avec des noms cohérents et du code simple c'est du temps considérable.
Donc non, commenter ce n'est pas de la merde, c'est un outil...
Tu exagères encore comme un sudiste, c'est aberrant...
QUOI ????? Mais c'est quoi cette vérité vraie que tu veux nous vendre ?
Dans le monde des bisounours et de la perfection oui c'est une vérité.
Mais qu'on me jette une pierre si quelqu'un a déjà trouvé un projet de plus de 3 développeurs et qui dure depuis plus d'un an et qui ne possède pas de trou dans ses tests...
C'est un peu comme l'Agilité ce que tu prône, la théorie cela s'adapte à la réalité et au contexte et du coup on peut s'en écarter méchamment...
Eh beh.. Cela mériterai un signalement à la modération vu les attaques gratuites et non fondées... A ce que je sache tu ne travailles pas avec lui pour savoir tout ça non ?
Donc tu inventes le personnage en le rendant le plus infect possible... C'est de la calomnie...
Après je vois que tu es doctorant, donc je peux comprendre que l'art et la beauté du code soit recherché dans la recherche.
Mais de là à appliquer ce modèle à l'industrie et à d'autres domaines il y a... une énorme galaxie de différence !
Par exemple il m'arrive plus que couramment de faire du code dégueulasse à lire pour réussir à passer le temps réel requis... (et avant que tu me sautes dessus, oui c'est commenté en bonne et due forme)
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
Bonjour,
Pour ma part , je trouve que les commentaires sont quand même le b a ba ... Ne pas en mettre c'est juste des programmes non maintenable ... Au moins dire ce que fait le morceau de code ...
C'est d'autant plus vrai quand on gère du SQL, SAS , R ou d'autre code pour de la data ... Savoir à minima d'ou vient et ou va la data . Sans quoi c'est imbuvable !
Même dans un etl comme pentaho, talend avoir du code c'est une question de clarté ... Sinon on a des morceaux de programme et on ne sait pas ce que fait le programme .
C'est mignon un chaine de traitement sans commentaire ... Quand cela pète bah au moins on sait ou regarder !
Choisir allow, c'est encore être sous domination anglaise...
Cordialement.
C'était ironique pour marquer le fait que le nombre de lignes de ton code ne change rien... que le projet fasse 100 ou des milliards de lignes, le tout est que tu comprennes d'un coup d'oeil, et donc de garder des fonctions de petites tailles compréhensibles d'un coup d'oeil.
Si ton projets fait des millions de lignes, sans que tu puisses travailler sur un "module" ou une "lib", plus restreint, ou de changer de niveau d'abstraction, c'est que ton architecture est pourrie.
Là je suis sur un projet avec bien plus de 10 000 lignes, et ~2 millions, si on compte les dépendances.
Ça aide aussi énormément de factoriser.
J'ai déjà eu à me plonger dans le code des dépendances pour corriger des bugs, ... sans jamais avoir de commentaires (je ne suis pas celui qui a écrit les dépendances), et pourtant c'est pas la mer à boire.
Si tu as besoin de suivre le cheminement du code... c'est que ton code c'est de la merde...
Si votre code est incompréhensible, vous m'étonnez qu'il vous faut des commentaires pour le comprendre...
Et par contre pour les commentaires... c'est magique et ça se mets à jours automatiquement dès que tu modifies ton code... hein... et puis y'aura jamais de trous dans tes commentaires aussi...QUOI ????? Mais c'est quoi cette vérité vraie que tu veux nous vendre ?
Dans le monde des bisounours et de la perfection oui c'est une vérité.
Mais qu'on me jette une pierre si quelqu'un a déjà trouvé un projet de plus de 3 développeurs et qui dure depuis plus d'un an et qui ne possède pas de trou dans ses tests...
C'est un peu comme l'Agilité ce que tu prône, la théorie cela s'adapte à la réalité et au contexte et du coup on peut s'en écarter méchamment...
Par contre quand on dit que je manque d'expérience, n'ai jamais travaillé en équipe et est le type de développeur qu'il exècre le plus, ça passe ?
Ensuite, j'ai parlé de "genre de développeur", je ne parles pas de lui en particulier...
La beauté du code dans la recherche ? Tu plaisantes ?
Tu verrais les codes dégueulasse qu'on pond, avec du code mort de partout, des if(true) if(false) de partout, des fichiers main énormes, aucun tests unitaires/de recettes, des codes qui font des appels à Matlab, des c/c de codes de partout, tout dans le même fichiers, des dossiers v1/v2... Va me parler de la beauté du code.
Dans la recherche, on fait des PoC, des démos, des calculs rapides, on fait du prototypage, la beauté du code.
Bon, après le problème c'est quand il faut refaire ses calculs pour des raisons X ou Y ou réutiliser des bouts de codes pour un autre projet (qui se résume souvent à c/c des fichiers/blocs de fonctions).
C'est une des raisons pour laquelle j'ai entamé un refactoring complet de mes codes, avec une bonne architecture. C'est un investissement pour l'avenir, et une fois que le core est fini, ça devient beaucoup plus rapide de refaire ou d'ajouter des calculs.
Après, une fois qu'une fonction est bien écrite, j'ai plus besoin de retourner dedans, c'est le principe d'encapsulation. Je l'appelle, et ça me sort le résultat attendu, je n'ai pas à me prendre la tête sur comment elle fait, et heureusement car sinon je ne m'en sortirais pas.
Derrière, si je veux ajouter une fonctionnalité, c'est un fichier dans un dossier, et mon bouzin se charge du reste. Bon d'accord, je suis en JS, si je voulais faire les choses proprement je devrais passer en TS.
Mais je ne vais pas m'amuser à mettre des commentaires quand mon code peut changer tous les 4 matins, et lorsque je n'aurais plus besoin à le relire après. Tout ce qui importe, c'est la documentation de l'API publique figée. Quand tu utilises une bibliothèque, tu vas aller lire le contenu du code et les commentaires pour l'utiliser ? Non. D'ailleurs va lire le code d'une bibliothèque... j'en ai pas vu beaucoup avec des commentaires...
Et bon, faut pas aussi oublier qu'on voit aussi pas mal passer le code de stagiaires et des étudiants... Les peu commentaires que tu vois ne servent à rien. Un coup d'oeil doit suffire, sinon c'est qu'il y a un problème dans ton code.
Donc ça rentre dans les "points très particuliers un peu tricky".
Ta contrainte de temps réel est particulière, liée à ton domaine particulier.
Dans 99.9% du temps, si t'as une complexité algorithmique pas trop dégueulasse, si tu évites les copies et opérations I/O, t'as pas de problèmes de performances.
Et je rappelle que dans la recherche, on fait aussi des très gros calculs sur des très gros serveurs de calculs, parce que ces derniers peuvent prendre une année sur un ordinateur normal... donc on fait quand même un minimum gaffe. Après, les micro-optimisations pour gagner des pouillième, ça nous est pas forcément utile.
Mais j'ai l'exemple d'un collègue pour qui sont code prenait de tête 3 jours d'exécution... je lui dit de garder ses fichiers en RAM... le code se termine en 10 minutes.
La plus grande majorité du temps, sauf domaines particuliers, l'optimisation nécessaire reste assez simple.
Je voudrais juste signaler au SJW qu'on dit noires alors qu'ils sont marrons et que les "blancs" sont beiges/Rose. Voila après je dis ca..je dis rien
Si tous les développeurs d'une entreprise démissionnent en même temps et que t'arrives après, ton premier job sera de faire de la rétro-ingénierie pour comprendre comment fonctionne le logiciel. Donc tu vas essayer de comprendre quelles méthodes sont appelées et dans quel ordre. Parfois toutes les connaissances ont été perdues et c'est compliqué de reprendre le projet.
Quand on veut corriger quelque chose il est souvent utile d'utiliser le debugger et de suivre l’exécution pour voir ce qu'il se passe.
Suivre le cheminement du code c'est souvent indispensable.
Si tu dois dire ce que fais ton morceau de code, c'est qu'il n'est à la base pas compréhensible.
... et le problème, c'est quand tu vas modifier ton morceau de code, sans mettre à jours les commentaires, et bonjour la catastrophe... tu vas y passer des heures, avant de te rendre compte que ton commentaire est faux, et te vas devoir au final te taper la compréhension de ton code incompréhensible.
Et puis, les fois futures, tu passeras du temps non seulement à lire les commentaires, mais aussi à lire ton code pour vérifier que les commentaires correspondent bien à ton code... bref, une perte de temps.
Alors que si ton code est compréhensible dès le départ... ça se fait tout seul.
Si tu as un morceau de code, auquel tu dois mettre un commentaire, ça peut être plutôt le coup de créer une fonction contenant ton morceau de code, ton code en deviendra bien plus lisible. Tu choisis des noms de variables courtes, mais explicites, et ça se comprend tout seul. Par de nombres magiques, etc. etc.
Derrière, gère ton code sur plusieurs niveau d'abstractions, haut niveau d'abstraction dans le main, et quand tu rentres dans une fonction, tu descends de niveau d'abstraction.
J'ai dû mal à voir à quoi tu te réfères.
Tu veux dire comprendre un script que tu appelles dans ton logiciel en lui transmettant des paramètres ?
Et de préciser dans le script les valeurs de certains paramètres transmis ?
Est-ce que tu as un exemple ?
Bah, c'est sûr que sans code, t'es pas prêt d'aller loin.
Dans ce cas n'est-ce pas un problème d'architecture, potentiellement dû au fonctionnement du langage/framework ? Et est-ce vraiment des commentaires dont tu as besoin, et pas plutôt d'une documentation sur une version figée ?
Bah, t'as les exceptions qui sont là pour ça.
Après, si t'as besoin de comprendre une chaîne de traitement, c'est une doc, avec une jolie figure qu'il te faut pas des commentaires. J'espère que tu vas pas relire l'intégralité de ton programme/commentaires pour reconstituer tes pipelines.
Après oui, je vais quand même m'excuser pour mon ton un peu sec.
Les forums Actualités/Politiques me mettent un peu sur les nerfs, et je pars au quart de tour.
Ah bon ? Ben ça me coupe le sifflet ça
Il fallait comprendre commentaire et non code.J'ai dû mal à voir à quoi tu te réfères.
Par exemple cela aide . Au lieu saisir manuellement 25 fois une ref ...Tu veux dire comprendre un script que tu appelles dans ton logiciel en lui transmettant des paramètres ?
C'est cela.Et de préciser dans le script les valeurs de certains paramètres transmis ?
Il fallait comprendre commentaire et non code.Bah, c'est sûr que sans code, t'es pas prêt d'aller loin.
Dans un ETL tu as des blocs de programme et de chaîne de traitement . Des commentaires pour expliquer une dérivation ou une règle de gestion c'est plus qu'utile.Dans ce cas n'est-ce pas un problème d'architecture, potentiellement dû au fonctionnement du langage/framework ?
Non les deux ... Tu as toujours le cas particulier ... qui devient la norme tellement les chaînes de traitements sont complexes.Et est-ce vraiment des commentaires dont tu as besoin, et pas plutôt d'une documentation sur une version figée ?
Le problème avec l'ironie c'est que mélangé dans un post dont le ton est clairement monté haut c'est difficile à voir. A ce stade les blagues bien vaseuses, bien raciste ou tout ce que tu veux c'est de l'ironie...
Quand ton module reste conséquent cela ne change rien au problème.
J'implémente des algorithmes pensés par des chercheurs et cela ne prend pas quelques centaines de lignes... (bon certes ce n'est pas la majorité, et mes projets ne reflètent surement pas le monde)
On est toujours content de passer après de bons développeurs.
Non. C'est qu'il est d'une certaine complexité qui fait que tu vas avoir du mal à l'aborder du premier coup d'oeil.
La factorisation par exemple cela ne rend pas forcément plus compréhensible un code, des fois c'est tout l'inverse.
L'appel à de multiples modules en tout genre dans tous les sens, cela peut nuire à la lecture et à la compréhension de la fonctionnalité finale.
Pour appréhender ce que fait un système on peut se contenter de lire la documentation.
Pour comprendre ce que fait un système on va forcément être obligé d'aller comprendre tous ses modules.
J'ai encore jamais vu quelqu'un qui en lisant la doc était capable de dire avec certitude que le bug était dans tel ou tel module... Cela s'appelle de l'astrologie ça.
Et les tests c'est magique cela se met toujours tout seul à jour.Et par contre pour les commentaires... c'est magique et ça se mets à jours automatiquement dès que tu modifies ton code... hein... et puis y'aura jamais de trous dans tes commentaires aussi...
Un métier cela englobe un certain nombre de tâche, la mise à jour des commentaires quand on modifie un code est une tâche au même titre que d'aller modifier les tests...
Je te souhaite de passer un de ces jours sur des projets merdiques mais fonctionnels pour relativiser car tu me sembles beaucoup trop campé sur tes positions.
Tu te rendras vite compte que vouloir tout refactoriser, tout rendre propre, c'est se tirer bien souvent une balle dans le pied.
J'en ai déjà vu passer dans mes projets... Le risque de régression est tellement énorme qu'à chaque fois, même sur des fonctions anodines bah ça passe rarement sans casse...
Alors quand on le détecte dans la semaine c'est bien, mais quand on le détecte deux ans après tu crois que c'est intéressant de payer un ingénieur pendant deux semaines pour trouver et corriger ?
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
Oui, ça j'ai bien compris, mais je me représentais mal l'exemple que tu nous décris.
Et tu ne peux pas nommer tes paramètres de manières explicites de sorte qu'on comprenne ce qu'ils représentent (et potentiellement leur domaine de valeur) sans avoir à en expliciter les valeurs prises ?
Ah tu veux dire une description de tes "scripts" que tu mets dans ton système et non dans le code ?
Un peu comme dans un jeu, tu as une description associé à tous les objets de ton inventaire ?
Et ton framework ne peut pas te donner automatiquement une image du pipeline ?
Ça permet d'avoir un premier niveau de découpage. Après, tu peux avoir des sous-modules, une interface publique que tu exposes, etc. etc.
Le tout c'est de ne pas se retrouver avec une énorme usine à gaz où on ne sait même plus par où commencer à chercher.
Après, faut redécouper en sous-partie.
C'est sûr que si tu mets tout dans la même fonction sans sous-fonctions, ça prend énormément de lignes. Moi j'ai plusieurs étapes :
- protection
- pré-traitement
- sélection des valeurs
- calculs des scores
- calculs des métriques
Ben chaque étape c'est plus ou moins une fonction (ou une méthode). Et puis derrière, e.g. pour la protection, j'implémente chaque méthode séparément, au plus simple. Et j'ai derrière un bout de code qui appliquera la méthode choisie à chaque élément de ma base.
Après, oui si je récupère des trucs d'ailleurs, je vais mettre un petit commentaire avec la source (e.g. c/c de Stack-Overflow), mais ça reste très rare.
Oui. Et puis même avec des très mauvais développeur, quand tu vois la gueule de certains bugs, tu sais tout de suite d'où ça vient, sans même n'avoir jamais eu accès au code.On est toujours content de passer après de bons développeurs.
Bon, des fois c'est plus compliqué. Par exemple j'avais en JS un Infinity qui était transformé en null à cause de JSON.stringify, qui est utilisé en internet par les communications entre processus. Puis retransformé en 0, parce que null = 0.
En regardant la gueule de certains résultats, tu sais d'où vient l'erreur. Un truc cyclique de 42, c'est un de tes 42 threads qui a merdé. Tu vois dans tes logs que ça arrive 2 fois après une certaine chose... ça te donne un gros gros indice.
Une valeur 0, sur une méthode particulière, tu sais que c'est que le problème vient de cette méthode, très certainement parce qu'elle a renvoyée NaN (valeur qui bousille toutes les opérations faites après).
Là c'est sur mon propre code, mais sur le code e.g. de bibliothèques, ou de jeux en lignes, t'as des trucs que tu renifles de loin. Tu valides un achèvement et plus rien ne s'affiche avec un message d'erreur de dépassement de liste... tu sais tout de suite d'où ça vient.
D'où l'utilité d'avoir plusieurs niveaux d’abstractions.
Si c'est bien fait, non, je ne suis pas d'accord.
T'as pas de la doc pour expliquer ton architecture ? De la manière dont s'organisent tes modules ?
Ton arborescence ne t'explicite pas déjà en partie ton architecture ?
Ben déjà t'as le message d'erreur, la stacktrace, les logs, les résultats, les symptômes, ça aide énormément.J'ai encore jamais vu quelqu'un qui en lisant la doc était capable de dire avec certitude que le bug était dans tel ou tel module... Cela s'appelle de l'astrologie ça.
Quand je clique 1 fois sur un bouton... rien ne se passe... je re-clique, ça me fait 2 actions d'un coup... je sais tout de suite d'où ça vient. C'est juste que le bouton est désactivés après réponse du serveur, donc en cas de lag, il met du temps à se désactiver, au lieu de se désactiver dès le clic, avant d'envoyer le message au serveur.
Si tout est bien propre, bien découpé, avec quelques vérifications à des points clés, des exceptions avec des messages explicites, tu remontes quand même bien vite à l'origine du bogue.
Non, en revanche, quand tu fais un commit le pipeline CI/CD va t'engueuler si tu passes pas les tests...Et les tests c'est magique cela se met toujours tout seul à jour.
Pour les commentaires, j'ai pas encore vu de mécanismes CI/CD pour faire ça...
Si t'as pas besoin de commentaires... t'as pas besoin de les mettre à jours...
Et puis oui... on connaît tous ça, tu fais des modifications un peu partout, tu mettras à jour les commentaires une fois que t'auras fini... et t'en oublie la moitié...
Sachant que tu vas passer un temps fou... juste pour paraphraser des banalités...
Alors que tes tests, eux, ils vont t'engueuler si tu les oublies.
Pour le moment, j'ai que eu des projets merdiques et non fonctionnels...Je te souhaite de passer un de ces jours sur des projets merdiques mais fonctionnels pour relativiser car tu me sembles beaucoup trop campé sur tes positions.
Tu te rendras vite compte que vouloir tout refactoriser, tout rendre propre, c'est se tirer bien souvent une balle dans le pied.
Mais oui, quand j'ai refactoré mon code, j'ai eu quelques bug qui m'ont pris du temps à corriger... sauf que derrière... mon dieu que c'est bon d'avoir du code propre... Parce que si je n'avais pas eu le temps d'écrire du code propre à l'époque... j'en avais encore moins pour écrire des commentaires.
Par contre maintenant, j'ai un système qui fait le café, et je rentabilise très rapidement le temps que j'y ai investi. Après, ça c'est pour l'architecture. J'ai des fonctions qui marchent très bien, que je n'ai pas retouchés. Ça marche, je sais ce qu'elle fait grâce à sa signature, j'ai pas besoin d'aller m'en soucier davantage.
Ce n'est pas une question de tout rendre propre, mais d'écrire dès le début du code propre. Si t'as besoin d'ajouter des commentaires, c'est que le code que tu as écrit est sale, et qu'il est en train de s'ajouter à ton projet merdique. Donc que tu ne fais que rajouter de la merde à la merde, et un jour ça va exploser, et tu seras obligé de tout réécrire, dans 3 ans, 10 ans, ou 20 ans. Et là ça va te coûter une blinde.
Parce que la dette technique que tu vas te traîner et accumuler, faudra bien la payer un jour.
Avancer itérativement en ajoutant rustine sur rustine, sans prendre le temps de prendre du recul, avec ou sans commentaires, ça deviendra une horreur impossible à maintenir à terme. Et le temps que tu auras "gagné", tu le perdras de plus en plus à chaque fois qu'il faudra faire la moindre modification.
Faut pas se lancer bille en tête, faut d'abord réfléchir. Ne pas trop anticiper, mais prévoir quelques possibilités d'évolutions futures, sans trop en faire. Puis lors d'ajouts de nouvelles fonctionnalités, prévoir quelques modifications pour bien intégrer le tout. Sinon tu construits une bombe qui t’explosera à la gueule tôt ou tard.
Et derrière, le temps que tu passeras à écrire tes commentaires, c'est du temps en moins pour la qualité du code que tu es en train d'ajouter... et tes commentaires vont s'ajouter à la pile de merde, parce que les 3/4 ne seront plus à jour dans 2 ans. Donc tu auras juste perdu du temps pour rien.
Et pour des fonctions à fort risque de régression... pourquoi il n'y a pas de tests unitaires ?
Parce que bon... 2 ans après, tu vas laisser un bogue dans ton code... et 5 ans plus tard ça t'explose à la gueule, avec les 100ènes d'autres bogues qui vont interagir n'importe comment, un vrai enfer. Et avec un peu de chance, la solution sera de tout réécrire de 0... Et c'est reparti pour un tour...
Sachant que si t'as un concurrent qui se pointe, plus jeune, donc avec moins de dette technique, pour un logiciel plus rapide et avec moins de bogues... il pourra te faire pas mal de dégâts à ton marché.
Plutôt que de se précipiter, puis de perdre du temps à écrire plein de commentaires de partout... juste prendre le temps sur la conception, pour écrire quelque chose de maintenable dès le début. Et si tu reprends du code, ben essayer de séparer le vieux du nouveau code, avec une bonne architecture et en remettant les choses au point. Et au fur et à mesure que tu retravailleras dessus, tu déplaceras l'ancien vers le nouveau.
Après, si tu ne fais que du débogue, tu ne fais pas réellement du développement au sens où tu n'écriras pas un nouveau logiciel, ou n'ajoutera pas une "grosse feature".
Parfois si on peut associé un nom de variable à un nom de programme. Pas toujours ...Et tu ne peux pas nommer tes paramètres de manières explicites de sorte qu'on comprenne ce qu'ils représentent (et potentiellement leur domaine de valeur) sans avoir à en expliciter les valeurs prises ?
Oui tout à fait . Car le principe d'un ETL c'est de modéliser le flux. Donc des commentaires , sinon c'est un parcours ... de données mais à l'aveugle.Ah tu veux dire une description de tes "scripts" que tu mets dans ton système et non dans le code ?
En quelques sorte. Un genre "d'info bulle".Un peu comme dans un jeu, tu as une description associé à tous les objets de ton inventaire ?
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