djano a écrit 1147 commentaires

Je te remercie de ton commentaire.

C'est grâce à des remarques comme ça (et comme celles de Xavier Poinsard) que le soft progresse et devient plus abordable.

Un grand merci à vous!

Tu as raison, la documentation est importante, et c'est une partie qui a été un peu délaissée.
Étant le seul a travailler dessus et ayant peu d'utilisateurs, ce n’était pas une priorité.
Ceci j'ai quand même fait l'effort de mettre beaucoup de javadocs dans le code.

Comme je devais mettre l'update site quelque part, il me fallait un serveur web. Je ne sais plus pourquoi je suis parti sur la solution de mettre la doc sur le serveur web.
Je pense que tu as raison, mais je voudrais quand même pouvoir générer des pages webs à partir de la doc. Je ne suis pas sûr de comment faire ça.

Étant un peu dans le bouillon en ce moment, j'accepte volontiers de l'aide :)

Mon message est simplement que d'aller de travailler à comment la situation peut être résolue, permet de se confronter aux vrais problèmes et donc soit de pouvoir les résoudre, soit d'avoir les cartes en main pour dire tchao si on est vaincu.

Je suis d'accord avec toi que c'est la meilleure solution dans certaines situations. Je pense que beaucoup de situations échappent à une telle solution.

Ne pas être utopique, c'est regarder la réalité en face. Le truc il semble pourri à la base, et n'a aucune vocation à devenir moins pourri. Si tu ne peux pas changer les choses et faire qu'il ne soit plus possible d'hériter d'un gros tas de boue à une échelle de temps qui te convient… casse-toi. C'est mieux à la fois pour toi et faire disparaître les tas boue.

Changer c'est un conseil sympa, mais ce n'est pas toujours facile de trouver une endroit où l'herbe est plus verte.

En gros, le schéma de notre conversation c'est:

• Je propose AutoRefactor comme une approche technique pour résoudre un problème.
• Tu arrives en disant que ce n'est pas la bonne façon, et que la bonne manière de faire, c'est de résoudre les problèmes humains/organisationels. (Je ne suis pas sur de comprendre si tu penses qu'AutoRefactor peut être utile ou bien pas du tout?)
• Je te réponds qu'AutoRefactor a une utilité dans les cas où les problèmes ne sont plus humains/organisationels, mais purement techniques.

Une refacto plus importante moins automatisable et souvent avec l'ajout de tests unitaires.
Souvent ce qui fait qu'on écris du code de mauvaise qualité au niveau micro vient d'un problème au niveau macro (on a pas pensé à séparer une partie de la logique dans une classe séparée par exemple).

Ça c'est dans le super cas où on te laisse le temps de le faire, et où tu as les compétences (en programmation, mais aussi métier!) pour le faire, et où tu sais comment faire. Bref ça fait beaucoup de conditions.

De toute façon ne t'inquiète pas: AutoRefactor ne corrige pas tout et ne corrigera jamais tout. Du code qui pue puera toujours. Il piquera juste un peu moins les yeux de ses lecteurs et ils pourront alors se concentrer sur la suite des améliorations. Un refactoring en appelle souvent d'autres.

Moi aussi j'ai été utopique comme toi.

Je pense l'être encore en faisant ce projet, mais différemment.

Libre à toi de te lamenter chaque fois que tu dois modifier du code pourri. Il est pourri et tu veux bien t'en rappeler à chaque fois que tu mets les yeux dedans? Très bien, moi ça ne m'intéresse pas.

OK tu as changé ton organisation et tu as viré tous les mauvais développeurs. Ton management est maintenant super aware que la qualité du code ça roxe les mamans ours. Bon on commence où? Ah merde on a cette bouse qui fait 2 millions de lignes de code qui nous fait vivre mais qui est vraiment pourrie. C'est pas grave on va tout récrire à la mano! N'oubliez pas qu'on roxe grave ici!

Comment ça c'est pas réaliste? Ah ben merde ça arrive tous les jours de travailler sur du code dont les auteurs ne sont plus disponibles! Je travaille sur un logiciel forké, je vais les mettre à qui les coups de pieds au cul? Tu hérites d'un logiciel outsourcé, tu fais comment?

Pour le passage aux generics dans Java 5, tu as chamboulé ton organisation pour adapter la base de code? J'espère que tu t'es bien amusé dans les meetings.

Ton code provient de la traduction d'un logiciel cobol, tu réécris tout? Avec de nouveaux bugs aussi? Comment tu fais si c'est pas toi qui décide?

Ça t'arrive jamais de relire ton code et de te demander si tu étais pas bourré quand tu as écris ça? Ou bien même de regarder du code en te disant "p***** j'y comprend rien, qui a écrit ce code à la c*? M*** c'est moi!" Si tu me repond non, je ne te crois pas.

 

Bref ton commentaire me gave: ta solution n'est pas applicable à tous les cas et penser que c'est la seule solution me paraît aussi ridicule que de penser qu'AutoRefactor va résoudre tous les problèmes.

AutoRefactor est juste un outil qui ne prétend pas remplacer les autres approches. Si l'approche ne te plais pas, tu es libre de ne pas l'utiliser. Merci de ne pas dégoûter les autres qui se battent avec les armes dont ils disposent.

Pas de souci, je ne prétends pas convaincre tout le monde :)

Expérience personnelle: on ne choisit pas toujours avec qui on travaille et certains de mes ex collègues ne semblaient pas progresser sur ces sujets, malgré tous mes efforts. Du coup j'ai arrêté de croire que je pouvais tous les changer. J'ai alors cherché à pouvoir rapidement corriger le code.

On m'a fait la même remarque que toi par ailleurs. Une solution serait de surligner le code avec des warnings ou des erreurs directement dans l'IDE. Je n'ai pas pris le temps de le faire car les même ex collègues m'ont montré qu'ils ignoraient royalement les informations de deprecation. Oui je suis devenu pessimiste par la force des choses. J'ai heureusement changé de boulot depuis.

Souvent la multiplication des erreurs de ce type me permet d'identifier des parties du code qui ont plus de problèmes qu'une simple question de syntaxe (des fonctions mal découpées, etc)

Et alors, que fais-tu avec cette information?

Tu étais présent à Grenoble? Ç'aurait été sympa de te rencontrer!

Ça y est, j'ai implémenté les tooltips: https://github.com/JnRouvignac/AutoRefactor/issues/129 .

J'ai aussi posté une nouvelle nightly si tu veux essayer.
Il y a aussi la correction pour https://github.com/JnRouvignac/AutoRefactor/issues/128 .

Ce vilain bug m'a piqué au vif.
Je ne pouvais pas laisser traîner ça!

Merci de l'avoir essayé :)

Libre à toi de ne l'utiliser que fichier par fichier si c'est ce que tu préfères.

Mais j'avoue que je ne comprend pas tes réticences à le faire tourner sur toute ta base de code. As-tu peur d'avoir trop de changements à revoir?

Dans ce cas d'utilisation, je conseille de ne jamais appliquer tous les refactorings à la fois sur une base de code. La diversité et le nombre de changements rendrait quasi impossible la revue de ces changements.
C'est mieux de faire ceci: prendre une règle, faire une passe sur toute la base de code, valider manuellement les changements, puis les committer (soit tous les fichiers d'un coup, soit petit à petit).

C'est ce que je fais sur OpenDJ, et les seuls soucis que j'ai, c'est quand je fais un refactoring à la main :)

 

Une entreprise m'a contacté pour utiliser AutoRefactor pour faire le post-processing d'un processus de transcompilation COBOL vers Java. Le code généré par le transcompilateur est tellement moche et volumineux (plusieurs centaines de milliers de lignes de code) que c'est la solution la moins coûteuse en temps de travail pour qu'ils finissent par avoir un code maintenable.

Tu veux dire lorsque l'on choisit le refactoring à appliquer?
Je vais voir si je peux faire ça.

Le tooltip serait une première étape vers ce bug report lié:
https://github.com/JnRouvignac/AutoRefactor/issues/127

PS: merci pour le bug report, c'est corrigé :)

Je pense que le plus simple est de regarder la page avec les exemples de test:
http://autorefactor.org/html/samples.html

La liste déroulante contient les règles de refactorings implémentées.

Est ce que ça te suffit ou bien est ce que tu cherches quelque chose d'autre?

D'ailleurs, c'est bien pour ça que chaque règle de refactoring d'AutoRefactor a plusieurs tests unitaires.
Du coup j'ai 100% confiance que lorsque je change le code du plugin, je n'introduis aucune régression dans les cas de tests connus.

Les problèmes se trouvent généralement dans ce qui n'est pas couvert par la suite de tests :)

Tout à fait, les tests unitaires augmentent la confiance pour faire toute sorte de changements, et en particulier le refactoring. Surtout lorsque le refactoring massif :)

J'ai oublié de le préciser, merci d'en parler.

pour nous parler de de POMM

un "de" en trop?

C'est rigolo, tu utilises Launchpad pour gerer le projet et github pour le site web.
C'est pour des raisons historiques?

Oui c'est ce que je voulais dire.
Merci de ta précision :)

Un autre. Voir: https://blog.golang.org/gccgo-in-gcc-471

À noter que les deux compilateurs gc (compilateur officiel) et gccgo (frontend go pour gcc) sont gérés par le projet golang. gc est plus rapide alors que gccgo compile sur plus d'architectures et produit un code bien plus optimisé.

Vous pouvez éditer cette partie en cliquant sur le crayon !

Petit oubli lors de l'édition?

Debian (qui qui vient

Debian (qui vient

puisque qu'une

puisqu'une

Tu as tout a fait raison pour la pyramide des tests et sur le fait que ce ne sont pas des tests unitaires.

Cependant, il faut comparer cette solution avec l'existant a base de vérifications manuelles.
Je trouve que l'approche présentée par Landry MINOZA permettrait d'avoir des aujourd'hui des tests automatisés, bien plus sûrs et rapides que les vérifications manuelles. Certes ce n'est pas l’idéal, mais ce serait déjà un grand pas en avant à mon humble avis.

Lorsque le code s'y prêtera mieux (avec un bon design comme tu le soulignes), alors il sera toujours possible de passer sur des tests vraiment unitaires.
Mais ce jour n'est pas encore là.
D'ailleurs c'est un des buts du financement participatif présenté dans la dépêche.

Bonne idée pour les tests unitaires.

Bravo pour ton travail Olivier!
Bravo pour la dépêche très détaillée!

En plus, tu as devancé ma question sur la comparaison avec LanguageTools :)

C'est rigolo, il y a un gros parallèle entre ce que tu fais et ce que je fais (http://linuxfr.org/redaction/news/modernisez-votre-code-java-en-un-clic-avec-autorefactor-v1-0-0, hum dépêche à compléter).
J'ai la chance de pouvoir travailler sur un langage informatique d'où une syntaxe très bien définie (je ne parle pas du C++ ;) ). Je peux m'appuyer sur Eclipse JDT pour les analyses lexicales, syntaxiques et sémantiques (analyse des types, des variables, etc.).
Malheureusement, la langue naturelle n'est pas aussi logique, et le processus classique des compilateurs ne fonctionnent pas ou difficilement.
Je te tire mon chapeau pour oser t'attaquer à ce problème très difficile.

Ton analyse en plusieurs passe qui transforme le texte est une idée très intéressante pour palier aux multiples formes que permet un langage naturel. Merci d'en avoir expliqué le concept.
Comme tu l'as fait remarquer, j'y vois hélas un inconvénient majeur: c'est lorsqu'il s'agit de rapporter les erreurs sur du texte modifié.
Les compilateurs transforment plusieurs fois le code source en interne pour finalement parvenir à générer du code. GCC a au moins 3 représentations internes: GIMPLE => GENERIC => RTL .
Pour pouvoir correctement rapporter les erreurs a n'importe quel moment de la phase de compilation, il est impératif de pouvoir toujours revenir vers le texte initial en gardant des marqueurs ou des informations de localisation sur le texte source original. C'est aussi ce qui est fait dans le code généré pour pouvoir se référer au code source original lors de séances de débogage (Voir DWARF ou les source maps en javascript).
C'est comme ça que le problème est résolu dans les compilateurs. Je ne sais pas si c'est applicable a ton cas ou bien si cela ferait exploser la consommation mémoire, mais bon je me suis dit que ça pourrait être utile d'en parler.

Sur l'utilisation des expressions rationnelles, je sais a quel point cela peut être difficile. J'ai commencé comme ça avant de créer sur AutoRefactor a cause de la difficulté a les utiliser correctement et a les maintenir. Elles sont souvent imprécises (la plupart de l'espace pris par une regexp c'est uniquement pour la gestion des espaces), complètement ignorante de la sémantique de ce qu'elles traitent (pas d'informations de type!) et redondantes (Comment reconnaître a == b et b == a? Réponse: 2 regexps avec duplication de code. grmbl!.
Je pense que tu dois passer beaucoup de temps a les mettre au point. Tu as beaucoup de courage.

La ou je te plains, c'est que tu n'as pas de tests unitaires :(
J'ai commence par un truc sale pour faire les tests: un booléen dans le code du plugin qui exécute les tests sur des exemples de code: Je lançais Eclipse sur le projet avec les exemples. Si la variable booléenne test valait vrai, alors le plugin parcourait le projet pour trouver les exemples avec le code d'entree et le code en sortie, il appliquait les transformations et vérifiait que le résultat final était obtenu. Il affichait alors une fenêtre avec les résultats.
S’était bien, mais lorsque j'ai pu automatiser les tests avec JUnit dans le processus de production (build en anglais), et bien ma productivité a été décuplée et j'ai pu ajouter beaucoup plus de regles avec une grande confiance sur l’absence de régressions.
Je t'encourage a faire ça en premier, c'est une investissement qui vaut vraiment le coup. Le temps passé dessus est récupéré plusieurs fois au fil du temps.

Finalement, je vois que tu as créé un outil que l'on retrouve dans le développement: un formatteur. De même dans l'Analyse statique de programmes, on retrouve le problème des faux positifs.
Comme je l'ai déjà dit, les parallèles sont rigolos :)

Encore une fois bravo pour ton courage et ta motivation!

Refactoring du chargement des applications

Le chargement des applications a été réécrit. Cette réécriture permet d'améliorer les points suivants :

Grrr, une réécriture n'est pas du refactoring!

Le refactoring c'est une suite de changements simples et sans risques (ou presque) faits de manière incrémentale et qui ne modifie pas le comportement observable du code.
Une réécriture, c'est abandonner l'ancien code et le réécrire de zéro (ou presque), en oubliant les anciens bugs et en en créant de nouveaux, ce qui bien sur modifie le comportement observable du code.

Ça n'a franchement rien a voir!
Dans un cas, évolution du code, dans l'autre, jetage de bébé avec l'eau du bain!

Pourquoi tu dis ça? C'est interdit les accords amiables en France pour terminer un procès?