この記事はハワイアンAdvent Calendar 2020 4日目の記事です。今日はオンライン飲みってやつがあって、今お酒を飲んでいます。3日目 はちょっとこってりだったかもですし、投稿時間も悪かったし、反省してます。…反省してません。押し付けが厳しい、なんだかこぞって取り繕って丁寧な文章を書いてる量産型な世の中だからこそ、わたしは押し付けられたいし、初期衝動を感じる技術ブログを読みたいなという気持ちで書いています。ドリランド

進化的アーキテクチャの本を読んでいるとだいたいサーバサイドアプリケーションの話ですね。クライアントサイドアプリケーションでいう進化的ってなんなんでしょうか。ソフトウェア開発をするのは人なので、人の話が一番大事なんですけど、ネタとして温存しようかなあ。眠くなってきました。

ここではAndroidアプリケーション開発を例に挙げてみましょう。2017〜2018年頃のAndroid開発を思い出しながら、進化的ってなんなんだろうか考えてみてください。

• GUIライブラリ・フレームワーク・基盤の変化に柔軟に追従できる
  • 2017年・2018年あたりのGUI開発のための選択肢は本当にたくさんありましたね。Data Binding, Kotlin Android Extension, Butterknife, anko, …色々ありましたね。AAC(Android Architeture Components)はまだalphaで、まだソースコードの量も少なくてなるほどねえとよなよなコードを読んだ気がします。
  • RxBindingもありましたね
  • 現在ではJetpack Composeもalphaまで来てますね。来年か再来年には本格的に潮流がやってくるんでしょう
• API通信にまつわる技術の変化に追従できる
  • Retrofit, Swagger, Apollo GraphQL, 色々ありましたね。今でもありますね
  • BFFな考え方も浸透してきましたタイミングでしたね
  • その通信手段としてgRPCなどもやってきましたね
• 他(アプリケーションによりけりな気はしますね。DBへの保存とか、リソース読み込みとか)

進化的アーキテクチャの第一原則の副作用として、技術的意思決定を先送りにする事ができます。これをLast Responsible Momentと呼びます。「決定を下さないコストが決定を下すコストよりも大きくなるまで、重要で不可逆な決定を開いたままにする」という戦略です。当時の自分はというと、WPFやFlash時代からクライアントアプリケーション開発をやってきてそれなりにノウハウがあるので、正直何が台頭してきてもどのように対処すればよいかはなんとなく分かるし、寿命が長そうであればなんでもよかったし、あえてこのライブラリでやっていこうと決める必要がなく、他のチームメンバーが各々の観点で相談しながら自由に決めて良いと思っていたので、自分はその外側の接続部となるオブジェクトを整備し、それぞれ漸進的な変更を加えられるよう整える事に注力しました。

このLast Responsible Momentという考え方は進化的アーキテクチャにおいては複数の次元で機能するので、パフォーマンス・チューニング、最適化も後から行うことが出来ますし、ビジネスの拡大に伴ってチーム単位での設計方針の移譲も可能です。Web APIとの通信方式を変更したければ、その部分だけ変えることもできます。技術の進化に柔軟な設計であれば、既存の実装に手を加える事なく、基盤実装も手軽に差し替えられるわけです。

というわけで、 https://www.klab.com/jp/blog/tech/2015/1047178565.html や https://techlife.cookpad.com/entry/2020/11/17/110000 の裏話でした。もうちょっとクライアントアプリケーション設計の話を続けるつもりです。1日で全部書いてしまうと、カレンダーの後半がやばそうなんですよね。明日はContractの話を書こうかなあという気分になっています。

一応、投稿前にざっと読み直してるんですけど、マジで情報商材っぽい感じの展開で嫌な文章だなあ。ごめんなさいね。皆さんは飲み会の日にブログを書く予定を入れないようにしましょう。