概要
自分が以下のような立場でレビューをする側だったらどんなことを考えればいいかをまとめてみる
- 製品の全体図、ドメインは少し分かる
- 製品としてどんな姿を目指していきたいか少しわかる
そもそもアーキテクチャって?
アーキテクチャーとは力のバランスであり、多くの場合、完全に満足のいくものには決してならない、一連の最適でないトレードオフの結果である。優れたパフォーマンス、優れたスケーラビリティ、優れたセキュリティ、優れたメンテナンス性、優れたユーザビリティなど。
ソフトウェアアーキテクチャの目標は、QARを満たすことである。少なくとも、QAR(品質属性要件)のほとんどを満足させるような合理的な選択をすることである。なぜなら、そのすべてを完璧に満たすことは不可能だからだ。アーキテクトのスキルは、トレードオフのバランスをとることである。
ポイントとその訳
現状 / 改善後が整理されていて、現状のときのデメリット、改善後のメリット・デメリットが整理できているか。また改善後のメリットが正しいか。どんなトレードオフがあるのか考慮されているか。改善パターンは一つだけなのか、なぜ別の代替手段がないのかを明らかにする。なぜなら、1つの案だけだと、比較ができず、その案についてのやるやらで議論が進んでしまい、他検討事項を無視して決定が行われてしまう可能性がある。 どんな制約が生まれるかも考えられているか。デメリットに書いてあるかもしれないが念のため。変更によって生まれる今後できないことはありそうなのかが焦点。決定によって、どんな技術的負債が発生するのか明確にする。
何かの責務をわけるために分割する場合、分割される A は A として独立してデプロイが可能か。独立性の正当な理由が明らかにされているか。例えば、A をモノリスの中に組み込んでいると性能問題が発生する。A についてオーナーシップを持つチームを作りたい、A がビジネスの広がりを見込める等の理由により。 逆に、ある機能を実装するときに A と同時にデプロイしなければならない、A を色んなチームが変更しないといけないようなことがある場合は要注意だろう。性能面を確保できるかもしれないが、開発生産性を落とすことになりかねない。そういう場合のトレードオフ理解があるか。 また、小さくすることが目的になっていないかサービスを小さくすればするほど、仕事をこなすためにシステムの他の部分とコミュニケーションを取らなければならなくなる。コミュニケーションをとるほど、「ネットワーク転送」コストを支払うことになる。どのサービスがどれと会話してるかを理解するのが難しくなるのは言うまでもない。サービス間のコミュニケーションが多いと見込めるなら、それは分割対象としてふさわしくないだろう。
作り込み過ぎていない？やりたいことを実現する手段が複雑になっていないか。もっと簡単に試せる方法がないか。例えば、Outbox パターンの運用をするときに Debezium, kafka のような構成を取るのか、まずは Debezium にあたる部分をアプリケーションでポーリングするものを作る、SQS で代用してみるとか。middleware の導入はその製品に詳しい人がいないと運用上問題が起きたときに困るかもしれない。それなら、自分たちが実験してみたいミニマム要件のものを作って後から差し替えればいい。ただ、middleware を利用したほうが早く実験できるとなれば話は別。
フィードバックをもらうのにどのくらい時間がかかる？長くなる場合は危険かもしれない。アーキテクチャの成功は、レビューが通ったからではなく、実世界で使われてからわかる。そのフィードバックを得るためにはなるべく早く世に出す必要がある。なので、アーキテクチャの刷新で初手ビッグバンな計画は避けたい。できるだけ小さく達成できるものをピックして試す。どうしようもないときがあるかもしれないが稀かと思う。トレードオフとして比較すれば、小さく改善を進めるのがよいという結論になるかと思う。 例えば、アーキテクチャがうまく行かなかかった場合は元に戻したほうがまだましな時があるかもしれない。そのときのコストは?小さく作っていればもちろんコストは低い。
どんな品質属性要件が求められている?この質問でどれだけプロダクトやビジネスの解像度があるかわかる。
他にもあれば教えてほしい。
参考
Software Architecture: It Might Not Be What You Think It Is 12のソフトウェア・アーキテクチャの落とし穴とその避け方
上記の記事で印象だったところ
アーキテクチャー上の課題に取り組んだ経験のある人材を解雇してはならない。その代わり、彼らを雇用し、必要であれば再教育する。
経営陣はコスト削減に執着し、時には管理職に特定の割合でコスト削減を奨励するボーナスが動機となることもある。ソフトウェア開発スキルはコモディティであるという信念に後押しされ、低コストのベンダーが何年も何十年も経験を積んだチームメンバーと同じスキルを提供できるという契約に誘惑されるかもしれない。
時にこれは真実である。かつての同僚が言っていたように、10年の経験があるのと、1年の経験を10回繰り返すのとでは大きな違いがある。別の言い方をすれば、ソフトウェア開発における本当のスキルは、コーディングでも、構文の知識でも、特定のフレームワーク群に精通していることでもなく、課題解決である。
アーキテクチャの役割は課題解決であり、さらに、特定の種類の課題を解決した経験から基づいたトレードオフが可能というスキルが加わる。アーキテクチャの課題を解決した経験のない開発者は、学べるが、その前に多くの間違いを起こすだろう。経験の有無にかかわらず、必要なのは賢い人材だけだと思い込むよりも、そのような学習サイクルをすでに経験した人材を雇用したり、維持したりする方が、安上がりな場合もある。
なので、アーキテクチャを考えたことある人にアーキテクチャを考えてもらうほうがいい。アーキテクチャで間違いを起こすのはきつい。
機能要件がアーキテクチャの原動力になってはならない。その代わりに、現実的なQARによってアーキテクチャが推進されるようにする。
優れたアーキテクチャ設計は、明確に定義された品質属性要件によって推進される。機能要件のみを使用してソフトウェアアーキテクチャを設計すると、拡張性が低く、負荷がかかった状態でうまく動作せず、長期間にわたって弾力性のないソフトウェア製品を作成することになる。開発チームが機能要件だけに焦点を当てると、そのソリューションのアーキテクチャは、ユーザーの実際のニーズを満たすには不十分なものになる可能性が高い。
社内のソフトウェア・アーキテクチャ・レビューだけに頼らず、できるだけ早く製品をリリースし、実世界からのフィードバックを得ること。
システムが稼動し、完了の定義を満たした後、アーキテクチャを改善する唯一の方法は、システムを開発した人々やその共同作業者のコミュニティが持つバイアスから解放され、実世界の精査を受けることである。