きむらです。
以下、上手さんからいただいたコメントに応えます。
>> --------ここから--------
>> CRCカード設計
>>
>> 私たちは、CRCカード設計をほとんどいつも使います。開発者も管理者もユーザ
も、
>> 全員がカードに対してくつろげるのは、おそれることなどないからです。カード
を
>
>ちょっと日本語として、こなれていない感じですね。
>カードに対してうちとけているのは、そんなに重くないから・・程度のニュアン
>スかな？
そうですね。たしかに不自然な日本語でした(^^*)
「うちとける」という言葉、いいですね(^^)
採用させてもらいますね(^_^)
<訂正部分訳>
私たちは、CRCカード設計をほとんどいつも使います。開発者も管理者もユーザも、
誰もがカードに対してうちとけています。おののく必要もないからです。
</訂正部分訳>
>> 動かしてみることで、クラスがどうはたらくか記述するのがかんたんになりま
す。
>> もし設計がうまくいかなくても、カードの束を捨てて新しくするのはかんたんで
す。
>>
>
>a couple なので、カードを２枚くらい捨てて・・では？
そうかもしれませんが、ちょっと自信がありません(^^;)
CRCカードセッションって、実際にやってみたことがないのですが
普通は何人くらいでするものなんでしょう。クラスの種類の数だけ
人がいるのかな。
（個人的に付箋紙にひとつずつ書いたクラス名を机上で並べ替え
てクラス相関を考え直したりしたことはありますが、ほんもののCRC
セッションってやったことがないのです(^^;)）
もしCRCセッションというものが通常（ペア疋プログラミングの原則
からの想像ですが）二人でするものだとすると、a couple of cardsは
（ふたりで１セットの）カードの束の組のことかもしれませんね。
しかし、上手さんのおっしゃるように、a couple ofは限定的に２つの
という意味ではなく、いくつかという程度の意味しか込められていない
（話し言葉としての用法）かもしれません。
これがいちばんありそうです。
<訂正部分訳>
カードを動かしてみることで、クラスがどうはたらくか記述するのが
かんたんになります。もし設計がうまくいかなくても、カードを何枚か
捨てて新しくするのはかんたんです。
</訂正部分訳>
>> 私たちはカードを保存しませんし、結果を文書にもしません。クラスが設計の
>> ドキュメントです：クラスがシステムの実際の表現なのです。
>>
>> 反論 「正しい設計プロセス」なしに、高品質システムを作成することはできな
い。
>
>rigorous は 厳密な の方がいいような・・
そのとおりですね(^^)
<訂正部分訳>
反論 「厳密な設計プロセス」なしに、高品質システムを作成することはできない。
</訂正部分訳>
>> 私たちの設計プロセスはまったくもって正しいのです。多くの開発者が私たちの
>> カード記入セッションに寄与します。その結果、開発者のチームがクラスの中に
>> 設計を実現します。ただ、私たちは設計プロセスの副産物としての付随的な
>> ドキュメントを生産しません。さらに、私たちはドキュメントの更新に時間を浪
費
>> することもなく、古びたドキュメントと過ごすこともないのです。敗者なし
>> (win-win)
>
>out-of-date は、古くなった とか 期限切れの 方が良いと思います。
たしかに「古びた」より「古くなった」のほうがなじみやすいですね。
修正しましょう。
>win-win はMS-intel連合などの話しと思うので、そのままwin-winにするか、勝者
>−勝者では？
ここは自己訂正されていますので、このままとします。
<訂正部分訳>
私たちの設計プロセスはまったくもって厳密です。多くの開発者が私たちの
カード記入セッションに寄与します。その結果、開発者のチームがクラスの中に
設計を実現します。ただ、私たちは設計プロセスの副産物としての付随的な
ドキュメントを生産しません。さらに、私たちはドキュメントの更新に時間を浪費
することもなく、古くなったドキュメントと過ごすこともないのです。敗者なし
(win-win)のアプローチというわけです。
</訂正部分訳>
regorousの訳語は「厳密な」で統一しておきます。
<訂正訳>
反論 「厳密な設計プロセス」なしでは、何を構築しているのかあるいは構築した
のかを知ることはできない。
</訂正訳>
>> 現実の世の中では、設計ドキュメントがソフトウェアの書かれた現実を反映する
>同じことかもしれませんが、＊書かれたソフトウェアの現実＊ の方が解りやすい
>かと。
ここはちょっと迷ったところです。
最初は「書かれたソフトウェアの現実」としていたのですが、
これを文脈に埋めこむとこうなります：
<試訳例>
現実の世の中では、設計ドキュメントが書かれたソフトウェアの現実を反映する
ことはまれです：最新には保たれません。私たちの焦点は、実際のソフトウェア
の品質と保守性にあるのです。
</試訳例>
こうなると、頭から読み下していく場合に「設計ドキュメントが
書かれた」という区切りで誤って読み取られるおそれがあります。
<誤>
（（設計ドキュメントが書かれた）ソフトウェア）の現実を反映することはまれ
です
</誤>
ではなく
<正>
設計ドキュメントが（（書かれたソフトウェア）の現実）を反映することはまれ
です
</正>
という構造の文であることをはっきりさせたいと思いました。
あらためて考え直すと
<A>
設計ドキュメントはまれにしか書かれたソフトウェアの現実を反映しません
</A>
とか
<B>
設計ドキュメントがソフトウェアに書かれた現実を反映することはまれです
</B>
としたほうがわかりやすいかもしれませんね(^_^)
この直後にコロンで区切って続く文が
<続く文>
最新には保たれません。
</続く文>
と否定形ですから、否定文が連続してくどくなるのを避けるなら、
AよりもBのほうが好ましいでしょうか。
結局、もとの試訳で「ソフトウェアの」としていたところを「ソフトウェアに」
と修正することにします。
<訂正部分訳>
現実の世の中では、設計ドキュメントがソフトウェアに書かれた現実を反映する
ことはまれです：最新には保たれません。私たちの焦点は、実際のソフトウェア
の品質と保守性にあるのです。
</訂正部分訳>
では、コメントを受けて修正した全体をあらためて掲げます：
<試訳 revision="2">
CRCカード設計
私たちは、CRCカード設計をほとんどいつも使います。開発者も管理者も
ユーザも、誰もがカードに対してうちとけています。おののく必要もない
からです。カードを動かしてみることで、クラスがどうはたらくか記述する
のがかんたんになります。もし設計がうまくいかなくても、カードを何枚か
捨てて新しくするのはかんたんです。
私たちはカードを保存しませんし、結果を文書にもしません。クラスが設計の
ドキュメントです：クラスがシステムの実際の表現なのです。
反論 「厳密な設計プロセス」なしに、高品質システムを作成することはできない。
私たちの設計プロセスはまったくもって厳密です。多くの開発者が私たちの
カード記入セッションに寄与します。その結果、開発者のチームがクラスの中に
設計を実現します。ただ、私たちは設計プロセスの副産物としての付随的な
ドキュメントを生産しません。さらに、私たちはドキュメントの更新に時間を浪費
することもなく、古くなったドキュメントと過ごすこともないのです。敗者なし
(win-win)のアプローチというわけです。
システムの品質は1300ユニット以上のテストによって保証されます。すべての
クラスは、それが行うと想定されることを行っていることを保証する広範な単体
試験を持っています。
システムの品質は何百もの機能テストによって保証されます。各テストは全体の
システムを試します。端から端まで、またそれがその入力からの正確な出力を
計算することをチェックします。
反論 「正しい設計プロセス」なしでは、何を構築しているのかあるいは構築した
のかを知ることはできない。
現実の世の中では、設計ドキュメントがソフトウェアに書かれた現実を反映する
ことはまれです：最新には保たれません。私たちの焦点は、実際のソフトウェア
の品質と保守性にあるのです。
Smalltalkの開発環境はソフトウェアを独り立ちさせます。適切な命名規約、うまく
設計されたクラス、それに強力なSmalltalk環境があれば、何がどう動くかを知る
のはかんたんです。
</試訳>
オリジナルURL：<http://www.xprogramming.com/Practices/PracCRC.html>
以上です。
ほかにもなにかお気づきの点があればいつでもどなたでも
お気軽にご指摘ください。