著作一覧 |
島田さんからもらった進化的アーキテクチャを読了した。
良い本だと思うし、サジェスチョンと確認と方向づけなど有意義な内容に満ちている。
なので、現在のエンタープライズアーキテクチャー(あるいはある程度の規模、たとえばモデルが8クラスを越えたあたりのWebアプリケーションなど)を構築する場合、あるいはなんらかの改造、修正、移行をする場合には一読しておきたい。
要点と勘所をメモもかねて書く。
ただ、もらっておいてなんだが、本書は良くない点も多い。
最初に、(というのは、要点と勘所を書く前に明らかにしておきたいからだし、正誤表的なメモを最初に掲示しておく意味があると思えるからだが)苦言を書く(もしかすると、このエントリーはそれで終わるかも。最初にネガティブなことを書いて後から誉めるのは悪手だが、それでも本書については最初に苦言を書くべきだと思う)。
本書は、読みにくい。
「読みにくい」という言葉を使うにあたって、おれの立場と言葉についての含意を説明する必要がある。
基本的におれは「読みにくい」とか「難解」とかいう言葉を発するやつは、少なくとも対象の書籍を読む最低条件を満たしていないか、またはそもそも読解力に欠けている無能者だという立場だ。要するに負け犬用語、負け犬判定用の言葉である。
しかし、おれは本書を読む最低条件を満たしていないとはまったく考えていない。読解力はどちらかといえば控え目に言っても並みのレベルは越えている(読み過ぎて壺にはまることはあるとしても)。にもかかわらず読みにくい。おれは負け犬か? いや、本気で本書は読みにくいのだと考えざるを得ない。
本書の場合、こういうことだと考える。
執筆者が高い位置から全体を書こうとしているために、比較的新しい概念を持ち込んだり、既存の概念と衝突するが微妙に異なるような場合に、積極的に新しい用語を発明している(のだと考えられる)。あと、アーキテクト、コンサルタントとしての(利用する用語についての)気取りを捨てきれていないのではなかろうか。好意的に解釈すれば、少ないページ数に考えを凝縮させるために言葉に意味を詰め込み過ぎたのだろう(そのため、原書を読んでも同様に意味が通らない箇所はあると考えられる)。
それに対して、島田さんがあまり適切ではない訳語を持ち込んでいたり、消化しきれずに訳してしまった箇所がある。
また、全体的に抽象的な説明や筆者の考え方の開陳が多いため、確立しきっていないものを説明するために言葉があやふやになっている箇所を、おそらく咀嚼しきれずに訳したか、あるいは本人は咀嚼していても日本語に落とし切れていない。内容が抽象的なところについては、校正もうまく機能していなそうだ。
たとえば最悪の例としてP.151の継続的デリバリーを選択すべき理由を解説した箇所の結論部分の段落(ただし、英語のまともな本なので、各節は、重要事項の提示(結論)-補説-具体例についての説明―提示部をそれに合わせて再現―という構造なので、抜粋部分は再現部に相当し、日本語の意味での結論ではない)を抜粋する。
一般的なビルドツールは、いずれもこのレベルの機能(引用者注:依存しているコンポーネントの最新バージョンの非互換性を検出したら、静的に現状の利用可能なコンポーネントのバージョンを自動的に記録し自動更新から防御する機能。BundlerのGemfileは自動ではないので、これには当てはまらない)はサポートしていない。そのため、開発者は既存のビルドツールの上にこの知性を構築する必要がある。しかし、この依存関係のモデルは、サイクルタイムが重要な基礎を成す値であり、他の主要なメトリクスの多くに比例する、進化的アーキテクチャにおいて非常にうまく機能する。
呪文みたいだ。「知性」はインテリジェンス(この場合は非互換検知による自動静的バージョン固定機能、継続的デリバリーのためのスクリプトに自分で実装する)という意味だろうと想像がつくが(それでも、インテリジェンスにしても知性にしても、適切な言葉ではないだろう)、「しかし」の後は言葉のサラダみたいだ。
原文を読んでいないから想像でしかないが、日本語であれば次のようになると考えられる。
「一般的なビルドツールには依存しているコンポーネントのバージョンを固定する機能がない。そのため、開発者自身が実装する必要がある。実装コストをはらってでも継続的デリバリーを選択するのは、依存関係を適切に解決することがサイクルタイムを短く保つためのキーファクターであり、進化的アーキテクチャを正しく構築するためには、他の主要メトリクス以上に重要だからである。」
(追記:「比例」というのは上の解釈と違って、「(依存関係を正しく処理することは)主要メトリクス全般に影響する。このため、進化的アーキテクチャをうまく機能させることができる。」という意味かも)
というような具合に読み替えが必要なので、読みにくい、と言わざるを得ない。
以下目立ったところ。
P.9
「アーキテクチャの一部はしばしばガバナンス活動だとみなされてきた。しかし、アーキテクトは最近になってアーキテクチャを通じた変更を可能にするという考え方を受け入れてきている。」
何がなんでも意味不明。ガバナンス活動=変更を不能とするほどの統制、という意味か?
(これは原書もおそらくガバナンスアクティビティとしているのだろうが、統制に対してアーキテクチャを通じて変更するというはいきなりそう書かれても意味がわからない。ただ、落ち着いて考えると、組織論に対する逆方向の影響について良く書いてあるからわからなくはないか)
P.27
「アップグレード中断テスト」
意味はわかるが、用語を投げて投げっぱなし(これは原書の問題だろう。節題ですらない重要な概念(ボルドを使っている)を投げっぱなしにして良いのか?
P.37
「彼らが解かなければいけない儀式であるとみなす罠」
決まり文句とかボイラープレートとかおまじないとかに訳したほうが良いのではなかろうか。というか「解かなければいけない」に「儀式」はかからない。日本語にするなら「彼らが封じなければならない呪い」(解くの逆の意味だが「封じる」に訳したほうが日本語としては良いと思う)
P.75
「一般的に大きくなるものが、安定もしている」
タイポ? 「一般的に大きくなるものの、安定している」あるいは「一般的に巨大化するが、安定している」
という意味だと思うが、順接の「が」で「安定」に繋いでいるので意味が不明。
P.79
「結合度が低め、」
普通のタイポ。「結合度を低め、」
(P.110 オプション3はとても良いというか、なるほど! と真似することにした。と、メモ)
P.113 5.2.1
これはひどい。節題が「2相コミットトランザクション」だが、どこにも2フェーズコミットについて書いてない。(おそらく原書が悪い)
内容を読めば、サービスを分割していくと分散トランザクションが必要となるため、2フェーズコミットのような機構が必要になる、ということなのだが……
(P.115 重要なことが書いてある…… 付箋紙を元にだめな点を挙げて行くことにしたのだが、段々暗澹たる気分になってきたので、気づきマークについても()内に少し入れることにした)
(P.123 ぽろっと「進化的アーキテクチャを構築することにおける最大にして唯一の障害は、扱いにくい運用だ。」という文が紛れている。なぜ、独立した項目にしない?(おそらく筆者たちは実運用に深くコミットしたことはなく、ただ現実問題として運用が障害になっている事例を知っているからではなかろうか))
(P.124 COTSは存在自体が障害(とまでは書いていない))
(P.126 最高におもしろい)
P.131 「赤で示す」
原書はカラー印刷なのかな? いずれにしても網掛けの工夫が必要そうだ。実際は和集合の箇所とはわかるけど。
(P.140 技術的負債の再定義。早すぎる最適化も技術的負債である(利用されなかった場合))
P.143 「サービステンプレート」
具体性に欠け過ぎている。想像はつくが、もう少し説明なり参照ポイントなりを出すべき。
(serverspecとかかなぁ、それとももっと良いものをThoughtworksは持っているのか?)
P.149 くだらない(としかメモが無いけど単なるページの埋め草と思ったのかな?)
P.151 「内部的にサービスをバージョン付けする」
言いたいことはわかるが、抽象的にしようとしてどう考えても失敗している。または誤訳。
本章では、外部APIにバージョンを付けることと、内部でバージョン分岐をすることの2つの方法を示しているのに、節題は「内部的にサービスをバージョン付け」としているので意味がわからない。ただし、結論は内部解決が良い、だがバージョン付けとナンバリングが完全に異なるというのがわかりにくい(バージョンは普通ナンバーだから)。
まあ、当たり前といえば当たり前のことではあるから書いてあることはわかるけど。
(P.156 クリーンアーキテクチャがなぜ必要なのか)
(P.163 圧倒的に正しい。ただし、コード:メタデータ≒サービス:インスタンスが混乱した記述になっている)
(P.179 とても良い提言。取り入れる)
P.199 「ソフトウェア開発エコシステムの動的平衡によって、予測可能性は効力を失っている。」
意味不明。そもそも平衡していないから予測可能ではないのではないか? 動的平衡言いたかっただけだろ的な。
「ソフトウェア開発エコシステムがもたらす急激な変化は業界バランスを容易に崩してしまう。このため予測可能だとは考えないことだ」くらいに訳さないと(おそらく原文含めて)意味が通らない。と、思うけど(自信なくなってきた。動的平衡を個別に進化することのような意味で使うのが正しいのかなぁ)
(P.202 順応とは並列であり、進化とは統合である。(だから進化を選択せよという話))
とりあえず以上
ジェズイットを見習え |
厳しいご指摘を重く受け止めつつ、よくできるタイミングで少しずつでもよくしていきたいと思います。ありがとうございます。<br>気になったところ、おそらく他にもあるのだと思いますので雑な形ででも個別にでもかまいませんので、いただけますとありがたいです。
これだけの難物の翻訳、興味のある分野なのでいただいたことも含めて、あらためて、どうもありがとうございます。<br>内容から早めのリリースも重要だったのだとは想像がつきますが、上でも半分は原書の書き方があまり良くない(副題の2相コミットが本文に出てこないなんていうのは原書自体の問題だと思います)としているように、元の文章が相当荒かったのだろうとは想像がつくので、大変な作業だったと思います。お疲れさまでした。<br>ちょっと勢いに任せて書きなぐったので、意図よりもきつい書き方になっているかも知れません。もしそうだったらごめんなさい。<br>とりあえず、意味がわからないか、あまりに引っかかって読み直しが必要だった箇所についてはほぼ網羅したので、ここまでです。むしろタイポが少ない(上の「が」の2点しか気づきませんでした)のはすごいと思いました。
> これだけの難物の翻訳、興味のある分野なのでいただいたことも含めて、あらためて、どうもありがとうございます。<br>内容から早めのリリースも重要だったのだとは想像がつきますが、上でも半分は原書の書き方があまり良くない(副題の2相コミットが本文に出てこないなんていうのは原書自体の問題だと思います)としているように、元の文章が相当荒かったのだろうとは想像がつくので、大変な作業だったと思います。お疲れさまでした。<br><br>そう言っていただけると、大変うれしいです。ありがとうございます。<br><br>> ちょっと勢いに任せて書きなぐったので、意図よりもきつい書き方になっているかも知れません。もしそうだったらごめんなさい。 <br><br>いえいえ、こういったことを書いていただくのはご負担がかかることだと思いまして、それでもこんな風に書いていただけたことに感謝しています。ありがとうございます。<br><br>> とりあえず、意味がわからないか、あまりに引っかかって読み直しが必要だった箇所についてはほぼ網羅したので、ここまでです。<br><br>ありがとうございます!それでは、ここでご指摘いただいたことを踏まえて改めて全体を見直しまして、次に改訂できるチャンスがありましたら、できる限りの改善を試みたいと思います。