CestQuoiRemanier

MeatballWiki | RecentChanges | Random Page | Indices | Categories

La page a démarré sur WhatIsReworking

Le titre au-dessus a été extrait de Wiki:WhatIsReworking ; l'auteur de tout le texte suivant est SunirShah et il accorde la permission à MeatBall d'en copier le contenu.

Remanier ou retravailler est ce que les enfants à l'école pourrait appeler, "refaire à nouveau !" Cela veut dire, tout à fait simplement, refaire quelque travail fait précédemment. Sur ce site, cela a deux usages principaux :

1. Retravailler l'écriture.

Comme expliqué brièvement sur Wiki:WhatIsRefactoring, il est possible de remanier la sémantique (sens littéral) d'un travail. Néanmoins le langage naturel n'est pas limité à la sémantique (ou fonctionnalisme). Il contient tout aussi bien un sens connoté, normalement appelé le style (par exemple la rhétorique). Le style d'un travail provient de la structure de l'écriture, de la relation entre les mots. Il n'est strictement pas possible de remanier un morceau d'écriture et d'en préserver le style.

Imaginez la différence entre, "Rapidement, Jean courut vers Jeanne." et "Jean courut rapidement vers Jeanne". Fonctionnellemnet, les deux phrases sont équivalentes, mais du point de vue du style elles sont vraiment différentes. La première phrase met l'accent sur la vitesse à laquelle Jean a couru tandis que la seconde souligne (plus mollement) les personnages dans la narration.

Mais plus pratiquement, remanier un texte est vraiment rare (même s'il est possible disons en migrant un morceau de discussion vers une page séparée sur un wiki). Retravailler est bien plus commun. Enoncer de nouveau ce qui s'est dit, enlever ce qui n'est pas intéressant, expliquer les points en de plus amples détails.

Ainsi, quand quelqu'un dit qu'il remanie une page, il va plus probablement la retravailler pour qu'elle se lise mieux.

Un grand objectif au moment de retravailler est de préserver la relation du travail en révision vers les autres travaux dans le système. Par conséquent, au moment de retravailler on ne veut pas devoir ajuster les relations qu'elle a vers d'autres pages. (Ce pourrait être faux si la discussion devient méta, mais nous ignorerons ces cas parce qu'ils sont de toutes les façons auto-bloqués).

Pensez à la rénovation d'une salle de bains dans la maison. Un bon artisant fera le travail sans changer les escaliers des chambres. Un vraiment bon artisant peut même ne pas avoir à toucher les chambres aux alentours.

2. Retravailler le code.

Généralement, ceci est fait afin d'améliorer le système, disons en nettoyant le code ou en l'améliorant. Eu égard au nettoyage du code, retravailler colle au spectre entre Wiki:CowboyCoding et Wiki:DesignByContract en partant du remanement vers un peu en direction du Wiki:CowboyCoding. A proprement parler, remanier est un cas spécial de retravail (voir en-dessous et Wiki:WhatIsRefactoring).

Remanier est bien quand vous voulez garantir une équivalence fonctionnelle. Disons que vous êtes confiants sur la manière dont fonctionne un sous-système mais pas de la façon dont il est écrit. Un remaniement strict empêche les bugs supplémentaires d'être introduits. D'un autre côté, cela protège les bugs existants.

La version plus lâche du retravail est simplemnet de récrire pour améliorer la qualité. Vraiment, ceci suppse essentiellement que le programmeur est parfait (comme un Wiki:CowboyCoder), et par conséquent n'introduira pas de bugs. Mais c'est aussi limité dans le domaine, réduisant par conséquent la quantité de complexité dont doit se soucier le programmeur. Ainis, en vertur de sa flexibilité accrue, il a le potentiel d'être plus optimal que le remaniement, même si le remaniement est sûr de fonctionner. Les personnes qui peuvent se permettre de traiter les défectuosités pur le temps de mise en marché peuvent apprécier cette approche. Ou celles qui comprennent suffisamment bien la solution (et comment l'écrire) pour que n'importe quel bugs introduit puisse être facile à détecter. Comment cela est fait est un autre problème, bien sûr. Ce pourrait être faux, aussi parce que cela arrive à chaque fois qu'on retire les garanties dans le monde plus risqué de la flexibilité éventuelle.

Une autre question est à quel niveau nous voulons garantir une équivalence fonctionnelle. Si vous considérez le système comme étant un oignon d'interfaces (pas vraiment vrai dans bien des cas, mais imaginons), alors vous pouvez sélectionner une couche et la bloquer avec des Wiki:RegressionTests. Tout ce qui est en-dessous que vous pouvez retravailler sans maintenir l'équivalence vers des unités correspondantes dans la révision précédente du système. Ceci une fois de plus équilibre la flexibilité contre la portée. Alors que cela peut sembler comme du refactoring, le refactoring strict protégerait l'équivalence vers le bas et tout aussi bien vers les unités atomiques dans le système.

Une chose que le retravail peut faire est de retirer les défectuosités ou ajouter des fonctionnalités. Ceci peut être facile à faire même en nettoyant le code. Il peut être difficile de préserver un défaut d'une révision à l'autre, tout spécialemnet un dont vous n'étiez pas nécessairement conscient. Ou il peut être plus élégant d'ajouter des points fonctionnels. Si vous croyez en des Wiki:RegressionTests complets, vous devez être conscient de ce dernier cas. Il est possible de faire toutes les passe des Wiki:RegressionTests tout en finissant par un super-ensemble de fonctionnalités ; par conséquent, vous devez écrire de nouveaux tests pour tout ce que vous avez consciemment décidé d'ajouter ou tout e qui émerge du système et sera utilisé.

Marmonnements Théoriques.

Fondamentalement, nous pouvons visualiser tous les systèmes linguistiques comme un graphe G = (V,E). Each functional (logical) point can be represented as a vertex. Refactoring transforms G to G' = (V,E'), where E' does not equal E. Reworking transforms G to G' = (V',E') where G' does not equal G, but V' may or may not equal V and E' is not equal E. Clearly, refactoring is a special case of reworking when V' = V.

However, if G was abstracted as a node in a metagraph H, a good reworking on G will make a commensurate transformation on H to H. That is, H shouldn't change.

: I don't get the last bit. What is a metagraph, and how could it be possible to modify only G and yet change the structure of the metagraph (i.e. isn't the last bit a tautology?)

: Also, I note that I use the term "reworking" to mean any kind of editing of a page. I try to use it instead of "refactoring" because "refactor" is jargon.

: -- BayleShanks

Voir aussi ProblèmesRemaniement.

LangueFrançaise PageTranslation WhatIsReworking DossierRemaniement

CestQuoiRemanier

Discussion