Comment convaincre la direction que reformater toute la base de code Java est sûr

https://stackoverflow.com/questions/2420174

19-09-2019
|

Question

Comment peut-on aller de prouver à la direction qu'un reformatage de lot de tous les fichiers .java dans une grande base de code (pour placer le code dans le respect des normes de codage de l'entreprise) est sûr et n'affectera pas la fonctionnalité.

Les réponses devraient apaiser la non-technique et la technique aussi bien.

Edit: 2010-03-12 Précisions pour la technique entre vous; reformater = blanc espace ne change - «réordonnancement des variables membres, méthodes, etc. » non « l'organisation des importations » ou

Edit: 2010-03-12 Merci pour les nombreuses réponses. Je suis surpris que tant de lecteurs ont voté jusqu'à la réponse de mrjoltcola car il est tout simplement une déclaration au sujet d'être paranoïaque et nullement propose une réponse à ma question. De plus, il y a même un commentaire par le même donateur réitérant la question. WizzardOfOdds ce point de vue appuyé (mais vous ne pouvez pas avoir lu tous les commentaires pour le voir). -jtsampson

Edit: 2010-03-12 Je signalerai ma propre réponse bientôt, bien que la réponse de John Skeet avait raison sur l'argent avec la suggestion MD5 (note -g: aucune pour activer le débogage off). Bien qu'il ne couvrait que les aspects techniques. -jtsampson

2010-03-15 J'ai ajouté ma réponse ci-dessous. En réponse à ce qui ne « sûr » signifie, je voulais dire que la fonctionnalité du code Java ne serait pas affectée. Une simple étude du compilateur Java montre que ceci est le cas (avec quelques mises en garde). mises en garde Thos étaient « espace blanc seulement » et ont été signalées par plusieurs affiches. Toutefois, ce n'est pas quelque chose que vous voulez essayer d'expliquer à BizOps. Mon but était d'obtenir « comment justifier le faire » type de réponses et j'ai eu plusieurs grandes réponses.

Plusieurs personnes ont mentionné le contrôle de la source et le « fun » qui va de pair avec elle. Je n'ai pas mentionné spécifiquement que cette situation est déjà bien compris (dans mon contexte). Méfiez-vous de l'effet « de la station de gaz ». Voir ma réponse ci-dessous.

La solution

S'il est juste reformater, alors cela ne devrait pas changer la sortie du compilateur. Prenez un hachage ( MD5 devrait être assez bon) de la construction avant et après le reformatage - si c'est la même pour chaque fichier, cela signifie clairement qu'il ne peut pas avoir modifié le comportement. Il n'y a pas besoin d'exécuter des tests, etc. - si la sortie est octet par octet même, il est difficile de voir comment les tests commenceraient à défaut. (Bien sûr, il pourrait aider à exécuter les tests juste pour le spectacle de celui-ci, mais ils ne vont pas à prouver quoi que ce soit que les binaires identiques ne seront pas.)

EDIT: Comme il est indiqué dans les commentaires, les binaires contiennent des numéros de ligne. Assurez-vous que vous compilez avec -g:none d'omettre des informations de débogage. Cela devrait alors être d'accord avec les changements de numérotation de ligne -. Mais si vous changez noms qui est un changement plus grave, et qui pourrait en effet être un changement de rupture

Je suppose que vous peut reformater et reconstruire sans que personne ne se soucier - vérifier que le code reformaté retour dans le contrôle source devrait donner tout cas de préoccupation. Je ne suis pas penser fichiers de classe Java ont quelque chose en eux qui donne une date de construction, etc. Cependant, si votre « mise en forme » change l'ordre des champs, etc., que peut avoir un effet significatif.

Autres conseils

Dans un environnement d'entreprise, vous avez deux défis.

Technique
politique

Du point de vue technique, reformatters sont une technologie mature. Combiné avec / hashing checksums, aussi longtemps que la langue ne sont pas des espaces sensibles, vous êtes techniquement sûr de le faire. Vous voulez également vous assurer que vous le faites lors d'un temps d'arrêt où aucune des fourches importantes attendent d'être fusionnés. Les changements réels seront impossibles à séparer de reformater, donc faire séparément. La fusion peut être très difficile pour tous ceux qui travaillent sur une fourchette. Enfin, je ne le faire après que je l'ai mis en œuvre une couverture complète de cas de test. En raison de la raison 2 ...

Sur le plan politique, si vous ne savez pas comment convaincre la direction, comment savez-vous qu'il est sûr? Plus précisément est-il sans danger pour vous. Pour une personne âgée, développeur bien confiance, qui contrôle des processus dans un magasin, il est un travail plus facile, mais pour un développeur qui travaille dans une grande organisation rouge enregistrée, politique, vous devez vous assurer que vous couvrir tous vos bases.

L'argument que je fait en 2010 était un peu trop intelligent peut-être, mais, parseurs reformatters, imprimantes jolies sont des logiciels juste; ils peuvent avoir des bugs déclenchés par votre code de base, surtout si c'est C ++. Sans les tests unitaires partout, avec une grande base de code, vous ne pouvez pas être en mesure de vérifier 100% que le résultat final est identique.

En tant que développeur, je suis paranoïaque, et l'idée me fait mal à l'aise, mais aussi longtemps que vous utilisez:

Contrôle source
couverture de test appropriée

vous êtes OK.

Cependant, méditez ceci: La direction est maintenant au courant que vous bidouiller dans un projet d'un million en ligne avec un « changement de masse ». Un bug encore été découvert après votre état se reformater. Vous êtes maintenant principal suspect pour causer ce bug. Que ce soit « sûr » a plusieurs significations. Il pourrait ne pas être sans danger pour vous et votre travail.

Cela semble banal, mais il y a quelques années, je me souviens quelque chose se passer comme ça. Nous avons eu un rapport de bogue venir un jour après une période de maintenance de nuit où je ne fait une reconfiguration et d'un redémarrage jtsampson . Votre question n'a pas été sur la façon de le faire; il a été « Comment convaincre la direction qu'il est sûr ». Peut-être que vous auriez dû demander, à la place, « Est-il sûr? Si oui, comment le faire, en toute sécurité. » Ma déclaration pointait l'ironie de votre question, que vous supposiez qu'il était sûr, sans savoir comment. J'apprécie le côté technique de reformater, mais je signale qu'il existe un risque impliqué dans quoi que ce soit non trivial et à moins que vous mettez la bonne personne à ce sujet, il risque d'être sali vers le haut. Est-ce que cette tâche nuire à d'autres tâches de programmeurs, les deux pour dévier jours? Sera-t-conflit avec des révisions non engagées un autre codeur? Est-ce à toutes les sources en cours de révision? Y at-il un script intégré qui est des espaces sensibles, tels que Python ? Tout ce qui peut avoir un effet secondaire inattendu; pour notre environnement, il serait difficile d'obtenir une fenêtre de temps où il n'y a pas quelqu'un qui travaille sur une branche, et reformatage de masse va faire leur fusion assez laid. D'où mon dégoût pour-reformatage de masse, à la main ou automatisée.

Utilisez une approche pragmatique:

Construire l'application.
Enregistrer l'application.
reformater le code.
Construire l'application.
Diff les binaires.

Je voudrais utiliser quatre mots.

Source de contrôle. Tests unitaires.

Eh bien, ce n'est pas du tout en sécurité et vous êtes probablement jamais à les convaincre. En tant que personne qui a réussi beaucoup de développement, je ne le considérer dans une base de code commercial sur lequel tout revenu dépendait. Je ne dis pas qu'il n'y a pas d'avantages au code formaté comme vous le souhaitez, mais les chances que votre formatage ne sera pas impliquer un code change est nul. Cela signifie qu'il ya un risque énorme pour un gain très peu. Si vous devez le faire, faites-le au coup par coup que vous bug corriger le code, ne le faites pas dans un grand succès. Il est peut-être une bonne décision pour vous en tant que programmeurs, mais ce serait une décision terrible pour eux que la gestion.

Quelle gestion parlons-nous ici? Sont-ils technophiles assez pour comprendre la mise en forme de ce code est et comment Java traite les espaces blancs? Parce que si elles ne sont pas, je ne pense pas qu'ils sont qualifiés pour prendre une telle décision technique (à savoir, devraient être déléguées à ces questions à une personne qui est responsable du code).

Mais si elles sont ou que vous essayez de convaincre votre « architecte » ou quelqu'un qui lui ressemble, eh bien, il est de faire confiance à un outil tiers. Proposer un formatter qui a une bonne réputation, autre que ce n'est pas que vous pouvez faire, puisque vous ne codez pas le formatter.

En tant que piste côté, permettez-moi de partager une anecdote. Notre architecte a décidé à un moment de reformater tous les fichiers. Sur les milliers de fichiers Java, pas une seule erreur n'a encore été trouvée (ce qui était il y a plus d'un an et demi). Cela me fait confiance à formatter Eclipse pour le code source Java. Les avantages de cette mise en forme sont les suivants:

Certaines classes mal formatées sont maintenant plus faciles à lire.
Mise en forme même partout.

Mais il y avait aussi des côtés négatifs:

Un formatter de code n'est pas parfait. Parfois, le code formaté manuellement lit mieux. Le formatter dans les luttes particulières avec le code vraiment mauvais (lignes trop longues, trop imbriqués ifs, etc.).
Avez-vous d'autres branches de code, comme une ancienne version qui a besoin de temps en temps à patcher? Parce que vous pouvez oublier la fusion entre les branches avec différents styles de code (au moins lors de l'utilisation SVN).
Vous touchez tous les fichiers (et parfois presque toutes les lignes) et de ruiner l'histoire de tous les fichiers à la fois. Ça fait mal la traçabilité.
Il est en fait un petit avantage en ce que chaque développeur a sa propre mise en forme de code, car vous commencez à apprendre que le formatage, et vous pouvez identifier immédiatement l'auteur d'un morceau de code

Je pense personnellement le négatif l'emporte sur le positif. Cela ressemble à une grande idée, mais en réalité, vous ne gagnez pas autant que vous le pensez. Lorsque vous tombez sur un code terriblement formaté, reformater juste que la classe ou tout simplement cette méthode et voir comme un petit pas vers le grand but.

Vos tests unitaires passent après le reformatage? Si oui, alors vous avez vendu l'idée à la gestion!

Si vous bidouiller avec le code non testé, alors vous aurez un cas beaucoup plus difficile à faire.

Vous voulez que le "code en conformité avec les normes de codage de la société" [sic] et que vous voulez convaincre la direction?

Trivial: install CheckStyle , font partie de votre processus, nourrir vos directives de codage, et leur montrer que l'ensemble codebase lamentablement PANNE CheckStyle .

Ceci est un bon exemple de l'inadéquation-business technique.

Les techniciens veulent le faire, car il peut rendre le code difficile à lire, mais, à moins que c'est exceptionnellement mauvais, la vraie raison est qu'il porte atteinte à la sensibilité généralement délicate et l'esthétique du programmeur moyen .

Les gens d'affaires veulent gérer le risque. Le risque peut être entreprise que s'il y a un certain avantage et il n'y a pas business bénéficient ici à moins que vous disputez ce sera moins cher, plus rapide et / ou moins risqué de faire du développement futur avec le code source reformaté, qui tous l'honnêteté est difficile à vendre.

Presque par définition tout changement a attaché le risque. Le risque ici est soit à distance, mais pas inexistante (du point de vue de la direction) presque sans tête.

Il y a une autre question à considérer aussi: ce genre de changement peut causer des ravages avec contrôle de code source. Il devient plus difficile de suivre ce qui a changé parce que la dernière modification de toute ligne sera le reformatage de sorte que vous aurez besoin d'aller comparer les révisions, ce qui est un peu plus fastidieux que d'une simple commande « blâme » ou « annoter ».

En outre, si vous avez plusieurs branches actives un reformatage de votre code causera des ravages avec vos fusions.

Il est sûr, en ce sens que les changements purs de mise en forme ne fera aucune différence pour ce qui est compilé, et donc pas de différence au comportement du code lors de l'exécution.

Il convient de rappeler que reformatage en vrac de code peut conduire à « fun » en traitant plus tard le contrôle de la source - si les collègues multiples ont le code vérifié, et un membre de l'équipe arrive et reformate, toutes ces copies sont des de ce jour. Pire encore, quand ils mettent à jour leurs copies de travail, toutes sortes de conflits vont apparaître, parce que ces changements auront une incidence sur la mise en forme d'énormes portions du code, et Persuadée peut être un cauchemar.

Code reformatage est le même que reformater un document dans Word; il change la mise en page et donc la lisibilité, mais pas le contenu.

Si tous les fichiers sont mis en forme le même code devient plus lisible , ce qui rend l'entretien un peu plus facile et donc moins cher. Aussi les revues de code peuvent être plus rapides et plus efficaces.

De plus, étant donné un bon style de mise en forme, des bugs peuvent être trouvés plus facilement qu'ils ne peuvent pas se cacher; penser si les déclarations sans accolades et 2 déclarations dans ces accolades imaginaires.

Ne soyez intelligent et vérifier le code et l'étiqueter avant de reformater, de sorte que vous avez un état pour revenir à (et dire aux gens la facilité qui serait), reformater et vérifiez à nouveau et étiquette, sans aucune autre modification.

Répondez à ces questions de gestion, et vous aurez parcouru un long chemin de les convaincre qu'il est un changement sûr?

Pourquoi les bonnes questions de mise en forme?
Quels changements seront effectués? (Si vous ne pouvez pas répondre à cela, vous ne savez pas assez sur le reformatage de le savoir sera en sécurité)
Est-ce que nos suites de tests unitaires prouver les changements ont eu aucun effet néfaste? (Indice, la réponse doit être oui)
Est-ce que le code existant est marqué dans le référentiel source de sorte que nous avons une option de retour rapide rouleau? (Allusion la réponse mieux que oui)

Qu'environ le couvre.

En fait, je serais probablement de leur côté. Reformater unités que vous les ouvrez pour les correctifs ou la mise en valeur quand ils seront testés à fond avant d'aller en production. Ils doivent avoir été correctement formaté la première fois, mais si elles sont en production, il semble inutile et téméraire de les reformater que pour l'amour de style.

La cohérence est bonne, mais « une consistance stupide est le Hobgoblin des petits esprits ».

Je suis d'enfiler mon chapeau de directeur ...

Pour le faire comme un grand projet, je ne vous laisse pas le faire, peu importe l'argument. Je voudrais cependant, être ouvert à des estimations plus sur les changements parce que vous modifiez les fichiers existants pour inclure ces changements de format. Je vous besoin de faire la mise en forme change son propre enregistrement bien.

Merci pour toutes vos réponses.

Mon dernier argument pour convaincre la direction; Bits de toutes vos réponses incluses. Merci pour l'aide.

Technique:

reformater se compose des changements d'espace blanc (pas de réordonnancement d'importation, aucun membre / méthode)
reformater utilisera [spécifier outil et processus]
reformater aura lieu le [spécifier le temps au sein du cycle de codage afin de minimiser l'impact de fusion]

Avant et après un reformatage:

Tous les tests unitaires passeront
Tous les tests d'intégration passeront
Tous les tests fonctionnels passeront
Tous les tests SOAP UI passeront
Le code octet est le même (MD5 des fichiers .class suivants javac (-G: none))

Business:

Objectif:. De se conformer aux normes de l'entreprise qui prévoit que nos fichiers source représentent avec précision la structure logique de notre code

changement par rapport à reformater le changement de code (exemple de document Word comme ci-dessus)
reformater utilisera [processus général]
reformater aura lieu le [spécifier le temps au sein du cycle d'affaires pour minimiser l'impact]

Test pilote:

Confirmé « Format lot » a donné lieu à moins des conflits de fusion puis « Format que vous Code ». .
a confirmé que le code exécutable (4k + fichiers .class) reste le même. (Test MD5)
fonctionnalité confirmée ne sera pas affectée (tests automatisés / tests de fumée)
Paramètres de formatter confirmés ne contiennent que des changements d'espace blanc.

Remarque: Dans mon cas, un test pilote a été exécuté plus de 6 mois par un sous-ensemble des développeurs utilisant un outil automatisé pour « Format que vous code » (tel que prescrit par certaines des réponses ci-dessus) . Alors que certains ont perçu le reformatage a causé plus des conflits de fusion, c'était en fait pas le cas.

Cette perception est la base sur la coïncidence temporelle de la reformater. Par exemple, considérer la personne qui ne savent rien sur les voitures. Un jour leurs freins ne marchent pas. A quoi ils attribuent la cause? Le gaz bien sûr. Ce fut la dernière chose qu'ils ont mis dans la voiture (l'effet « de la station de gaz »?). Il est clair cependant, les freins et un système de carburant sont système disparates que sont le formatage et les changements de code. Nous avons trouvé que les enregistrements inappropriés dans le cadre de notre processus de construction étaient en faute.

dernier, j'espérais que quelqu'un aurait fourni un bon lien vers une étude montrant des gains de productivité liés à un code commun car il est difficile de démontrer le retour sur investissement pour l'entreprise. Bien que dans mon cas, car il était une norme de l'entreprise que j'avais « conformité » de mon côté. Je ne devais montrer qu'il était plus de temps à « Format que vous code » par rapport à « Format de lot »

Si vous utilisez href="http://en.wikipedia.org/wiki/Eclipse_%28software%29" Eclipse comme votre plate-forme de développement, vous pouvez charger tout le code dans l'espace de travail local. Démontrer à la gestion, il n'y a pas de problèmes en leur montrant l'onglet problèmes.

Ensuite, faites un clic droit et Format chacun des projets un par un -. Démontrant à nouveau aucun problème sont introduits

Vous pouvez le faire sur votre poste de travail, sans aucun dommage du tout à votre dépôt.

Honnêtement si votre gestion est si non technique à avoir peur de formatage du code source, puis démontrer qu'il n'y a pas de problèmes apparaissent dans l'onglet problèmes après un format devrait être suffisant pour montrer que le code est toujours très bien.

Sans oublier que vous aurez sans doute l'ancienne version de droite marquée dans le contrôle source?

Une école de pensée pourrait être de le faire sans demander et pouvoir aller « Voir »

Bien sûr, si vous épave le tout vous aurez mis le feu. Vous fait vos choix ...

Vous pouvez également, le contrôle de la source (ou des sauvegardes simples), alors vous pouvez toujours rouler en arrière.

Si votre code a assez près la couverture de code 100% alors je pense que le risque peut être abaissée un peu.

Cependant, même si la direction a convenu que la base de code est sûr, je pense qu'ils ont leurs yeux d'avoir à justifier de payer un employé à passer des heures Code reformatage juste pour adhérer à une norme (je présume) a été introduit à long dans le cycle de vie de développement.

Nous utilisons Jalopy ici à mon emploi actuel. Il est un produit assez solide et il produit une sortie vraiment bien. Le développeur le plus élevé ici reformaté toute la base de code quand il a migré à partir de CVS à SVN, et il a dû effectuer quelques tests pour vous assurer qu'il travaillerait tout le chemin du début à la fin, et nous avons maintenant des crochets pour faire en sorte que checked- dans le code est correctement formaté.

Cela étant dit, je ne pense pas que vous pouvez convaincre quelqu'un que tout outil est fou (ou faute) la preuve, parce qu'il n'y a pas un tel outil. Si vous pensez que l'avantage vaut le temps et le (très faible) risque, essayer de convaincre votre gestion le plus grand avantage que vous voyez à le faire. Pour moi, le plus grand avantage viendra si:

Tous les développeurs ont les mêmes paramètres de mise en forme;
La mise en forme du code source est cochée lors de l'enregistrement par un crochet dans votre SCM.

Parce que si vous faites ce qui précède, si votre code est déjà formaté, lorsque vous comparez les révisions dans votre SCM vous verrez des changements réels dans la logique du programme, et non pas seulement le formatage des changements.

Si vous avez une bonne couverture des tests unitaires, les résultats des tests avant et après sera suffisant.

Juste une tête spécifique jusqu'à: si votre politique de l'entreprise comprend un élément alphabétique de tri, il faut savoir que l'ordre des champs statiques importe. Donc, si vous incluez un en sauvegarde ou règle de nettoyage qui fait cela, vous pouvez casser votre code.

Techniquement, au cours de la première phase de compilation, lexer bandes tous les commentaires et les espaces blancs de la source. Ceci est bien avant que la sémantique du code est reconnu par le compilateur. Par conséquent, tout espace ou commentaires ne peuvent pas changer quoi que ce soit dans la logique du programme. Au contraire, de quelle utilité serait la langue et être qui voudrait l'utiliser si l'ajout de deux espaces ou des sauts de ligne serait changer la sémantique?

Du côté de l'entreprise, vous allez probablement utiliser quelques outils spécialisés pour cela. Je suis sûr qu'ils annoncent sur leurs sites Web qu'ils travaillent beaucoup.

Note finale: si vous devez convaincre votre gestion de cela, peut-être vous devriez chercher à trouver un moyen de travailler avec des gens plus intelligents

Je demande Gestion quelle est leur base actuelle pour croire que le code fonctionne - démontrent alors que le même outil (tests, documentation, petites voix ...) fonctionne exactement aussi bien pour le code reformaté. Je veux leur réponse soit « tests » ...

Je sais que les réponses précédentes sont très bien, mais voici une autre possible: Faire un CRC sur la version compilée avant et après un reformatage. Comme la compilation ne tiendrait pas compte des espaces, des onglets, des sauts de ligne, etc., la version compilée doit être identique à l'original, et qui prouverait aux gestionnaires semi-techniques que tout va bien.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow