覚えたら書く

IT関係のデベロッパとして日々覚えたことを書き残したいです。twitter: @yyoshikaw

「ビヨンド ソフトウェア アーキテクチャ」 - ソフトウェアアーキテクチャ

「ビヨンド ソフトウェア アーキテクチャ」第1章 ソフトウェアアーキテクチャ で気になった部分の抜粋

ビヨンド ソフトウェア アーキテクチャ (Object Oriented Selection Classics)

ビヨンド ソフトウェア アーキテクチャ (Object Oriented Selection Classics)


ソフトウェアアーキテクチャの定義

  • システムのあらゆる側面の中で、アーキテクチャ以上に「全体像」を扱うものは他にない。アーキテクチャを理解するにあたって本当の鍵となるのは、この全体的な観点で見ることなのだ。


ソフトウェアアーキテクチャに関する一考

サブシステムは人間のやる気や願望に応じて設計される

  • アーキテクチャを構築する責任を負ったチームの希望、体験、夢、恐れ、好みについて考慮しなければならない。


なぜソフトウェアアーキテクチャが重要なのか

安定性

  • アーキテクチャレベルで安定していれば、システムの機能追加リリースが何度繰り返されても、基本部分の手戻りは最小限で済むことが保証される。
  • 開発チームに重要な足場がもたらされる。
  • 安定していれば最高の価値をもたらす変更に集中できるようになる。

変更の度合いと性質

  • 顧客満足度を改善するための変更や、新規顧客を呼び寄せるための機能追加が容易になるような場合、私たちは普通そのアーキテクチャを「優れている」とみなす。

採算性

  • アーキテクチャを維持するコストがあまりに高くつくようであれば、そのアーキテクチャは破棄されることになるだろう。
  • 長期間使われているものなら、採算性の高いソリューションの基盤には、簡潔で洗練されたアーキテクチャの方が向いている。

アーキテクチャを置き換えるのにどのくらい工数がかかるだろうか?

  • 旧アーキテクチャと同等な機能を構築するには、最低でも過去に投資した額の20%はかかる。
  • 一般的に言うと、旧アーキテクチャと同等な機能を新アーキテクチャで構築するには、チームの規模や移行しようとしているシステムの複雑さにもよるが、旧アーキテクチャにかけたコスト全体の40%から60%はかかるだろう。

境界を定める

  • 何がシステムの「内側」にあり、何が「外側」にあるのかということについて膨大な数の決定を行う。
  • この境界と、境界を形作る方針は、アーキテクチャが最終的に成功するうえできわめて重要になるのだ。

持続可能で、圧倒的な優位性

  • アーキテクチャが優れていてれば、技術的に洗練されていて、真似もしにくく、競合に対する持続的な優位性を得られることになる。あなたのアーキテクチャが技術的な側面において真似しやすいものであったなら、別の競争ポイントを探さなければならないだろう(より優れたサービス、優秀な販路など)。


アーキテクチャの構築

  • 未成熟なアーキテクチャはフィードバックなしに成長することはできない


アーキテクチャの進化と成熟:フィーチャをとるかケイパビリティをとるか

  • フィーチャは、マーケティングによってはっきりと優先付けされているときが一番管理しやすい。そして、フィーチャ間の技術的な依存関係が開発チームによってきれいに整理されているときが、一番うまく実装できる。フィーチャは関連しあっているからだ。
  • アーキテクチャとは、求められたフィーチャを比較的容易に実装できるようにするものだと言える。
  • 再設計、再構築のきっかけは、遡ると、増えていく顧客に対して可能な限り急いで新しいフィーチャを提供してきたことが原因であることが多い。端的に言えば、成功は適切に管理しないと、失敗の元になるのだ

エントロピーの縮小 ~リリースの後に必ず技術的負債を支払う~

  • プロダクトを出荷した後で、ソースコードを改善するための十分な時間を割かなければならない。私はこれを「エントロピーの縮小」(ER、Entropy Redution)と呼んでいる。
  • ある開発部門ではER活動によっていくつもの重要な利益を得ることができた
    • ソースコードレベルの品質に対する集中を保ち続けることができる
    • 開発チームでいことをする意識が強化される。優れた開発者はプロダクトを出荷するためにソースコードへ妥協の産物を埋め込むことをためらう。きれいにする許可を出さなければ彼らの品質に対するモチベーションは「死んでしまう」だろう。彼らの品質に対する感覚が擦り切れてしまうと、それはプロダクトにはね返ってくる。
    • 保守性が劇的に改善し、システムの拡張性も劇的に高まる。
    • チームが、システムの特定の振る舞いについてきちんと理解できるようになる
  • ER活動を活動を無事に進行させるためのベストプラクティス
    • リズムを定着させる。リズムに合わせたリリースは私にとってとても重要だった。うまくやっているチームにはリズムが定着していた。
    • ER活動にタイムボックスを設定する。一週間から二週間が一番よい。実りあるER活動のために四週以上必要になるようだったら、鏡に向かって「おまえのアーキテクチャはもう死んでいる」と告げてあげよう。


アーキテクチャへの配慮と手入れ

  • アーキテクチャとは慎重に手がけられた庭のようなものだ。
  • アーキテクチャへの配慮と手入れとは、新しいフィーチャやケイパビリティを追加することではなく、それらを良い形に保ち続けることなのだ。

技術的負債

  • 本来やるべきでないハック等の妥協の産物は技術的負債の一種であり、基礎となるケイパビリティがない状態でフィーチャを実装した場合に起きることとよく似ている。この負債の返済もアーキテクチャへの配慮と手入れの一端を担う。


一に原則、二に原則、三に原則

カプセル化

  • アーキテクチャは、分離された相互に独立した部品から構成される。そしてそれらの部品は内部に実装を他から隠蔽している。
  • カプセル化が推し進められたシステムでは、それぞれのサブシステムの内部もカプセル化されている。

インターフェイス

  • 大規模な設計において、サブシステム間のやりとりは明確に定義される。そうしたやりとりについてシステムが稼働している限り比較的安定していられるように定義できれば理想的だ。そのための方法の一つが、具体的な実装を超えた抽象化である、抽象に対してプログラミングすれば、実装を変更しなければならなくたったとしても、はるかに柔軟でいられる。

疎結合

  • 一般的に、疎結合な部品は理解しやすく、テストも再利用もしやすいうえに、保守も簡単だ。なぜならシステム内のほかの部品から独立しているからだ。

適切な粒度

  • 疎結合に関連する大きな課題の一つがコンポーネントの粒度だ。どの粒度が適切かは、コンポーネントが関連するタスクに応じて定まる。

高凝集

  • 私たちが最も凝集度が高いとみなすのは、内包する要素が一つだけの仕事をこなすようになっているコンポーネントだ。

パラメータ化

  • 最も効果的なコンポーネントは、利用する側が制御できるよう適切な数のパラメータを使って、適切な量の仕事をする。パラメータ化の洗練された形式が「制御の反転(IoC)」だ。これはコンポーネントの制御を外部に任せる方法で、フレームワークやプラグインアーキテクチャでよく使われている。

遅延

  • 決定をできる限り遅らせることによって、開発チームは全体として正しい選択をするための最高のタイミングを計ることができる。