きむらさん、今日は、上手です。
従来のMLで議論されていた諸点を、自然にクリアされている訳に驚きました。
ソフトウェアと英語を熟知されていることが、訳からすぐに解りました。
強力なメンバーの新参加を歓迎します。
このMLでは、指摘を有り難く受けるのは当然ですが、訳は ＊自分が自分で間違い
だと判断した以外は＊ 修正する必要はないと思います。私も頑固なのでよくと
ぼけます。
＃（が、たいてい指摘が正しいのが段々わかって来て、密かに修正しておきます）
という前提の下で、ちょっとコメントさせて下さい。
On Sat, 3 Jun 2000 21:53:08 +0900
"KIMURA Shinichi" <JAE01451@....jp> wrote:
> This is a multi-part message in MIME format.
>
> ----------------------------------------------------------------
> みなさんはじめまして(^_^)
> きむら(kimura363@....jp; JAE01451@....com)といいます。
> （@niftyで使っているハンドルで、きむら しんいちと名乗ることにします。）
>
> 矢崎(firo@....jp)さんからメールの回答をいただいたのがご縁でメーリ
> ングリストに参加させていただくことにしました。
> 以後よろしくお願いします。
>
> XPracticeの日本語版で、リンクが一部切れているとお知らせしたところ、
> 未翻訳なのでよかったら翻訳してみませんかとお誘いを受けました。
> それで、未訳と聞いたものの中から試しにひとつ訳してみました。
> 「CRC Cards」(http://w3.dreams.ne.jp/~pb1871/PracCRC.html)
>
オリジナルのURLを一番下に表示するようになってます。（別項参照して下さい）
> に相当する文章のつもりです。
> （訳文は、翻訳ソフトに下訳をしてもらったものをもとに、原文をみながら修正
> して作成しました。）
>
> ほかにもよかったら訳してみたいと思いますが、Smalltalkを知らないので、
> 術語の訳には誤りが出るかもしれませんし、既存の翻訳との整合性がない
> 文章になってしまうところもあるかと思います。
> （もちろん、そうしたこと以前に英文の解釈にも欠陥があるかと思いますが。）
>
> ところで、一連の翻訳にあたっての翻訳標準のようなものは決められている
> でしょうか？
> もしあるのでしたらその所在(URL？)を教えてください。
>
あまり無いと思いますが、矢崎さんがコメントしてくれると思います。
> それではまた(^o^)/
>
> --------ここから--------
> CRCカード設計
>
> 私たちは、CRCカード設計をほとんどいつも使います。開発者も管理者もユーザも、
> 全員がカードに対してくつろげるのは、おそれることなどないからです。カードを
ちょっと日本語として、こなれていない感じですね。
カードに対してうちとけているのは、そんなに重くないから・・程度のニュアン
スかな？
> 動かしてみることで、クラスがどうはたらくか記述するのがかんたんになります。
> もし設計がうまくいかなくても、カードの束を捨てて新しくするのはかんたんです。
>
a couple なので、カードを２枚くらい捨てて・・では？
> 私たちはカードを保存しませんし、結果を文書にもしません。クラスが設計の
> ドキュメントです：クラスがシステムの実際の表現なのです。
>
> 反論 「正しい設計プロセス」なしに、高品質システムを作成することはできない。
rigorous は 厳密な の方がいいような・・
> 私たちの設計プロセスはまったくもって正しいのです。多くの開発者が私たちの
> カード記入セッションに寄与します。その結果、開発者のチームがクラスの中に
> 設計を実現します。ただ、私たちは設計プロセスの副産物としての付随的な
> ドキュメントを生産しません。さらに、私たちはドキュメントの更新に時間を浪費
> することもなく、古びたドキュメントと過ごすこともないのです。敗者なし
> (win-win)
out-of-date は、古くなった とか 期限切れの 方が良いと思います。
win-win はMS-intel連合などの話しと思うので、そのままwin-winにするか、勝者
−勝者では？
> のアプローチというわけです。
>
> システムの品質は1300ユニット以上のテストによって保証されます。すべての
> クラスは、それが行うと想定されることを行っていることを保証する広範な単体
> 試験を持っています。
>
> システムの品質は何百もの機能テストによって保証されます。各テストは全体の
> システムを試します。端から端まで、またそれがその入力からの正確な出力を
> 計算することをチェックします。
>
> 反論 「正しい設計プロセス」なしでは、何を構築しているのかあるいは構築した
> のかを知ることはできない。
>
> 現実の世の中では、設計ドキュメントがソフトウェアの書かれた現実を反映する
同じことかもしれませんが、＊書かれたソフトウェアの現実＊ の方が解りやすい
かと。
（以上）
> ことはまれです：最新には保たれません。私たちの焦点は、実際のソフトウェア
> の品質と保守性にあるのです。
>
> Smalltalkの開発環境はソフトウェアを独り立ちさせます。適切な命名規約、うまく
> 設計されたクラス、それに強力なSmalltalk環境があれば、何がどう動くかを知る
> のはかんたんです。
> --------ここまで--------
>
>