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 :
On dirait aussi ... pour moi debugger c'est de la maintenance. Et il s'agit généralement de cas tordus sur des programmes tournant depuis de nombreuses années. alors que "debugger" un programme qui vient d'être écrit relève du test unitaire et est censé être simple puisqu'il s'agit de son code, donc connu et compris.Envoyé par Washmid
Oui, le débogage doit être mieux enseigner mais de là à dire que c'est le plus important, pas sûr du tout
Par exemple, la factorisation du code est essentielle car elle permet d'isoler les tâches dans des fonctions dédiées
Nous seulement, cela permet de tester individuellement chaque tâche unitaire (et facilite le débogage) mais améliore également la robustesse et la maintenabilité du code (la modification d'une tâche ne se fait qu'à un seul endroit, ça évite les oublis)
Apprendre le débogage : oui
Apprendre à bien structurer son code pour éviter / simplifier le débogage : oui et oui
Le développement est une tâche complexe qui implique de multiple compétences qui ont toutes leur importance
Affirmer que l'une est plus importante que l'autre n'a pas grand sens
Complétement faux...
quand on travaille dans la qualité logiciel, on relis le code de ses petits copains.
Ce qui est quasiment la règle pour tous logiciels destiné à la vente grand public, mais c'est encore pire pour les logiciels embarqués, ou millions peuvent être en jeux, voir des vies humaines.
Bien sur dans le secteur Banque finance, ils peuvent jouer avec l'argent des autres, c'est moins grave (ironique), mais normalement, avant qu'un code soit livré en exploitation, il est au moins relu par le chef de projet
Et que penser des dépots libres sur GitHub et autre, destinés à la communauté des développeurs, si tu tiens à ta réputation, t'as plutôt intérêt à lécher ton code...
Ah, et j'oubliais, et ceux qui travaillent ensemble sur des gros projets libres, genre Apache (qui entre nous soit dit, sont plutôt des pointures) je crois pas non plus qu'ils ajoutent du code avec un simple commit, sans prévenir les autres...
Non, Le Debugging fait partie de la programmation, dès le départ !
Les tests unitaires ne permettent pas de debugger, je serais vraiment très reconnaissant si quelqu'un me montre sur un exemple simple comment il peut localiser un bug qu'on a détecté en production grâce aux tests unitaires. Les tests unitaires permettent juste de détecter la présence des bugs prévisibles dans classe, mais ils ne permettent pas de localiser le bout de code précis qui cause le bug. Si par exemple une méthode f1 retourne un "bug" et que cette méthode appelle des méthodes privés f2, f3, f4, le test unitaire ne va pas vous dire qui de f2, f3, ou f4 est à l'origine du bug, le test unitaire signale simplement un bug, mais il ne le localise pas avec précision.
En plus 95% des bugs que je rencontre sont des bugs d'intégrations, les bugs issues des tests unitaires sont très rares, et sont très facile à détecter
Il y a un autre problème, différent du déboggage mais qui lui est néanmoins connexe : le code écrit pour gérer les erreurs à l'exécution.
Il ne suffit évidemment pas de blinder son code d'assertions, ni de passer son temps à lever et à catcher des exceptions. Une bonne gestion d'erreur nécessite beaucoup plus de réflexion que cela (même si les exceptions peuvent être un outil précieux) et a sans doute besoin d'être abordée différemment selon les types de projets.
Petit problème : comment ENSEIGNER la gestion d'erreur ? Ou le déboggage ? Ou la maintenance ?
Je pense que ce sont des choses que l'on ne peut pas trop enseigner, et qu'il ne suffit pas de croire à une telle idée pour en faire quelque chose.
Remarquez qu'il est peut-être facile d'"enseigner" la maintenance... demander aux étudiants de la promo N+1 de faire de la maintenance évolutive et / ou corrective des projets des étudiants de la promo N... avec l'interdiction stricte de tout réécrire from scratch. Voilà un bon exercice pour ceux qui n'ont peur de rien !
J'adhère bien à l'idée de gérer des projets sur plusieurs promo avec de mettre en pratique la maintenance.
Sinon, la gestion des exceptions s'enseigne très bien (en tout cas, j'ai eu un bon prof pour ça lors de mes études)
De même, il existe des design pattern pour gérer les exceptions...
Ce qui manque surtout, c'est d'avoir des prof qui soient proche de la réalité du travail en entreprise
En ce qui me concerne, j'ai étudié à la fac et l'intégralité de mes prof étaient des enseignants chercheurs et la plupart étaient totalement déconnectés des réalités du marché
Pour ceux qui étaient membres de communautés open source, ça allait
Mais certains étaient auto centrés sur leurs domaines et là....
Normal, ce n'est pas leur but. Les TU (mais aussi un typesystem riche et strict, des assertions/pré ou postconditions dans le code) ne traquent pas les problèmes ou régressions apparus en production mais les signalent dès le développement. D'où, moins de bugs qui atteignent la production. Le debug devient une compétence moins primordiale, car on utilise autre chose en dev, et il y a moins de problèmes qui atteignent la prod. CQFD
On a déjà au moins la méthode publique où se trouve le bug, ainsi qu'une description du problème, les valeurs attendues par rapport aux valeurs réelles. Ce qui est bien mieux que de partir d'un comportement anormal constaté à travers une exécution manuelle de l'application, où on essaie plus de deviner et de tâtonner. Par ailleurs, il vaut mieux externaliser les responsabilités dans des petites classes séparées et testables unitairement, que de recourir à de longues méthodes publiques qui font appel à beaucoup de méthodes privées.
Si on a conçu une application valide et fiable dès le départ, bien sûr que 95% des bugs seront liés à la configuration et à l'environnement, et c'est tant mieux. Pour ceux-là, le diagnostic via du debugging est long, fastidieux et parfois hasardeux (on ne peut pas toujours recréer entièrement les conditions de la prod en débuggant).
On ne dit pas qu'il ne faut pas débugger, juste que mettre la priorité sur l'apprentissage d'une technique consommatrice de temps, pénible et dont on peut significativement réduire l'utilisation, n'est pas forcément une bonne idée.
Pour faire court, je suis de l'avis de Luckyluke34, air-dex, Saverok. Pour ceux qui aiment les pavés, lisez la suite. {^_^}
Et pour ceux qui se diront tout au long de leur lecture "ouais mais ça c'est la théorie, la pratique c'est pas comme ça" ou "tu connais rien à la vie", qu'ils se disent qu'il y a ceux qui passent leur temps à critiquer la théorie, et ceux qui passent leur temps à l'appliquer. Choisissez votre camp. {^_°}
Je fais partie du "presque". On peut-être suffisament rigoureux pour avoir un truc qui marche du premier coup. Et là je parle d'expérience perso, pas de principe. Ça m'est déjà arrivé, et si on reste flexible sur la notion de "premier coup" (correction de quelques ';' ou '"' manquants, dire que ça compile), alors ça m'est arrivé plus d'une fois et ça m'arrive encore. C'est tout à fait possible et ça n'a rien de miraculeux ni de l'ordre du génie. C'est d'autant plus faciles si on se limite de 100 à 1000 lignes de code, et quand on fait de la programmation modulaire c'est plusieurs modules de 100-1000 lignes sur chacun desquels on peut réitérer l'exploit.
Quand tu sais découper ton gros problème en sous problèmes, qui deviennent suffisamment simples pour être codés bons du premier coup (tous tes tests dédiés passent au vert direct), et que tu fais ça dans l'ordre, y'a pas de raison que tu ais à passer un temps significatif en débogage. Mais bien entendu, ça demande de prendre le temps de comprendre le problème, de le formaliser, de le découper proprement, de restreindre ses envies d'optimiser à tout bout de champ, etc. Ce temps que tu ne passeras pas en débogage à générer de la sueur froide, tu le passeras en préparation à générer de l'expertise, qui se traduira en code propre et robuste.
@psychadelic : Non faire un code qui marche du premier coup c'est pas qu'un coup de chance. Soit on fait ce qu'il faut pour que ça marche du premier coup, soit on ne s'en soucie pas (ça n'empêche pas d'avoir d'autres critères de qualité en tête) et là c'est effectivement un coup de chance. Si tu veux quelque chose, organise-toi pour l'avoir, c'est aussi simple que ça. Découper en sous-problèmes et faire preuve de rigueur sont deux façons de favoriser le "test vert dès le premier coup". Contrairement au golf où tu ne contrôles ni le vent ni le terrain et dois faire uniquement avec des approximations, le codage est bien plus contrôlé et donc facile à maîtriser. Le tout étant de faire l'effort d'être méthodique. Ça ne préserve pas des erreurs, mais ça réduit notablement le temps passé en débogage (initial comme maintenance).
Importante, oui mais pas en tant que telle, donc la plus importante, non. Avant de savoir déboguer, il faut savoir coder et connaître le contexte de l'application. Et c'est quand on a intégrer tout ça qu'on peut remettre en cause le code. Déboguer c'est savoir identifier ce qui ne vas pas, trouver une solution et l'implémenter, ce qui n'est rien de plus que savoir coder.Pensez-vous aussi que le débogage est la compétence la plus importante à enseigner ?
Dire que le débogage est négligé dans le sens "on n'apprends pas assez à régler des problèmes", je suis d'accord. Mais le codage c'est pareil, ça se limite pas au débogage. Dans le sens "on ne passe pas assez de temps à s'entrainer à des tâches de maintenance", là par contre je suis contre. Je préfère de loin un enseignement qui m'apprend à faire du code propre et correct plutôt qu'un enseignement qui prend le code sale pour la norme inévitable. Quand tu sais faire du code propre, tu reprends un code sale en le nettoyant, pas en minimisant tes modifs.
Pour moi c'est quelqu'un qui passe beaucoup de temps à faire évoluer une appli mais peu à la déboguer. Déboguer, c'est savoir se poser les bonnes questions pour remettre en doute le code. Quand on se pose les bonnes questions avant de coder, le débogage on n'en a quasiment plus besoin. Et ces questions se transforment en tests qui passent au vert.
Pour répondre à BugFactory, utiliser le débogueur souvent aujourd'hui est soit un choix (parce que tu préfères faire des tests en manuel plutôt que de les implémenter, clin d'oeil à nirgal76) soit le symptôme d'un manque de maitrise :
- si c'est seulement pour vérifier que son propre code marche, c'est soit un manque de maitrise du langage en lui-même (t'es pas sûr de comment interpréter telle syntaxe), soit un manque de maitrise du problème (concepts peu clairs, grosse fonction intestable venant d'un manque de découpe du problème en sous-problèmes, etc.). Et pour ce genre de cas, mieux vaut je pense prendre le temps de maitriser le problème, le découper proprement pour faire des fonctions dédiées et leurs tests associés, qu'on peut rejouer plus tard et fournissent un filet de sécurité. On ne joue plus avec le débogueur, qui reste du manuel et donc un effort supplémentaire récurrent.
- si c'est seulement pour comprendre le code d'un autre, c'est un manque de maitrise du langage aussi, dans le sens où il suffit de lire le code pour savoir ce qu'il fait. Ça ne nous dit pas pourquoi il le fait, mais ce qu'il fait. Et comprendre le pourquoi ne doit pas venir du code mis en défaut, mais du contexte (où et comment il est utilisé). Toute déduction du pourquoi d'une fonction par l'étude de son code n'étant qu'interprétation perso sujette à caution (je me suis déjà fait avoir). Et si le code est "trop complexe", utiliser le débogueur ne te donnera que des informations supplémentaires sur des exécutions précises, donc pas forcément généralisables et donc des interprétations biaisées. Plutôt que d'utiliser le débogueur (et comme le mentionne Mat.M), mieux vaut je pense faire du refactoring qui préserve la sémantique du code mais améliore sa lecture : changer les noms des variables et fonctions, extraire les parties indépendantes du code dans des fonctions dédiées (et bien nommées), etc. Ce n'est pas toujours facile, et parfois infaisable (des tas de dépendances inutiles sont ajoutées, ce qui t'empêche de trouver des parties indépendantes à factoriser), mais tu peux le pousser jusqu'à être bloqué pour te donner la meilleure vision que possible. Après, soit tu altères le code sur la base d'interprétations pour le factoriser davantage, soit tu prends les morceaux monolithiques comme des boites noires.
- si c'est pour régler un problème (et là je ne dis rien de neuf, cf. toutes les discussions qui parlent de l'origine des bogues), ça implique que le codeur initial (toi ou un autre dont tu auras repris le code) n'avait pas une idée assez claire/fiable de ce qu'il devait faire. Dans le cas de plusieurs devs, qu'au moins certains d'entre eux n'avaient pas une idée claire/fiable de ce qu'ils devaient faire, ou que l'intéraction de leurs différents modules n'était pas claire/fiable. Après on pourra se demander à qui la faute, mais c'est une autre discussion déjà lancée.
Quand tu codes une application, même complexe (complexe ne veut pas dire compliqué), pour obtenir un code dont tu es convaincu qu'il fonctionne il faut passer par des étapes nécessaires (qui dépendent de beaucoup de choses, mais dans l'ensemble qui se résument à comprendre le problème, le formaliser, déduire la solution et l'implémenter, la notion de test étant transversal à tout ça). Pour s'assurer que ces étapes soient faites, il faut bien organiser le processus d'implémentation, et pour s'assurer qu'elles soient validées, il faut bien organiser le code pour pouvoir tester chaque partie concernée. Quand tu as une deadline trop courte, tu pourras jouer des pieds et des mains, tu ne pourras pas faire une appli complète ET correcte. Dès lors, il faut faire des choix, le tout étant de les assumer derrière.
On peut être amener à déboguer un code propre (règle de gestion mal comprise, par exemple).
La maintenance c'est à la fois l'analyse et la correction de bug mais aussi de l'optimisation de code et la mise en place de petites évolutions.
Ces tâches représentent le quotidien d'énormément de développeurs.
Je dirai même que dans la majorité des cas, on part rarement d'une feuille blanche, il y a toujours de l'existant qu'on doit comprendre et développer voir le modifier afin d'y insérer son propre code.
Une bonne formation qui prépare à la vie professionnelle doit tenir compte de cela.
Tjrs développer à partir de zéro ne prépare pas à la vie réelle en entreprise.
De même, il faut bien s'entraîner à analyser et déboguer des programmes mal codés car ce n'est pas en ayant appris uniquement avec du code propre qu'on est armé pour faire face à un programme codé avec les pieds.
Je dirai même que comprendre en première lecture un code bien structuré, c'est facile.
Alors que comprendre un code "pourri", même en s'y prenant à plusieurs fois, c'est nettement plus complexe.
Une bonne formation doit préparer à la réalité de la vie pro.
Et dans la vie pro, on est souvent confronter à du code pas propre.
Y être confronté durant sa formation ce n'est pas le prendre pour norme, c'est au contraire, en tirer des enseignements pour savoir s'y retrouver et prendre conscience des choses à ne pas faire car on en a les conséquences directs (écrire du code naze est une chose, reprendre celui d'un autre est une toute autre expérience)
+1
j'ai eu en 2008 à réécrire entièrement un code COBOL codé avec les pieds en 1972. Et ma spec était : "on c'est que c'est sale, mais ça marche. Tu nous fait la même chose, qui marche pareil, mais propre et documenté"(bon, y'avait un pretexte, le format de sortie était chamboulé. Mais les données devaient rester les mêmes). Sauf que nous n'avions des outils de déboguage qu'en transactionnel, et que c'était du batch. J'ai dansé. Avec des codes du genre :
le tout, dans un langage qui permet de faire des boucles propres, qui permet des libellés long et parlants, qui permet de mettre des END-IF au lieu d'un atroce point en bout de ligne qui le ferme alors qu'on ne le voit pas, qui connait le else, etc... Et il y avait des boucles beauuuuuuucoup plus complexes que ce bête garnissage de tableau. J'aurais vraiment aimé, dans ces conditions, avoir un debugger, et pas juste une trace.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9A122. MOVE 1 TO II A12. ADD 1 TO II MOVE ZZZ(II) TO ZZZZ(II) IF II > JJ GO TO A121 . GO TO A12 A121. (.../...)
dans ce cadre, l'argument "si c'est seulement pour comprendre le code d'un autre, c'est un manque de maitrise du langage aussi" ne passe pas. Un code crade est crade, point. Et tout ce qui permet de mieux l'appréhender est le bienvenu. Et c'est quand même horriblement fréquent. J'attire l'attention du lecteur sur l'ordre apparemment aléatoire des labels(cibles des GO TO). Quand on est confronté à ça(et ça m'est arrivé dans plusieurs endroits), il ne s'agit plus de maitrise. Il s'agit de survie. Et tous les coups sont permis - tant que le résultat, lui, est lisible.
pour les curieux, la boucle "propre" en COBOL :
Sans être aveuglant d'élégance pour les aficionados du Python, J'ose espérer que ça vous parait quand même plus civilisé...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3PERFORM VARYING I FROM 2 BY 1 UNTIL I > TAILLE-TABLEAU MOVE TABLEAU-ENTREE(I) TO TABLEAU-SORTIE(I) END-PERFORM
Le débogage partie importante du développement
Quel que soit le projet il convient de de prendre un papier et un crayon de noter le but de son élaboration, sa structure et les points important importants qu'il faut avoir à l'esprit. Ensuite passer à l'écriture et enfin tester l'appli pour la déboguer. Cette dernière étape étant incontournable. En effet, qui peut dire avoir penser à tout avant l'écriture du code. Le débogage contribue, nécessairement, à parfaire la formation personnelle de chacun.
Si on applique la démarche TDD, écrire les tests avant le code, le test est la pour s'assurer du bon fonctionnement, moins besoin de débuguer.
Si on code en appliquant les bonnes pratiques : SOLID, DRY, YAGNI, KISS, qui mènent à une faible complexité cyclomatique, et donc la possibilité de tester facilement et de tester en découplé.
On va éviter pleins de debugages qui prennent du temps.
Les tests unitaires et automatisés diminuent cette incontournable que vous sitez...
La démarche RED, GREEN, REFACTOR permet aussi d'avancer plus simplement vers l'objectif...
Moins ne veut pas dire qu'on en a pas besoin. Et comme souligner par une autre personne, un test auto c'est presque du debuggage. Avec TDD, le premier reflexe suite à l'apparition d'un bug (en dev, en prod ou autre), sera de recréer le cas dans les TU, comme quand tu lanceras ta séance de débuggage.
L'avantage c'est qu'avec TDD, les TUs ainsi créés pourront être gérer en conf et ratisseront surement beaucoup plus large que de poser une garde (TU + assertions) sur uniquement la/les classes en cause après avoir trouvé le bug.
Attention, ces sigles sont le reflet d'important concept mais il ne faut pas oublier ce qui en découle :
SOLID revient à créer beaucoup de classe avec de petits rôles. Cela complexifie la navigation et parfois la représentation que l'on a du système. Idem pour DRY.
YAGNI tend dans certains cas à créer des bugs. En effet dans le monde des bisounours tous les cas sont prévus et ont été spécifiés. Dans la vraie vie tu vas remonter le problème à un responsable qui ne tranchera jamais ou qui balancera un "ca n'arrivera jamais", en d'autres mots "tu n'en auras jamais besoin".
Sinon je connais un moyen d'éviter les bugs (dans le code) : la méthode B. Mais cela n'empêchera pas un bug de spécification. Sauf le jour où on saura spécifier formellement le monde et son évolution ...
Donc on a encore devant nous de nombreuses heures à traquer les anomalies qu'elles soient dans une méthode/procédure/macro/..., dans l'intégration de classes/librairies/systèmes/..., dans une spécification/cahier des charges/mail/.. ou ...
Les matières purement informatique n'ont pas à vocation à apprendre l'esprit d'analyse. Les matières plus générales sont bien mieux adaptées. Car le débogage n'est rien d'autre que de l'analyse (au sens purement "cognitif", et non "conception de système"). La seule leçon utile qui s'applique éventuellement à l'informatique, je peux la donner 5 minutes : "Réduire le problème à sa plus simple expression" et ensuite décrire le problème. Rien qu'avec ça, 75-80% du travail est fait.
Le débogueur, les logs, les "print" etc. n'étant que des moyens de feedback (une vue sur ce qui et quoi se passe).
Après ce sera surtout l'expérience qui parle. Inutile de dédier des cours à cela. Du code écrit, compilé, exécuté, analysé et ... débogué les étudiants en verront plein durant leur apprentissage de l'écriture de code.
Ce n'est pas non plus parce qu'une chose prend du temps qu'elle est complexe, ni même qu'on y consacre une part importante de l'enseignement. Dormir prend beaucoup de temps, pourtant personne ne nous l'a enseigné ...
Logan Mauzaize
Je partage ton commentaire sauf la fin
Par contre, il existe des méthodes pour optimiser son sommeil
Les objets connectés permettent d'analyser son sommeil pour l'optimiser et c'est des techniques largement utilisées par les navigateurs en solitaire, notamment.
C'est la même chose pour le débogage
Il existe des outils dédiés qui permettent d'optimiser cette phase et des trucs et astuces qui le facilite bien...
Consacrer 1 ou 2 TP au débogage au cours du cursus ne me paraît pas déconnant.
Ce n'est pas parce que l'on sait faire quelque chose qu'il n'est pas possible de l'optimiser (d'autant plus quand on est autodidacte sur le sujet)
Attention à ne pas vouloir créer une "usine à expert". Il faut être conscient qu'en sortant d'une école, un jeune diplômé soit encore en friche.
Le diplôme n'ouvre qu'une voie sur une multitude de métier et donc une grande diversité de compétence et de manières de les utiliser.
Le problème avec le débogage c'est que tous les débogueurs ne disposent pas des mêmes fonctionnalités. Et que son fonctionnement est fortement lié à la représentation du code dans un langage donné. Après tout c'est bien son rôle, coller l'exécution du programme à sa représentation en code source.
Je n'ai qu'une expérience en débogage Cobol (sous Windows avec AcuBench), avec le C++ (avec ???) et Java (avec Eclipse/Netbeans). Mais de mes souvenirs, ce fut à chaque fois expérience différente. L'art du débogage me semble plus lié à la capacité de faire le lien entre le code et son fil d'exécution. Ce qui me semble important avant tout c'est d'avoir une bonne représentation de ses lignes de code.
Après il est vrai qu'abordé ce travail au cours de quelques TPs ne feraient surement pas de mal. Mais seulement ne mérite peut-être pas des TPs exclusivement dédié à cette notion. Par exemple, la robustesse (dans son ensemble : gestion des erreurs, de bonnes traces, reprise, etc.) mérite surement plus d'attention.
Bref, de toutes façons mes propos faisaient écho à :
Plutôt surprenant comme discussion, on dirait en regardant les réponses qu'on ne fait pas tous le même métier...
Pour ma part, on pourrait aborder le debug en cours mais sans approfondissement parce que les outils de debug ne se valent pas tous et n'ont pas les mêmes fonctionnalités.
Ceux qui disent que faire du debug ne sert à rien me font doucement rigoler ! Ou il travaille sur des codes ne dépassant pas les 50 lignes et avec une seule classe qui les utilise, ou eux et leur égo ne passent pas les portes
Dans les applications modernes (conséquentes), les interactions entre différents modules, bibliothèques, api diverses, couches... sont telles qu'il est presque impossible de tout prévoir. Même les tests unitaires ne peuvent garantir le bon fonctionnement du tout...
Il me paraît plus important que les cours mettent l'accent sur les tests unitaires que sur le debug, le minimum qu'on puisse (et qu'on devrait) garantir est que la brique logicielle fonctionne correctement de manière autonome... pour le reste, il y aura le debug, ou la vieille méthode à base de log (la misère quoi)
C'est effectivement le cas
DVP est un site des professionnels de l'informatique et l'informatique est un domaine très vaste qui regroupe pas mal de métiers différents
Tout le monde ici ne fait pas du dev, ou pas exclusivement
Et même dans le dev, il y a énormément de variantes et de sensibilités différentes.
Je suis parfaitement d'accord avec ça
Il est évident qu'avec un programme parfaitement construit, une granularité des méthodes bien dosée, des variables bien nommées et des TU en veux-tu en voilà, le débogage est rarement utile et lorsque cela arrive, il est aisé
Malheureusement, la réalité est souvent très différente
Quand on débute, on a rarement une conception aux petits oignons
De même, en entreprise, pressé par les délais, les TU passent parfois (voir souvent) à la trappe et lorsqu'ils sont écrits, ils ne sont pas forcément ultra complet
Pour finir, le pus important, on débogue rarement ses propres lignes de codes mais souvent celles écrites par d'autres
Nos lignes de code entrent souvent en interaction avec le code existant et c'est souvent là que ça coince.
L'expérience fait énormément mais cela ne remet pas en cause la nécessité d'une bonne formation adaptées aux réalités du terrain
Attention, je parle bien de représentation et non de présentation. J'évoque plus une carte mentale (mind map) que la forme que l'on donne au code. Ceci dit c'est peut-être l'exercice de construction de carte mentale qu'il faut développer chez les étudiants ?
Tout ceci est largement subjectif, ce qui va te paraître clair, limpide, sera un véritable merdier pour un autre...
Rien que pour les noms de variables c'est déjà la foire d'empoigne entre développeurs, pour ce qui est de la structure du code c'est pareil, la "norme" en java veut que l'accolade ouvrante d'une classe ou méthode se trouve sur la même ligne que son nom, chez nous on préfère à la ligne (perso, je trouve ça bien plus lisible), etc...
Dans tous les cas, je ne place pas le debug au même niveau, on l'utilise pour suivre l'exécution pas à pas lorsqu'on n'a pas d'idée sur l'origine du dysfonctionnement... et ça arrive souvent avec le nombre de boites noires qu'on assemble ou la manie de certains de faire des try catch de tout et n'importe quoi
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