佃です。
Kazuyuki Kuribayashi wrote:
>
> 栗林です。
>
> 担当分を翻訳しました。
> 誤訳等ありましたら、びしびし指摘してください。
>
> なお、
> 10. CRC Cards
> のところを担当したいのですがよろしいでしょうか？
>
> ＃CRC Cardは、この翻訳パートと関係が有りそうですので。
>
> --------------------------------------------------------------------------
>
> The Four ValuesThe Four Project Values
> プロジェクトの４つのバリュー
>
> ●簡潔さ
>
> われわれは、「仕事をできるだけ単純にすます」ために常に多くの努力をします。
>
> われわれはこれについて、かなり神経質になります。
>
> われわれは、正しいアーキテクチャとcorrectly-factored codeを見出せれば、
> ニーズが起こった際に、われわれのソフトウェアを速やかに拡張できます。
文章の区切れは、以下のようではないでしょうか？
correctly-factored codeによりわれわれのソフトウェアを速やかに拡張できる、ということを知っている。
>
> われわれが「必要とする」あるものについて働きかけれれば、
> われわれは必要する何かに働きかけることはなくなるであろう。
「今やるべきことをやればいい、将来やるかもしれないことは今やらなくてよい。」をいＸＰう思想を書いていると思いますが、どう訳せばいいのでしょうねえ。
難しい。
>
> ●コミュニケーション
>
> われわれは可能な限りの方法でコミュニケーションについて強調します。
>
> われわれのコードでは、
> みんなが同じフォーマント規約、命名規約やコーディング標準を使います。
>
> これは、「たとえ、すべての方法を書き留められたとしても、
> それらの方法にたまたま出会ってから、よく知るようになったり、
> 簡単に理解できるようになります。」ということを意味しているのです。
>
私のイメージです。
「（他人が書いた）メソッドに出会ったとき、誰が記述したものでもすべてのメソッドの見た目は同じであり、理解しやすい」
以下でもmethod、objectが出てきますが、これはオブジェクト指向の用語なので、そのままカタカナで訳した方がいいと思います。
> われわれは、アルゴリズムではなく意図を表現するようにコードを書きます。
>
> われわれの方法の名前は、いかにそれを成し遂げるではなく、
> 何を成し遂げるについて表しています。
>
> あらゆるレベルで、人間が読みつづけれるような記述で、
> われわれは自分たちの方法を作るろうとしています。
>
> それで、われわれはCRCカードを使って、設計情報を伝達することができます。
>
> われわれは新しいいくつかの新しい目標に向かって仕事を始めるときはいつでも、
> われわれの中の少数の人々が椅子にすわって同じカードを使います。
>
> われわれが大きな変更を行うときはいつでも、
> われわれは、すでに何が終わったかについての情報を、
> より大きなグループがいっしょに得たり、気付いたりできます。
>
> しかし、形式的な文書化についてはどう思いますか？
>
> ●テスティング
>
> われわれはテスト作業については狂信的になります。
>
> われわれが、実際のコードを作るより、それ以上にもっとたくさんのソース行を
> テストするのがのぞみです。
「実装のコードよりも多くのテスト用のコードを作成すること」を述べていると思います。
テスト用のコードとは、単体テストなどで書くスタブとかスケルトンでしょう。
>
> あらゆるクラスは、そのクラスに対応した単体テストを行わなければなりません。
>
「テスト用のクラスを持たなければならない。」
テスト用フレームワークの解説記事に詳細がありますが、本番のクラス以外にテスト用のクラスを導入しています。
http://member.nifty.ne.jp/masarl/article/testing-framework.html
この記事はデザインパターンの知識がなければ、理解することはできないですが。
> 各々のパブリックメソッドは少なくとも一度以上は単体テストをすべきです。
>
「（実装クラスの）メソッドは、少なくとも１つ以上のテストクラスのメソッドを持つ。」
（実装クラスの）メソッドをテストするための、テストクラスのメソッドが存在することを言ってます。
> 現在のわれわれは、システム当たり1400個以上の単体テストを行います。
>
> われわれがコードをリリースするときには、
> すべての単体テストは100%実行されていなければなりません。
>
> あなたがたは、
> 100%単体テストが実行されていなければリリースすることはできません。
> もし、単体テストが完了していなければ、問題を速やかに解決します。
>
> われわれは、同じように機能テストを行います。
> 一人か一人以上の人が注意を払い、テスト結果を調べながら、
> システムのすみからすみまで機能テストを行います。
>
> 100種類くらいの機能テストがあります。
>
> このすべてのテストの結果から、われわれはシステムが動作していることを
> 確認します。エラーが起こったときは、われわれは、すみやかにそれを
> 発見します。
>
> ●積極性（恐れないこと）
>
> ほかの三つのバリューの効果から、恐れないで積極的に対処することができます。
>
> われわれは、色んなテストの堅牢なシステムを確保しているので、
> より良くシステムの部分を変更することができます。
>
> われわれは色んなことを試すことができます。
> もし、テストの動作が気に食わなければ、それらを捨てて、もう一度試します。
>
> We know we won’t break the system,
> which gives us the confidence to move forward rapidly.
> ＃うまく訳せませんでした。
Sugisaku Nakao wrote:
>
> 中尾です
>
> > We know we won’t break the system,
> > which gives us the confidence to move forward rapidly.
> > ＃うまく訳せませんでした。
> このような感じではどうでしょうか？
>
> 「システムを壊してしまうようなことが起きないのを我々は知っています。
> それが我々に全速前進する自信を与えてくれるのです。」
>
こんな感じではないでしょうか？
「我々全速前進する自信を与えてくれるシステムを壊したくないことを知ってます」
「システムをいじると、再テストをしなくてはならないが、そのための仕掛け（テスティングフレームワーク）はある。再テストにより、システムの信頼性が確保できる。
だから、システムの一部を変更しても、その後も自信を持って仕事が出来ますよ」という感じではないでしょうか。
>
> ---
> オリジナル http://www.xprogramming.com/
> Copyright (c) 1999, REJeffries et al. (ronjeffries@....org)
>
> ----
> Kazuyuki Kuribayashi kuribayashi@....jp
--
佃 軍治 tsukuda@....jp
日立製作所システム開発研究所第２部