Pythonによるアーキテクチャパターン

エピローグ

どうする？

ふぅ！本書では多くの分野をカバーしてきたが、ほとんどの読者にとって、これらのアイデアはすべて新しいものだ。そのことを考えると、これらのテクニックのエキスパートになることは望めない。私たちにできることは、大まかなアイデアと、あなたがゼロから何かを書くのに十分なコードを紹介することだけだ。

本書で紹介するコードは、戦闘で鍛え上げられたプロダクション・コードではない。最初の家や宇宙船、高層ビルを作るために遊べるレゴブロックのセットなのだ。

残された課題は2つある。既存のシステムでこれらのアイデアを実際に適用し始める方法について話すことと、省略せざるを得なかったいくつかの事柄について警告することだ。自分の足を撃つための新たな武器庫を手に入れたのだから、基本的な銃器の安全性についても説明しなければならない。

ここからどう行けばいいのか？

多くの人がこんなことを考えているのではないだろうか：

「よし、ボブ、ハリー、それはいいことだ。もし僕がグリーンフィールドの新サービスに雇われることになったら、どうすればいいかわかったよ。でもその間に、僕はジャンゴの泥の大きなボールと一緒にここにいる。ここからではない"

お聞きしたい。一度大きな泥の玉を作ってしまうと、どのように物事を改善していけばいいのかわからなくなってしまう。本当に、一歩一歩物事に取り組む必要がある。

まず最初に、どんな問題を解決しようとしているのか？ソフトウェアを変更するのは難しすぎるか？パフォーマンスが受け入れられないのか？奇妙で不可解なバグがあるのか？

明確な目標を持つことで、行うべき作業に優先順位をつけることができ、重要なことは、それを行う理由をチームの他のメンバーに伝えることができる。企業は、技術的負債やリファクタリングに対して現実的なアプローチをとる傾向があるが、エンジニアが物事を修正するための理にかなった引数を立てることができる限りは、技術的負債やリファクタリングは行わない。

チップ

システムに複雑な変更を加える場合、それを機能的な仕事とリンクさせれば、売り込みやすくなることが多い。おそらく、新製品を発売したり、新しい市場にサービスを開放したりするのだろう。これは、エンジニアリングリソースを基礎の修正に費やすのに適したタイミングだ。納期が6ヶ月のプロジェクトなら、3週間のクリーンアップ作業の引数を稼ぐのは簡単だ。ボブはこれをアーキテクチャ税と呼んでいる。

絡み合った責任を分離する

本書の冒頭で、大きな泥の玉の主な特徴 、同質性であると述べた。システムのどの部分も同じように見えるのは、各コンポーネントの責任を明確にしていないからである。それを解決するためには、責任を分離し、明確な境界線を導入する必要がある。最初にできることのひとつは、サービス・レイヤーの構築を始めることだ（図E-1）。

図E-1. コラボレーション・システムの領域

[plantuml, apwp_ep01, config=plantuml.cfg] @startuml hide empty members Workspace *- Folder : contains Account *- Workspace : owns Account *-- Package : has User *-- ...