Le 22 mars 2015 est sortie la version 1.0.0 du projet AutoRefactor. Ce logiciel est publié sous Eclipse Public License v1.0 et GNU General Public License v3+.
AutoRefactor restructure automatiquement le code source d'un programme Java afin de :
- Faciliter la maintenance en améliorant la lisibilité
- exemple : lorsque toutes les branches d'un
ifont les mêmes instructions à la fin des blocs, celles-ci sont déplacées après leif, …
- exemple : lorsque toutes les branches d'un
- Moderniser le code
- exemple : passer des APIs de java.util.Vector vers celle de java.util.List, …
- Appliquer les bonnes pratiques
- exemple : utilisation d’accolades après un
if, javadoc bien formés, bonne utilisation des APIs de BigDecimal, TestNG, …
- exemple : utilisation d’accolades après un
- Réduire la taille du code
- exemple : un
ifimbriqué dans un autreifdevient unifunique, suppression des variables locales déclarées juste avant unreturn, …
- exemple : un
- Améliorer les performances
- exemple : utiliser Integer.valueOf(int) au lieu de new Integer(int), …
Sommaire
Historique
J'ai commencé ce projet car j'en avais assez de faire les mêmes changements manuellement (ou semi-manuellement avec les refactorings proposés par Eclipse) dans tous les fichiers sur lesquels je travaille. J'ai commencé par utiliser des expressions rationnelles pour retravailler toute la base de code, mais les faux positifs étaient bien trop nombreux, et puisque les expressions rationnelles ne travaillent que sur du texte, toute analyse s'appuyant sur la sémantique du langage (types, variables, etc.) est impossible.
J'ai donc fait diverses expérimentations pour pouvoir faire des analyses « comprenant » le langage. Hélas toutes ces expérimentations ont raté.
Toutes, jusqu’à ce que je crée un greffon Eclipse s'appuyant sur l'API des Java Development Tools (Eclipse JDT). Cette dernière fournit un parser, mais surtout une API pour faire des refactorings. En fait, c'est l'API que l'IDE Eclipse utilise pour ses propres refactorings.
Utilisation
Depuis l'interface d'Eclipse, le développeur sélectionne les fichiers, packages ou projets Java à restructurer, et lance la réorganisation automatique du code. Pour cela, il choisit l’entrée AutoRefactor dans le menu contextuel accessible par un clic doit, ou bien il tape le raccourci clavier Alt+Shift+Y.
Le greffon AutoRefactor restructure alors le code en appliquant automatiquement les refactorings choisis par le développeur.
Principe de fonctionnement
Les restructurations de code sont implémentées par des refactorings successifs, c'est-à-dire des petits changements incrémentaux qui modifient le code sans changer son comportement à l'exécution. Ceci est vrai pour la plupart des refactorings, ceci dit, certains peuvent avoir des effets de bord (voir ci-après), mais un programme sensible à ces changements s'expose à des comportements indéfinis lors de l’exécution.
Système de passes successives
Le greffon travaille avec un système de passes successives. Lorsque le développeur a choisi les règles de refactoring à appliquer, le greffon prend la liste des refactorings et (algorithme simplifié) :
- le fichier Java à analyser est parsé et produit un arbre syntaxique abstrait (AST en anglais)
- pour chaque refactoring :
- cherche des opportunités de refactoring en visitant l'arbre syntaxique abstrait
- génère les réécritures de code lorsqu'une opportunité de refactoring a été identifiée
- lorsque tout l'arbre syntaxique abstrait a été visité, si des réécritures de code ont été générées :
- alors, toutes les réécritures de code générées sont appliquées sur le fichier
- le fichier est sauvegardé
- boucle vers 1.
- sinon, fin : il n'y a plus de refactorings possibles sur ce fichier Java
Actuellement, tous les refactorings implémentés font du filtrage par motif (pattern matching) et travaillent fichiers par fichiers.
Du coup, il est extrêmement facile de paralléliser le code : le greffon lance autant de fils d’exécution en arrière-plan qu'il y a de processeurs disponibles et utilise une simple liste de tâches pour leur fournir du travail. Chaque tâche consiste à analyser et restructurer un fichier Java.
Bien sûr, le greffon dispose d'une suite de tests composée de paires de fichiers exemples Java : un fichier avant restructuration, un autre fichier contenant le résultat que l'on souhaite obtenir après restructuration. La suite de tests unitaires exécute chaque règle de refactoring indépendamment sur sa paire de fichiers et compare la sortie attendue avec la sortie obtenue. Les deux doivent correspondre. La compilation et les tests unitaires sont exécutés sur un serveur d’intégration continue.
Je vous encourage très vivement à regarder les exemples tirés de la suite de tests.
Par ailleurs, je teste plus avant les refactorings sur la base de code mature d'OpenDJ. Cela me permet de trouver pas mal de bugs avant qu'ils n'atteignent une version stable et donc de rajouter des cas de tests. Le code mature est bien plus sournois que les cas de tests auxquels on peut penser ! :)
Attention ! Il faut toujours relire le code modifié automatiquement avant de committer les changements !
En effet, voici un exemple de code pour lequel les changements ont modifié le comportement :
Integer i1 = 0;
Integer i2 = new Integer(0);
if (i1 == i2) { // compare des références d'objets !
System.out.println("OK");
}Ici, "OK" n'est pas affiché sur le terminal car i1 et i2 sont deux objets différents en mémoire.
Maintenant si AutoRefactor modifie le code comme ceci :
Integer i1 = 0;
Integer i2 = Integer.valueOf(0);
if (i1 == i2) { // compare des références d'objets !
System.out.println("OK");
}"OK" sera affiché sur le terminal car i1 et i2 référencent le même objet en mémoire.
Comment est-ce possible ? Et bien la ligne Integer i1 = 0; est en fait générée comme ceci par le compilateur java : Integer i1 = Integer.valueOf(0);. De plus il existe un cache pour les objets Integer entre -128 et 127 (inclus), ce qui fait que i1 et i2 référencent le même objet en mémoire.
Ce code aurait probablement du être écrit comme ceci :
int i1 = 0;
int i2 = 0;
if (i1 == i2) { // compare la valeur des entiers !
System.out.println("OK");
}Et le code aurait correctement affiché "OK" sur le terminal.
AutoRefactor ne sait pas encore le faire, mais j’espère y arriver un jour.
Cet exemple démontre que certains refactorings ne préservent pas totalement le comportement lorsque le code s'appuie sur des comportements « limites » de Java.
Cependant il est possible que ce soit bien le comportement désiré par le programmeur.
C'est pourquoi il est recommandé de toujours relire les refactorings automatiques avant des les committer dans le gestionnaire de sources. Vous utilisez bien un gestionnaire de source, n'est-ce pas ?
De la difficulté d’écrire des outils automatiques dans un monde subjectif
Après avoir mis ce gros bémol, je tiens à signaler que j'essaie d’avoir un résultat final propre et logique. Je suis pragmatique : soit j'essaie absolument de préserver le comportement du programme, et dans ce cas, je ne fais presque rien ; soit je prends des risques « mesurés » en ignorant les cas « bêtes » comme celui-ci dessus, et alors j'autorise beaucoup plus de possibilités de refactorings.
C'est un équilibre dur à trouver dans certains cas tel qu'illustré par la méthode isHardToRead(). Bien sûr, c'est éminemment subjectif, mais puisque c'est moi qui code, j'impose mes idées. :) Plus sérieusement, si vous pensez que j'ai tort, je suis ouvert à discussion.
J'avais d'ailleurs pensé rajouter une préférence pour forcer à préserver le comportement, mais j'ai renoncé lorsque je me suis rendu compte du nombre de refactorings que cela interdirait. Par exemple, un code aussi simple que celui-ci :
System.out.println("this is " + obj.toString());ne pourrait plus être réécrit comme ceci :
System.out.println("this is " + obj);En effet, on perdrait la vérification sur référence nulle. Si obj est null, la première écriture lève une NullPointerException, alors que la deuxième écriture imprime "this is null". Bien sur, il serait peut-être possible de détecter qu'obj n'est pas null en faisant une analyse du flot de contrôle (j'ai bien dit peut-être), mais cela nécessite des outils dont je ne dispose pas encore. Par pragmatisme, j'ai simplement considéré que s’appuyer sur un appel à toString() pour détecter une référence nulle était une mauvaise pratique dans ce cas, et j'ai quand même écrit la règle qui fait cette réécriture :)
Futur
Même si tous les refactorings actuellement implémentés font du filtrage par motif, j’espère bien parvenir un jour à faire de l'analyse de flot de contrôle en construisant un graphe de flot de contrôle (CFG an anglais). Ceci permettrait d’écrire des refactorings comprenant les chemins d’exécution du code, comme le ferait un développeur qui lirait du code. En particulier, il deviendrait possible de réduire la portée des variables, comprendre quels chemins d’exécution du code sont morts (impossibles à atteindre)
J'aimerai aussi développer une autre fonctionnalité : l'extraction (semi-?)automatique de méthodes.
Voici un exemple de code que je vois trop souvent :
// ... quelques dizaines / centaines de lignes de code
boolean found = false;
for (String s : strings) {
if (toFind.equalsIgnoreCase(s2)) {
found = true;
break;
}
}
if (found) {
// faire quelque chose
}
// ... quelques dizaines / centaines de lignes de codeComment simplifier cette longue méthode ?
En extrayant une nouvelle méthode, comme ceci :
// ... quelques dizaines / centaines de lignes de code
if (containsIgnoreCase(strings, toFind)) {
// faire quelque chose
}
// ... quelques dizaines / centaines de lignes de code
}
private boolean containsIgnoreCase(Collection<String> strings, String toFind) {
for (String s : strings) {
if (toFind.equalsIgnoreCase(s2)) {
return true;
}
}
return false;
}La plus grosse difficulté, c'est de savoir comment nommer la nouvelle méthode, et un humain doit intervenir, d’où le coté semi-automatique.
Le support de Java 7 arrive doucement avec le support de refactorings générant l'opérateur diamant '<>' (pas de besoin de répéter les types génériques), et le multi-catch (pas besoin de copier-coller le même bout de code dans deux blocs catch différents).
Par exemple, le code suivant :
List<String> strings = new ArrayList<String>();
try {
// plus de code
} catch (IllegalArgumentException e) {
e.printStackTrace();
} catch (NullPointerException e) {
e.printStackTrace();
}Peut être réécrit comme ceci en Java 7 :
List<String> strings = new ArrayList<>();
try {
// plus de code
} catch (IllegalArgumentException | NullPointerException e) {
e.printStackTrace();
}La version 1.1.0 à venir a beaucoup de bonnes et nouvelles choses disponibles. Je vous conseille de l'installer depuis les nightlies.
Appel à contributions
J’espère que la présentation de ce greffon vous aura intéressé.
Si vous êtes un développeur Java, je vous encourage à l'installer :
- Depuis l'update site http://autorefactor.org/releases/
- Depuis l'Eclipse marketplace:
- Pour les aventureux, installez une nightly depuis l'update site http://autorefactor.org/nightly/
Si vous êtes vraiment enthousiasmés et que vous voudriez l’améliorer ou l'adapter à vos besoins, n’hésitez surtout pas ! Envoyez des rapports de bugs, des pull-requests, interagissez sur gitter, etc.
Si vous voulez aider, mais que vous êtes à court d’idées, voici une petite liste :
- Testez le logiciels sur de grosses bases de code anciennes. C'est là où se cachent les surprises. :)
- Je suis aussi intéressé par des retours d’expériences, blog posts ou autres… Faites connaître ce greffon auprès de vos collègues !
- J'ai plein d’idées dans le bug tracker, mais pas assez de temps pour les implémenter. Si jamais le cœur vous en dit…
- Le site web est moche, et a besoin d'amour
- Le greffon n'a pas encore de logo malgré mes misérables tentatives.
Je m'amuse bien à réécrire le code automatiquement. Franchement, ce n'est pas trop difficile ou trop long d'ajouter de nouvelles règles, alors n’hésitez pas à vous lancer ! Je vous aiderai.
Aller plus loin
- Site officiel (615 clics)
- AutoRefactor sur Github (246 clics)
- Soirée Autorefactor à l'AlpesJUG 24/02/2015 – Le support (143 clics)
- Exemples de restructuration de code effectuées par AutoRefactor (tirés de la suite de tests) (243 clics)
# Et les tests unitaires?
Posté par Toff' . Évalué à 9.
C'est aussi dans ce genre de cas que les tests unitaires sont essentiels.
Perso, je me sens beaucoup plus à l'aise pour me lancer dans du refactoring (manuel ou automatique) quand je sais que mon code est correctement couvert par des tests.
@++
Toff'
[^] # Re: Et les tests unitaires?
Posté par djano . Évalué à 3.
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.
[^] # Re: Et les tests unitaires?
Posté par djano . Évalué à 3.
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 :)
# bravo
Posté par steph1978 . Évalué à 2.
Ça me donne envie de rouvrir mon éclipse tout ça :)
# Liste détaillée des refactorings
Posté par Xavier Poinsard . Évalué à 2.
Y a une liste détaillée de refactorings implémentés ?
[^] # Re: Liste détaillée des refactorings
Posté par djano . Évalué à 4.
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?
[^] # Re: Liste détaillée des refactorings
Posté par Xavier Poinsard . Évalué à 2.
Ça m'ira très bien, mais ce serait pas mal d'avoir, au moins en tooltip, un peu plus de détails dans l'interface du plugin Eclipse.
[^] # Re: Liste détaillée des refactorings
Posté par djano . Évalué à 5.
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é :)
[^] # Re: Liste détaillée des refactorings
Posté par Xavier Poinsard . Évalué à 2.
Oui.
Et bravo pour la correction rapide !
[^] # Re: Liste détaillée des refactorings
Posté par djano . Évalué à 3.
Ce vilain bug m'a piqué au vif.
Je ne pouvais pas laisser traîner ça!
[^] # Re: Liste détaillée des refactorings
Posté par djano . Évalué à 6.
Ç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 .
# Je suis un vieux con
Posté par Hodj . Évalué à 4.
Quand je vois ce genre d'outil (je l'ai même un peu plus que vu, je l'ai installé sur mon Eclipse et j'ai fait quelques test dont le résultat est même plutôt bon), j'ai toujours du mal a y croire (même malgré mes tests encourageant).
Sur le papier, c'est top, à l'exécution, c'est même plutôt bien.
Le faire tourner sur un ou deux sources où c'est facile de relire et de corriger, je ferais surement l'expérience. Par contre, sur une grosse application avec des milliers de classes je ne pense pas que ça soit raisonnable de l'utiliser.
[^] # Re: Je suis un vieux con
Posté par djano . Évalué à 6.
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.
[^] # Re: Je suis un vieux con
Posté par tyoup . Évalué à 1.
Quoi ? Ton code n'est pas couvert à 100% par des tests unitaires ? :-)
# Pas convaincu
Posté par barmic . Évalué à 5.
J'ai vu la présentation que tu as fais à Grenoble et je suis pas vraiment convaincu.
Je préfère des systèmes à la checkstyle qui vont juste gueuler. Pour deux raisons :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par djano . Évalué à 3.
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.
Et alors, que fais-tu avec cette information?
Tu étais présent à Grenoble? Ç'aurait été sympa de te rencontrer!
[^] # Re: Pas convaincu
Posté par ckyl . Évalué à 1.
Tu ne corriges "rien du tout".
Ca me fait un peu penser aux gens qui utilisent des choses comme Sonar pour "gérer la qualité du code". L'analyse statique c'est un outil très pratique pour:
Là tu as l'étape d'après, l'auto-correction. Mais l'auto-correction de quoi ? De problèmes majoritairement syntaxiques ? Si la partie la plus triviale, l'aspect syntaxique, du job est moisie dans quel état est le reste ? Pourquoi la collection des requirements serait bonne ? Pourquoi l'architecture/design serait bon ? Pourquoi il y aurait une bonne test maintenable suite ? Pourquoi les aspects non fonctionnel seraient gérés correctement ? Pourquoi je devrais avoir une quelconque confiance dans une équipe qui livre objectivement de la merde ?
Et ça, ça se fait qu'on soit team member, tech lead, ou manager.
Ton outil, qui n'est qu'un outil, a évidement des cas d'utilisation (l'analyse statique / auto-correction d'intellij est super bien foutue par exemple). Par contre les cas d'exemple que tu donnes semblent d'être de corriger du code déjà écrit plutôt qu'une aide contre l'étourderie et là je suis très septique. Corriger les vrais problèmes dans ton organisation me semble être mille fois plus productif (mais moins marrant que d'écrire du code il est vrai).
CQFD :)
[^] # Re: Pas convaincu
Posté par djano . Évalué à 5.
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.
[^] # Re: Pas convaincu
Posté par ckyl . Évalué à 0.
Crois moi je n'ai rien d'utopique bien au contraire. Je suis incroyablement pragmatique et réaliste.
Non. Le but est de se débrouiller pour trouver une stratégie pour qu'il finisse par disparaitre vraiment sans être masqué par un coup de peinture. Ce n'est pas magique, ça prend extrêmement longtemps, beaucoup plus longtemps qu'il en a fallu pour écrire le code.
Il peut aussi vivoter en faisait payer son coût de maintenance, on peut trouver des stratégie pour le tuer. On peut aussi décider de tout un tas de chose (comme le fait que le transformer un peu est le premier pas).
Donc si je résume:
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 disparaitre les tas boue.
C'est apparemment ce que tu as fait.
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.
[^] # Re: Pas convaincu
Posté par djano . Évalué à 5.
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.
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:
[^] # Re: Pas convaincu
Posté par jraf . Évalué à 2.
On peut aussi se dire qu'avec un outil pareil on règle les "petits" problème, comme ca on enlève un peut de brouillard et ca permet de voir les vrai problèmes compliqués.
Qui ne sont souvent pas d'ordre technique, je suis d'accord avec toi.
Sur mon projet actuel, 7 developpeurs, pas tous amoureux du beau code, sonar annonce 600j de dette technique.
En soit ca ne veut pas dire grand chose, mais grâce a l'outil proposé (que tu n'est pas obligé d'utiliser) je vais pouvoir plus sereinement diminuer ce compteur pour accéder aux "vrais" problèmes qui m’intéresse, améliorer la couverture de test et diminuer la complexité de certaines méthodes.
La je viens de corriger l'ordre des paramètres dans la comparaison de 145 chaines dans 95 fichiers.
Si cet outil avait existé il y a quelques années, j'aurais gagné des semaines entières que j'ai passer à corriger des bricoles dans un soft qu'on reprenait en TMA.
Enfin moi j'en suis content.
Toutes les règles ne rentrent pas dans nos conventions de codage locale, mais je suis quand même content que cet outil existe.
Merci à l'auteur
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 5.
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).
À l'occasion d'une prochaine soirée AlpesJUG (faut juste que je trouve le temps d'y retourner).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par djano . Évalué à 6.
Ç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.
[^] # Re: Pas convaincu
Posté par robin . Évalué à 1.
Zut, j'ai loupé ça, c'était quand et où ?
bépo powered
[^] # Re: Pas convaincu
Posté par djano . Évalué à 4.
[^] # Re: Pas convaincu
Posté par robin . Évalué à 1.
Ok, merci. J'ai du passer à côté à cause du flag java ^^
bépo powered
# Revoir la doc README.md
Posté par Loyl . Évalué à 1.
Je n'ai pas encore eu l'occasion de tester le plugin car mon premier réflexe a été d'aller directement sur le projet GitHub pour voir comment installer et utiliser ton plugin et malheureusement, j'ai été déçu par la documentation du fichier README.md.
J'ai pris l'habitude de me faire une idée sur des projets mêmes très jeunes par la qualité de la documentation et je pense n'être pas le seul dans ce cas. Prenons un exemple : https://github.com/mkotsur/restito, le fichier README.md contient le minimum : une description de l'application, comment l'installer (dans ce cas via maven) et un exemple simple d'utilisation. Il y a aussi un lien vers un guide d'utilisation plus fourni : https://github.com/mkotsur/restito/blob/master/guide.md, parfait.
Pour AutoRefactor, j'ai bien vu qu'il y avait un site externe http://autorefactor.org/ mais pourquoi ne pas tout mettre dans Github ? C'est quand même plus simple.
[^] # Re: Revoir la doc README.md
Posté par djano . Évalué à 2. Dernière modification le 08 juin 2015 à 14:22.
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 :)
[^] # Re: Revoir la doc README.md
Posté par djano . Évalué à 3.
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!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.