Author: bertrand
Date: Tue Jul 24 03:45:29 2007
New Revision: 846
Log:
Ch02, §3 finished
Modified:
trunk/fr/ch02.xml
Modified: trunk/fr/ch02.xml
==============================================================================
--- trunk/fr/ch02.xml (original)
+++ trunk/fr/ch02.xml Tue Jul 24 03:45:29 2007
@@ -187,8 +187,8 @@
puisse quelque fois révéler des hypothèses cachées voire des
désaccords sur la nature du projet, ce qui est une bonne chose:
mieux vaut résoudre les divergences en amont. L'étape suivante est
- de packager le projet à destination du grand public, ce qui est un
- travail titanesque.</para>
+ de packager le projet à destination du grand public, ce qui s'avére
+ être un travail titanesque.</para>
<para>Ce qui rend ce travail si laborieux est le fait qu'il consiste
à formaliser et documenter des concepts que tout le monde connaît
@@ -240,7 +240,7 @@
<!-- ======================== subsection ============================== -->
<sect2 id="choosing-a-name">
- <title>Choisir un bon nom</title>
+ <title>Choisir un nom adéquat</title>
<para>Mettez vous à la place d'une personne qui aurait entendu
parlé de votre projet pour la première fois, peut être après
@@ -1452,227 +1452,247 @@
<blockquote>
<para>
- <emphasis>First, let's please cut down on the (potentially) ad
- hominem comments; for example, calling J's design for the
- security layer "naive and ignorant of the basic principles of
- computer security." That may be true or it may not, but in
- either case it's no way to have the discussion. J made his
- proposal in good faith. If it has deficiencies, point them
- out, and we'll fix them or get a new design. I'm sure M meant
- no personal insult to J, but the phrasing was unfortunate, and
- we try to keep things constructive around here.</emphasis>
+ <emphasis>Tout d'abord, veuillons à éviter les potentielles
+ attaques ad hominem; par exemple celle de qualifier la
+ conception de la couche sécurité de J. de "naïve et ignorante
+ des principes de base de la sécurité informatique". Ce peut ou
+ non être vrai, mais c'est hors propos. J. a fait cette
+ proposition de bonne foi. Si elle présente des lacunes,
+ analysons les, et nous les corrigerons ou nous proposerons une
+ nouvelle architecture. Je suis persuadé que M. n'avait pas
+ l'intention de blesser J., mais la phrase était maladroite et
+ nous essayons de rester constructifs.</emphasis>
</para>
<para>
- <emphasis>Now, on to the proposal. I think M was right in
- saying that...</emphasis>
+ <emphasis>Maintenant, sur la proposition en elle-même, je
+ pense que M. avait raison de dire que...</emphasis>
</para>
</blockquote>
- <para>As stilted as such responses sound, they have a noticeable
- effect. If you consistently call out bad behavior, but don't
- demand an apology or acknowledgment from the offending party, then
- you leave people free to cool down and show their better side by
- behaving more decorously next time—and they will. One of the
- secrets of doing this successfully is to never make the
- meta-discussion the main topic. It should always be an aside, a
- brief preface to the main portion of your response. Point out in
- passing that "we don't do things that way around here," but then
- move on to the real content, so that you're giving people
- something on-topic to respond to. If someone protests that they
- didn't deserve your rebuke, simply refuse to be drawn into an
- argument about it. Either don't respond (if you think they're just
- letting off steam and don't require a response), or say you're
- sorry if you overreacted and that it's hard to detect nuance in
- email, then get back to the main topic. Never, ever insist on an
- acknowledgment, whether public or private, from someone that they
- behaved inappropriately. If they choose of their own volition to
- post an apology, that's great, but demanding that they do so will
- only cause resentment.</para>
-
- <para>The overall goal is to make good etiquette be seen as one of
- the "in-group" behaviors. This helps the project, because
- developers can be driven away (even from projects they like and
- want to support) by flame wars. You may not even know that they
- were driven away; someone might lurk on the mailing list, see that
- it takes a thick skin to participate in the project, and decide
- against getting involved at all. Keeping forums friendly is a
- long-term survival strategy, and it's easier to do when the
- project is still small. Once it's part of the culture, you won't
- have to be the only person promoting it. It will be maintained by
- everyone.</para>
+ <para>Bien que pompeuse, ce style de réponse a un effet non
+ négligeable. Si vous reprenez avec constance les débordements,
+ mais sans demander de faire ou de d'accepter des excuses, vous
+ laisser aux gens la possibilité de garder la tête froide et de
+ montrer leur meilleur jour en se comportant de façon plus
+ appropriée la fois suivante. Un des secrets est de ne jamais faire
+ de cette méta-discussion le sujet principal. Elle doit toujours
+ être traitée séparément, comme préface dans votre réponse.
+ Notifiez en passant que "les choses ne se traitent pas de cette
+ manière ici", mais retombez tout de suite sur le sujet initial
+ pour laisser la possibilité aux gens de répondre quelque chose en
+ rapport. Si quelqu'un proteste qu'il ne mérite pas votre
+ réprimande, refusez simplement de répondre à cette escalade. Vous
+ pouvez soit ne pas répondre (si vous pensez qu'il s'agissait
+ simplement d'un accès d'humeur), soit dire que vous êtes désolé si
+ vous avez réagit trop vivement et qu'il est difficile de percevoir
+ toutes les nuances dans un e-mail, puis revenez au sujet
+ principal. N'insistez <emphasis>jamais</emphasis> pour exiger des
+ excuses, que ce soit de façon publique ou privée, de quelqu'un qui
+ s'est mal comporté. C'est une bonne chose s'il décide de son
+ propre chef d'envoyer une excuse, mais en exiger ne cause que du
+ ressentiment.</para>
+
+ <para>L'étiquette doit être reconnue comme l'un des comportements
+ du groupe. Cela aide le projet car les développeurs peuvent être
+ dissuadés de participer (même des projets sur lesquels ils
+ aimeraient travailler) par les polémiques. Vous pouvez même ne
+ jamais vous en rendre compte; quelqu'un peut scruter la liste,
+ constater qu'il faut être armé d'une cuirasse pour participer au
+ projet, et donc décider de ne pas s'y investir du tout. Garder les
+ forums amicaux est une question de vie ou de mort sur le long
+ terme, et c'est bien plus facile à faire tant que le projet est
+ encore jeune. Une fois que l'étiquette rentre dans les moeurs,
+ vous n'aurez plus à être le seul à la promouvoir, elle le sera par
+ tous.</para>
</sect2>
<!-- ======================== subsection ============================== -->
<sect2 id="code-review">
- <title>Practice Conspicuous Code Review</title>
+ <title>Pratiquez la revue par pairs</title>
- <para>One of the best ways to foster a productive development
- community is to get people looking at each others' code. Some
- technical infrastructure is required to do this effectively—in
- particular, commit emails must be turned on; see <xref
- linkend="commit-emails" /> for more details. The effect of commit
- emails is that every time someone commits a change to the source
- code, an email goes out showing the log message and diffs for the
- change (see <xref linkend="vc-vocabulary-diff" />, in <xref
- linkend="vc-vocabulary" />). <firstterm>Code review</firstterm> is
- the practice of reviewing commit emails as they come in, looking
- for bugs and possible improvements.<footnote>
- <para>This is how code review is usually done in open source
- projects, at any rate. In more centralized projects, "code
- review" can also mean multiple people sitting down together
- and going over printouts of source code, looking for specific
- problems and patterns.</para>
+ <para>L'une des meilleurs bonnes pratiques pour favoriser le
+ développement d'une communauté productive est de permettre aux
+ gens d'observer leur code les uns les autres. Un peu
+ d'infrastructure technique est requise pour y arriver, en
+ particulier il faut activer l'envoi d'e-mails sur commit (voir
+ <xref linkend="commit-emails" /> pour plus de détails). Le but est
+ d'émettre un e-mail contenant le message de commit et les
+ changements (diff) à chaque commit dans le code (voir <xref
+ linkend="vc-vocabulary-diff" /> du <xref
+ linkend="vc-vocabulary" />). <firstterm>La revue de
+ code</firstterm> est la pratique consistant à consulter ces
+ e-mails au fil de l'eau en y recherchant des bogues ou de
+ possibles améliorations.<footnote>
+ <para>C'est en général de cette façon qu'est réalisée la revue
+ de code dans les projets libres. Dans des projets plus
+ centralisés, cette revue peut également se faire en réunissant
+ plusieurs personnes et en analysant des listings de code
+ source à la recherche de problèmes spécifiques ou de patrons
+ de conception à mettre en place.</para>
</footnote></para>
- <para>Code review serves several purposes simultaneously. It's the
- most obvious example of peer review in the open source world, and
- directly helps to maintain software quality. Every bug that ships
- in a piece of software got there by being committed and not
- detected; therefore, the more eyes watch commits, the fewer bugs
- will ship. But code review also serves an indirect purpose: it
- confirms to people that what they do matters, because one
- obviously wouldn't take time to review a commit unless one cared
- about its effect. People do their best work when they know that
- others will take the time to evaluate it.</para>
-
- <para>Reviews should be public. Even on occasions when I have been
- sitting in the same physical room with developers, and one of us
- has made a commit, we take care not to do the review verbally in
- the room, but to send it to the development mailing list instead.
- Everyone benefits from seeing the review happen. People follow the
- commentary and sometimes find flaws in it, and even when they
- don't, it still reminds them that review is an expected, regular
- activity, like washing the dishes or mowing the lawn.</para>
-
- <para>In the Subversion project, we did not at first make a
- regular practice of code review. There was no guarantee that every
- commit would be reviewed, though one might sometimes look over a
- change if one was particularly interested in that area of the
- code. Bugs slipped in that really could and should have been
- caught. A developer named Greg Stein, who knew the value of code
- review from past work, decided that he was going to set an example
- by reviewing every line of <emphasis>every single
- commit</emphasis> that went into the code repository. Each commit
- anyone made was soon followed by an email to the developer's list
- from Greg, dissecting the commit, analyzing possible problems, and
- occasionally praising a clever bit of code. Right away, he was
- catching bugs and non-optimal coding practices that would
- otherwise have slipped by without ever being noticed. Pointedly,
- he never complained about being the only person reviewing every
- commit, even though it took a fair amount of his time, but he did
- sing the praises of code review whenever he had the chance. Pretty
- soon, other people, myself included, started reviewing commits
- regularly too. What was our motivation? It wasn't that Greg had
- consciously shamed us into it. But he had proven that reviewing
- code was a valuable way to spend time, and that one could
- contribute as much to the project by reviewing others' changes as
- by writing new code. Once he demonstrated that, it became expected
- behavior, to the point where any commit that didn't get some
- reaction would cause the committer to worry, and even ask on the
- list whether anyone had had a chance to review it yet. Later, Greg
- got a job that didn't leave him as much time for Subversion, and
- had to stop doing regular reviews. But by then, the habit was so
- ingrained for the rest of us as to seem that it had been going on
- since time immemorial.</para>
-
- <para>Start doing reviews from very first commit. The sorts of
- problems that are easiest to catch by reviewing diffs are security
- vulnerabilities, memory leaks, insufficient comments or API
- documentation, off-by-one errors, caller/callee discipline
- mismatches, and other problems that require a minimum of
- surrounding context to spot. However, even larger-scale issues
- such as failure to abstract repeated patterns to a single location
- become spottable after one has been doing reviews regularly,
- because the memory of past diffs informs the review of present
- diffs.</para>
+ <para>La revue de code répond simultanément à plusieurs objectifs.
+ Il s'agit de l'exemple le plus évident de revue par pairs dans le
+ monde du libre, et elle aide à assurer un bon niveau de qualité au
+ logiciel. Chaque bogue incorporé dans la version finale l'a été
+ parce qu'il n'a pas été détecté à temps; ainsi, plus d'yeux
+ observent les commits, plus le nombre de bogues sera limité. Mais
+ ce processus sert aussi un autre but plus indirect : il conforte
+ les gens dans l'idée que ce qu'ils font a de l'importance,
+ puisqu'il est évident que personne ne prendrait le temps de faire
+ une revue s'il ne se souciait de son effet sur le programme. Les
+ gens produisent leur meilleur travail quand ils savent que
+ d'autres l'évalueront.</para>
+
+ <para>Les revues doivent être publiques. Même lorsque j'ai été
+ assis avec d'autres développeurs dans la même pièce physique, et
+ que l'un d'entre nous avait fait un commit, nous prenions garde à
+ ne pas faire la revue verbalement, mais de l'envoyer plutôt sur la
+ liste. Tout le monde profite de cette revue. Les gens suivent les
+ commentaires et quelque fois y découvrent des erreurs, et même si
+ ce n'est pas le cas, cela leur rappelle que la revue est une
+ activité régulière, comme laver la vaisselle ou tondre la
+ pelouse.</para>
+
+ <para>Dans le projet Subversion, la revue de code n'a pas été
+ initialement un exercice régulier. Il n'y avait aucune garantie
+ que chaque commit serait revu, même on pouvait consulter une
+ modification si elle se trouvait dans notre champs d'action. Les
+ bogues se glissaient sans difficulté alors qu'ils aurait pu et
+ auraient du être filtrés. Un développeur nommé Greg Stein, qui
+ connaissait la valeur de la revue par pair d'un ancien travail,
+ décida qu'il allait montrer l'exemple en faisant la revue de
+ <emphasis>chaque commit</emphasis> arrivant dans le référentiel.
+ Chaque modification était rapidement suivie d'un e-mail de Greg
+ envoyé à la liste développeur dans lequel il disséquait le commit,
+ analysait les problèmes potentiels, et proposait quelque fois un
+ peu de code bien tourné. Instantanément, il attrapa des bogues et
+ des méthodes de programmation non optimales qui autrement auraient
+ glissées sans que personne ne s'en rende compte. Il est à noter
+ qu'il ne s'est jamais plaint d'être le seul à faire ces revues,
+ même s'il y consacrait une quantité de temps importante. Il en
+ chantait simplement les louanges, dès qu'il le pouvait. Assez
+ rapidement, d'autres personnes, moi compris, commencèrent à
+ l'imiter. Quelle était notre motivation ? Non pas que Greg avait
+ jeté l'opprobre sur nous, mais il avait prouvé que la revue de
+ code était une façon intelligente de dépenser son temps, et que
+ chacun pouvait contribuer autant au projet en analysant le code
+ des autres qu'en écrivant du code soit-même. Une fois qu'il l'eu
+ démontré, ceci devint le comportement par défaut, au point qu'un
+ commit sans réaction aurait causé de l'angoisse à son émetteur, et
+ qu'il aurait demandé sur la liste si quelqu'un avait déjà pu faire
+ la revue. Plus tard, Greg trouva un travail qui ne lui laissait
+ peu de temps pour Subversion, et du arrêter ses revues régulières,
+ mais cette coutume était si bien enracinée en nous tous qu'elle
+ est toujours activement pratiquée depuis un temps
+ immémorial.</para>
+
+ <para>Commencez à faire des revues depuis le premier commit. Les
+ types de problèmes les plus faciles à détecter de cette façon sont
+ les vulnérabilités de sécurité, les fuites mémoire, les manques de
+ commentaires ou de documentation d'API, les effets de bord, les
+ erreurs de conception dans la hiérarchie d'appels, et d'autres
+ problèmes qui nécessitent un minimum de recul pour être détectés.
+ Néanmoins, même les problèmes à plus grande échelle comme
+ l'incapacité à mutualiser du code à un seul endroit devient
+ visible à force de revues, parce que le souvenir des revues
+ précédentes renseigne les revues courantes.</para>
<!-- todo: Andrew Stellman suggested putting a checklist of what to
look for in code review here. That might be a good idea. -->
- <para>Don't worry that you might not find anything to comment on,
- or that you don't know enough about every area of the code. There
- will usually be something to say about almost every commit; even
- where you don't find anything to question, you may find something
- to praise. The important thing is to make it clear to every
- committer that what they do is seen and understood. Of course,
- code review does not absolve programmers of the responsibility to
- review and test their changes before committing; no one should
- depend on code review to catch things he ought to have caught on
- his own.</para>
+ <para>Ne vous inquiétez pas si vous ne trouver rien à commenter,
+ ou si vous de maîtrisez pas assez toutes les parties du code. Il y
+ aura souvent quelque chose à dire sur tout commit; même si vous ne
+ trouvez rien à redire, quelque chose peut faire l'objet d'un
+ commentaire admiratif. L'important est de rendre clair le fait que
+ chaque développeur sache que ce qu'il fait est vu et compris. Bien
+ entendu, la revue du code n'absout pas les programmeurs de leur
+ responsabilité à vérifier et à tester leurs modifications avant de
+ commiter; personne ne devrait dépendre de la revue pour détecter
+ des problèmes qu'on aurait dû trouver soit-même.</para>
</sect2>
<!-- ======================== SECTION ============================== -->
<sect2 id="opening-closed-projects">
- <title>When Opening a Formerly Closed Project, be Sensitive to the
- Magnitude of the Change</title>
+ <title>Lorsque vous ouvrez un projet propriétaire, soyez attentif
+ à la gestion du changement</title>
- <para>If you're opening up an existing project, one that already
- has active developers accustomed to working in a closed-source
- environment, make sure everyone understands that a big change is
- coming—and make sure that you understand how it's going to feel
- from their point of view.</para>
-
- <para>Try to imagine how the situation looks to them: formerly,
- all code and design decisions were made with a group of other
- programmers who knew the software more or less equally well, who
- all received the same pressures from the same management, and who
- all know each others' strengths and weaknesses. Now you're asking
- them to expose their code to the scrutiny of random strangers, who
- will form judgements based only on the code, with no awareness of
- what business pressures may have forced certain decisions. These
- strangers will ask lots of questions, questions that jolt the
- existing developers into realizing that the documentation they
- slaved so hard over is <emphasis>still</emphasis> inadequate (this
- is inevitable). To top it all off, the newcomers are unknown,
- faceless entities. If one of your developers already feels
- insecure about his skills, imagine how that will be exacerbated
- when newcomers point out flaws in code he wrote, and worse, do so
- in front of his colleagues. Unless you have a team of perfect
- coders, this is unavoidable—in fact, it will probably happen to
- all of them at first. This is not because they're bad programmers;
- it's just that any program above a certain size has bugs, and peer
- review will spot some of those bugs (see <xref
- linkend="code-review" /><phrase output="printed"> earlier in this
- chapter</phrase>). At the same time, the newcomers themselves
- won't be subject to much peer review at first, since they can't
- contribute code until they're more familiar with the project. To
- your developers, it may feel like all the criticism is incoming,
- never outgoing. Thus, there is the danger of a siege mentality
- taking hold among the old hands.</para>
-
- <para>The best way to prevent this is to warn everyone about
- what's coming, explain it, tell them that the initial discomfort
- is perfectly normal, and reassure them that it's going to get
- better. Some of these warnings should take place privately, before
- the project is opened. But you may also find it helpful to remind
- people on the public lists that this is a new way of development
- for the project, and that it will take some time to adjust. The
- very best thing you can do is lead by example. If you don't see
- your developers answering enough newbie questions, then just
- telling them to answer more isn't going to help. They may not have
- a good sense of what warrants a response and what doesn't yet, or
- it could be that they don't have a feel for how to prioritize
- coding work against the new burden of external communications. The
- way to get them to participate is to participate yourself. Be on
- the public mailing lists, and make sure to answer some questions
- there. When you don't have the expertise to field a question, then
- visibly hand it off to a developer who does—and watch to make sure
- he follows up with an answer, or at least a response. It will
- naturally be tempting for the longtime developers to lapse into
- private discussions, since that's what they're used to. Make sure
- you're subscribed to the internal mailing lists on which this
- might happen, so you can ask that such discussions be moved to the
- public lists right away.</para>
-
- <para>There are other, longer-term concerns with opening up
- formerly closed projects. <xref linkend="social-infrastructure" />
- explores techniques for mixing paid and unpaid developers
- successfully, and <xref linkend="legal" /> discusses the necessity
- of legal diligence when opening up a private code base that may
- contain software written or "owned" by other parties.</para>
+ <para>Si vous libérez un projet existant, sur lequel travaillent
+ des développeurs actifs et accoutumés à travailler dans un
+ environnement propriétaire, assurez vous que tous comprennent
+ qu'un changement important va en suivre, et de votre coté,
+ vérifiez que vous êtes en mesure de faire face leurs
+ réactions.</para>
+
+ <para>Représentez vous la situation telle qu'ils la perçoivent :
+ tout le code et les décisions sur la conception sont faites par un
+ groupe de développeurs qui connaissent tous plus ou moins autant
+ le logiciel, qui reçoivent la même pression du même management, et
+ qui connaissent leurs forces et faiblesses respectives.
+ Soudainement, vous leur demandez d'exposer leur code pour qu'il
+ soit scruté par des étrangers ne formant leur jugement que sur le
+ code final, et sans prendre en compte la pression de la hiérarchie
+ qui a pu forcer certaines décisions. Ces étrangers posent de
+ nombreuses questions, des questions qui secouent des développeurs
+ lorsqu'ils réalisent que la documentation sur laquelle il avait
+ tant travaillé est <emphasis>toujours</emphasis> inadéquate (c'est
+ inévitable). Ajoutez le fait que tous ces arrivants sont inconnus
+ et sans visage... Si l'un des développeurs manquait d'assurance,
+ imaginez à quel point ce sentiment se trouvera exacerbé quand des
+ nouveaux contributeurs lui désigneront des faiblesses dans son
+ code, et pire, devant ses collègues. A moins de disposer d'une
+ équipe de développeurs parfaits, c'est inévitable, en fait cela se
+ produira probablement pour tous. Non pas qu'ils soient de mauvais
+ programmeurs; c'est simplement qu'au dessus d'une certaine taille,
+ un projet a des bogues et la revue par pairs permettra de les
+ détécter (voir <xref linkend="code-review" /><phrase
+ output="printed"> précédemment dans ce chapitre</phrase>). Dans le
+ même temps, les nouveaux arrivants ne seront pas eux mêmes sujets
+ à la revue par pairs puisqu'ils ne peuvent produire de code tant
+ qu'ils ne sont pas suffisamment familiers du projet. Pour vos
+ développeurs, cela peut être pris comme une situation de critique
+ dans un seul sens. Il y a donc danger de voir apparaître une
+ mentalité d'assiégés parmis les vétérans.</para>
+
+ <para>La meilleure façon de l'éviter est de prévenir le groupe de
+ ce qui va arriver. Expliquer leur que l'inconfort initial est
+ parfaitement normal, et rassurez les en leur assurant que les
+ choses iront en s'améliorant. Certains de ces messages peuvent
+ rester privés, avant que le projet ne soit ouvert. Mais vous
+ pouvez également trouver utile d'informer sur la liste publique
+ qu'une nouvelle méthode de développement pour le projet se met en
+ place, et qu'un temps d'adaptation sera nécessaire. La meilleur
+ chose que vous puissiez faire est de manager par l'exemple. Si
+ vous constatez que vos développeurs ne répondent pas suffisamment
+ aux questions des débutants, leur demander simplement d'y répondre
+ plus ne fera pas avancer les choses. Ils peuvent manquer de
+ discernement entre ce qui nécessite une réponse ou pas, ou ne pas
+ savoir comment prioriser le travail de développement face à la
+ nouvelle charge amenée par cette communication externe. Le moyen
+ de les faire participer est de participer vous mêmes. Soyez sur la
+ mailing liste publique, et répondez y à des questions. Si vous
+ n'avez pas l'expertise pour répondre à une question, désignez
+ clairement un développeur qui la possède, et vérifiez qu'il
+ fournira une solution ou au moins une réponse. Il peut être
+ naturellement tentant sur le long terme de glisser vers des
+ discussion privées, ce qui constituait après tout la situation
+ antérieure. Assurez vous de vous inscrire sur les mailing listes
+ internes sur lesquelles cela peut se produire pour être en mesure
+ de demander à déplacer ces discussions vers la mailing liste
+ publique.</para>
+
+ <para>Il existe d'autres considérations de long terme à prendre en
+ compte lorsqu'on ouvre un projet propriétaire. <xref
+ linkend="social-infrastructure" /> explore les techniques de
+ management permettant de faire travailler avec succès
+ contributeurs bénévoles et salariés, et <xref linkend="legal" />
+ discute de la nécessité d'un travail juridique consciencieux
+ lorsqu'on ouvre une base de code privée qui peut contenir du code
+ écrit ou "détenu" par d'autres tiers.</para>
</sect2>
</sect1>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
