"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Perso je me suis rendu compte que mon IDE avec un debuggeur plus d'un an après son utilisation.
On m'a toujours appris, pour le debuguage, de positionner des balises (print, echo, messagebox etc...) pour trouver la tranche où le code déconne et agir en conséquence.
Mais le debogueur qui permet de connaître exactement les données, ça c'est top.
Dans le Language Qt/C++ que J'utilise actuellement dans mon projet , il n'est plus nécessaire de debugger en utilisant soit le gdb de Linux , ou l'assistant de debugage car le qDebug() fait le travail parfaitement .
Il faut savoir que l'orsque l'on développe un langage on ce retrouve à programmer avec des notions de récursives mutuelles (le fameux recursive descent parser) des arbres de compilation (Abstract Syntax Tree), en objet, des visiteurs à couper au couteau... bref, des structures qui rendent quasi impossible le debuggage.
Effectivement des traces bien placés et bien conçus et surtout un bonne dose d'intuition (qui tiens parfois plus de l'hésothérisme que de la logique mathémarique que nous connaissons) sont souvent les seuls outils qui soit pratiquable.
Parce qu'un breakpoint dans une pile d'execution d'une centaine d'étages, ça fait relativement mal à la tête, et n'aide en rien à comprendre le problème.
Retrouvez tous mes tutoriels : http://caron-yann.developpez.com/
Et mon projet en cours : Algoid - programming language
N'oubliez pas de consulter les FAQ Java (http://java.developpez.com/faq/) et les cours et tutoriels Java (http://java.developpez.com/cours/)
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Discussion intéressante.
J'utilise un débogueur interactif depuis toujours, et je programmerai difficilement sans.
par contre, j'ai rencontré un autre de ces gourous de la programmation. Il est l'auteur unique d'un énorme logiciel de calcul numérique. Nous avons travaillé ensemble sur quelques projets. je l'ai donc vu travailler dans son quotidien. J'ai été très surpris de sa pratique de la programmation totalement à l'opposé de la mienne : il édite ses sources avec vi (éditeur de texte en ligne de commande de Linux) et ne se sert pas de débogeur.
Autre différence d'avec moi : il n'a pas BESOIN d'un débogueur.
La seule explication que je vois est donc une plus grande capacité à se représenter mentalement la "géographie" de son projet.
"La vraie grandeur se mesure par la liberté que vous donnez aux autres, et non par votre capacité à les contraindre de faire ce que vous voulez." Larry Wall, concepteur de Perl.
Disons qu'à mon avis (même si je ne sais pas de qui tu parles, je pratique comme ça et ai vu pratiqué tout un tas de gens), il y a la superposition de cet effet que tu mentionnes et de la bonne connaissance du langage utilisé, ainsi que de ses "types" d'erreurs..
Quand tu connais la "géographie" précise de ton projet, et que tu vois une erreur apparaître, et si tu as une bonne maitrise de ce que je mentionne plus haut, à de très très rares exceptions près tu sais immédiatement où chercher.... Non seulement quelle portion du code, mais également quel type de chose vérifier..
Du coup, soit juste en re-regardant le code en ayant ça en tête, ou juste ajouter 2 ou 3 petits traces et refaire un run te donne la solution dans 99.99% des cas..
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Ca à mon sens c'est un truc de nerd pour impressionner les filles (les les collègues par la même occasion).
Ca et le "je te sort un GREP de fou sans les mains"
Ca n'indique en rien la capacité du développeur.
C'est plus dure, ça entraine la tête, je suis d'accord, mais ça n'apporte que ça. Ca fait surtout perdre du temps.
Pour en revenir au debugger, je pense qu'il ne permet pas de donner une visibilité suffisante dans plusieurs cas :
- Récursives à outrance (et là on parle d'algorithmes mutuellement récursifs (d'ou leurs noms : recursif descent parser))
- Temps réel et Threads.... là on oublie carrément parce que ça fausse la donne.
D'ailleurs dans mon projet Algoid (je suis en mode pub puisque je l'ai mis sur le playstore ce matin, veuillez m'en excuser) mais la grosse difficulté à été de synchroniser le debugger avec les différents threads.....
Et sur android les Handler et le ThreadMain, c'est l'angoisse.
Retrouvez tous mes tutoriels : http://caron-yann.developpez.com/
Et mon projet en cours : Algoid - programming language
N'oubliez pas de consulter les FAQ Java (http://java.developpez.com/faq/) et les cours et tutoriels Java (http://java.developpez.com/cours/)
Quand ce sont des personnes de 45 ans ou plus, ou des gens mariés et très heureux en ménage, qui le font, c'est pas pour "impressioner les filles"...
Et ça va plus vite quand tes mains ne quiitent pas le clavier pour aller vers une souris.. ça par contre c'est une mesure bien connue de l'ergonomie..
C'est purement une question d'habitude...
(comme les secrétaires allaient très vite avec WordPerfect, et toutes les touches e fonctions préprogrammées)
Bref, retourne ta langue sept fois dans ta bouche avant de parler..
Merci
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Je prenait pour exemple quelques jeunes lurons de ma connaissance....
Je n'y voyait pas un conflit générationnelle et ne pensait pas par là heurter ni déclencher des polémiques.
Je reste toutefois persuadé qu'avec une certaine complexité de projet, comme la multiplication (voire la génération spontanée) de fichiers comme en java, ça deviens vite un peu casse tête non ?
Je reste donc pragmatique et essaye toujours d'employer l'outil qui me simplifiera le plus la vie. Comme ça je peu concentrer mes 3 neurones sur les problèmes qui valent réellement la peine qu'on s'y penche.
Genre Java -> Netbeans
txt, ini, regex -> textpad
ect.... ect...
Retrouvez tous mes tutoriels : http://caron-yann.developpez.com/
Et mon projet en cours : Algoid - programming language
N'oubliez pas de consulter les FAQ Java (http://java.developpez.com/faq/) et les cours et tutoriels Java (http://java.developpez.com/cours/)
Le dernier projet que j'ai vu, environ 2 millions de lignes, 10 softs communiquant en TR via réseau (de la reconnaissance vocale, de la synthèse vocale, de la simulation de vol, de la simulation d'environnement 3D, de la simulation radar, de la simulation météo, plus de l'évaluation TR des élèves, et quelques autres "petits" trucs), agrément militaire (formation des contrôleurs du ciel) , environ 3000 fichiers sources, tous les gens utilisaient Vim... y compris des jeunes.. tranche d'âge de 24 à 49 ans.. programmation ou débogage.. avec une rapidité déconcertante..
Juste pour dire que ce que tu as mentionné était faux et une idée préconçue..
Maintenant, je suis d'accord avec toi (il me semble que je l'avais mentionné plus haut) pour le déboggage de serveurs, de TR, de récursivité ou d'algos complexes...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Vrai que je n'ai jamais travaillé sur linux. Tu doit donc avoir raison sur ce point.
Quand j'aurai un peu de temps j'y jetterai un oeil, histoire de ne pas rester idiot.... lol.
Je reste persuader que ça ne doit quand même pas faciliter la vie tout ça.
Mais n'entrons pas dans une polémique stérile !
Retrouvez tous mes tutoriels : http://caron-yann.developpez.com/
Et mon projet en cours : Algoid - programming language
N'oubliez pas de consulter les FAQ Java (http://java.developpez.com/faq/) et les cours et tutoriels Java (http://java.developpez.com/cours/)
Pour moi, c'est presque le contraire utiliser un debug, c'est pas toujours possible et, quand tu travailles dans différents langages/technos, pas toujours facile de "mettre tout en branle" alors qu'un simple print/dump est accessible partout. Peut-être aussi parce que j'ai fait pas mal d'exploitation, langages de script, shell ... validation de code existant en production ...
Ok, bientôt 50 ans :-) suis plutôt de l'ancienne école, j'ai souvent des regards bizarres autour de moi quand on me voit ouvrir un vi. Je n'utilise un "IDE" que lorsque j'ai "beaucoup de code" a saisir, et même, je vais travailler "par petits bouts" pour valider puis intégrer cherchant toujours des solutions pour extraire un code de son "contexte". J'ai une sainte horreur du code écrit et non validé dix fois "point par point", jusqu’à un simple 1+1 qui ne fonctionne pas toujours tel qu'on le croit et je m'inquiète toujours de constater qu'un bout de code marche "tel quel" sans avoir a le retoucher, j'ai quelques mauvais souvenirs de bugs surprises de n'avoir pas passé suffisamment de temps a retravailler un code.
Ca donne de fait une culture de "tests unitaires" même s'ils sont quelque peu improvisés, mais j'ai vu a contrario des "pro de l'IDE" nous balancer du code en production sans avoir validé les mécanismes élémentaires, persuadés que leur truc marchait sans problème. Le souci des outils, c'est que trop souvent ils donnent l'illusion que tout roule et font perdre, de mon point de vue de "vieux", quelques bons réflexes salutaires.
Par contre très décevant de voir des développeurs ne même pas connaitre trois commandes de base de vi, pas plus une regexp pour un simple grep ou le moyen de lancer une bête requête SQL "en direct".
En faite hein! c'est pas que ca facilite pas la vie, car effectivement tu n'as pas essayer. et je vais te dire la verite, quand j'ai commencer a utiliser VIM c'etait il y a longtemp justement pour frimer. et je ne le trouvais pas du tout pratique.
puis je me suis rendu compte avec le temps que comme dit souviron, garder les mains sur le clavier ca va tres vite. mieux: le deplacement sur une ligne est magnifique surtout quand tu codes.
le probleme se trouve au moment de l'apprentissage car tu trouveras plus simple de selectionner ce qui se trouve entre { et } puis commencer a taper ton code plutot que de faire
c i { et tapper ton code pour la bonne et simple raison que tu reflechiras. mais pour quelqu'un qui l'a comme reflex, et qui n'a pas besoin de reflechir pour chercher la commande avoue que c'est plus rapide de taper 3 touches sur le clavier pour remplacer toutes une section de code plutot que de prendre la souris pour selectionner non?
sinon , non utiliser vi ca rend pas plus intelligent et en plus les filles s'enfoutent.
Petit lien vers mon premier jeux SDL2/C
http://store.steampowered.com/app/72..._Soul_Of_Mask/
la suite? ca vient,ca vient!
Il faut bien préciser: quand tu as l'habitude. Je trouverais toujours plus efficace de naviguer dans un fichier a coup de :<nro de ligne>, /<reg exp> et autre $, set nu, suppressions, copy paste & co, des search/replace globaux. Je ne compte pas le nombre de fois où j'insère des "i" et des ":wq" dans un éditeur de texte "classique"
Vrai que de l'extérieur, ça fait un peu "magie noire"
Toutefois, hors "petites modifs", avec navigation dans un nombre de sources importants (surtout si pas à toi!), je travaille bien entendu avec un IDE (même si Netbeans me fait sérieusement c... a mettre des séparateurs a ma place ...), ce qui n'empêche d'ouvrir un terminal "au cas où" ...
Concernant ce point, les unitaires doivent impérativement être automatisés.... sinon impossible de refactorer serieusement.
Je viens de me cogner l'écriture d'un langage tout entier... sans unitaires il n'aurait jamais vu le jour. Le nombre de fois ou ça m'a sauver la vie.
Donc pas de debug, plein de traces, des toStrings bien explicites et des unitaire (acceptence testes) dans tous les coins.....
Le backtracking n'avait qu'à bien ce tenir.
Je connais aussi le tout au clavier, puisqu'avant de reprendre des études, je faisait pas mal de 3d et je modélisait avec Wings3d.... pratiquement tout au clavier, sauf les déplacements.....
C'est radicale comme ça m'a augmenter l'efficacité... Donc je peu comprendre l'idée....
Cela dit j'utilise NB, et question souris je ne la touche que pour ouvrir un fichier, sinon tout le reste en [ctrl] [alt] i.....
Je croie que c'est un guerre de clocher que j'ai déclenché là.....
Retrouvez tous mes tutoriels : http://caron-yann.developpez.com/
Et mon projet en cours : Algoid - programming language
N'oubliez pas de consulter les FAQ Java (http://java.developpez.com/faq/) et les cours et tutoriels Java (http://java.developpez.com/cours/)
Tu bosses sur des trucs 100% techniques, manifestement. Dans ce cadre, tu as surement raison. Quand on fait essentiellement du fonctionnel(dans le sens "métier", pas dans le sens "langage fonctionnel"), on aimerait bien avoir 100% de couverture automatique, mais c'est pas toujours possible.
(1)==>Par exemple parceque les normes de sécurité interdisent d'avoir un environnement de test "réaliste"(avec tous les référentiels qui vont bien).
(2)==>Ou parceque le fonctionnement de l'appli est asynchrone. Exemple vécu : on développe une appli pour saisir l'argent des gens qui ont fait des excès de vitesse, et qui ne les ont pas payés. L'appli emet donc un mouvement comptable. Qui(c'est le fonctionnement de la plupart des banques) sera pris en compte pendant la nuit, avec résultat dans l'appli le lendemain matin.
Mon cas 2 est absolument impossible à automatiser. Il se passe une nuit complète(et les traitements sont vraiment longs, même en homologation) entre le moment ou on génère le mouvement, et le moment ou il a un effet retour dans l'application. La personne en charge avait mis en place une classe de test qui vérifiait le mouvement envoyé à la compta, mais il était inconcevable de déclencher "sur mesure" le traitement comptable de la nuit. Donc, c'était moi, petit homologateur, qui allait regarder le lendemain que l'appli trouvait bien le nouveau niveau attendu. Avec pas mal de surprises, je dois le dire.
Maintenant que je suis retourné au développement, je tente de mettre en place ce genre de chose, mais en COBOL/MVS, c'est, euh, pas la culture ni la technologie. Et, nous sommes toujours bloqués par les référentiels des autres : si un client change, notre cas automatique est planté. Bon à refaire.
En d'autres termes, tu as raison, mais ça ne s'applique hélas pas partout.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Pas de guerre, chacun trouve ses propres automatismes (d'ailleurs amusant de voir comment en vi, on a chacun les siens :-)), mais je trouve un avantage au "rase motte", celui de garder pied avec son code et j'ai finit par prendre l'habitude de tout vérifier pas à pas. C'est bien souvent quand tu baisses la garde, genre "petite modif" dans un coin que tu fais sans douter et qui te met le binz dans toute ton appli.
Pas toujours possible, mais mon approche dans ce cas là sera d'essayer de "mocker" le composant externe et là encore, je vais souvent faire du "ligne a ligne". Quand je parle plus haut de "fou de l'IDE", j'ai vu du code passer en prod sur la simple base de la lecture d'une spec! mais bon, je finis par me dire que je n'ai pas encore tout vu les développeurs sont pleins de ressources insoupçonnées!
Pour rebondir sur les tests de CyaNnOrangehead, j'ai même eu parfois la bonne idée d'en intégrer en prod (je parle "d'évidences" qui n'en sont pas toujours), ça m'a moi aussi sauvé la vie, mais il faut dire que j'étais aussi coté exploitation
C'est l'éternel combat de l'abstraction contre la maitrise. L'abstraction augmente la productivité, parfois de manière drastique, mais possède toujours des fuites.
Euh, voyons, la compta d'une banque, c'est des centaines de JCL(scripts), des milliers de programmes, avec un ordonnancement précis. Avec des dizaines de subtilité par programme, et un blocage au moindre poil fourmi de travers.
Non, on oublie l'automatisation pour le test de bout en bout.
ça, c'est plus génant. récemment, j'ai pratiqué(à mon grand regret), vu que les environnements de test ont été vraqués à des niveaux intolérables(sous pretexte de sécurité); enfin, j'ai quand même testé unitairement, mais l'absence de tests de bout en bout a fait du dégât. Prévisible. La collègue sur qui le gros des soucis est tombé, accusée ne ne pas avoir fait son boulot, a renvoyé toute la hiérarchie sur les roses - avec raison.
Moi aussi. Avec une variante : quand je reçois de la merde, la specification disait "plantez". Sous-entendu, le programmeur(moi) réparera les conneries de la MOA. Au lieu de planter, j'envoie un joli message "Merci de re-emettre un fichier en corrigeant les erreurs suivantes", et je replanifie la reception. Depuis, je n'entends plus parler de tous ces plantages.
encore plus amusant : je leur en ai parlé des dizaines de fois, ils ont toujours refusé. Quand je les ai mis devant le fait accompli, ils ont demandé plus de détails dans le message.....
Mais là, je pouvais.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager