まえがき
これはアドベントカレンダー11日目の記事です。
まえがきなんていらないのでは？と思うかもしれないが、個人的にこれは本文を書く前の助走みたいな感じでこれがないと本編が書けない体になっているのである。
そしてお気づきの方がいるかもしれないがタイトルの表現のネタ切れが起きてしまいました。
この検索キーワードでこの記事がヒットすることはないだろうからこれを読んだ人はアドカレから辿ってくれた方なのだろう。読んでくれたありがとう(先にお礼をいうスタイル)
今回紹介する本
『ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ』
この本はかのオライリーから出版されている本で、2022年に出版された模様
紹介したい部分はたくさんあるし、正直まだ100%理解し切ったというには到底及ばないのですが読んで良かったのは間違いないので紹介させて欲しい。
アーキテクチャを選定するということ
エンジニアをしていると案件1つからシステム全体のことまで「どういうアーキテクチャが良いのだろう」と悩むことはみなさんあるでしょう。
そう言った時に、リーダークラスになると「どれもいいよね〜」なんて生ぬるいことは言ってられずどれかを選ばなくてはならない。
そう言った時にどのようにして選べば良いのかというのをかなりこと細かいに記載してある。
トレードオフを意識する
この本で節々に書かれているが、絶対的にこれが正解というアーキテクチャは存在しない。
それは、システムや組織が時間と共に変わっていきその瞬間最適であったとしても未来でもそれが絶対正解であったかと言われるとそれはわからないからである。
例えば、ガチガチに保守性の高いロードバランシングや、レプリケーション、マルチリージョン構成など今上げたものはやった方がいいかと言われたらやったほうがいいことではある。
ただ、それを新規事業の立ち上げでまだ売り上げも立っていない状態においてやったほうがいいかというと、それはオーバースペックである。
が、一方であらかじめそれをやっておけばシステムが大きくなった際にそれをする工数を取る大変さがなくなるという考え方もできる。
と言った感じで、どちらの選択をしてもいい面があったりするのでそれらを天秤にかけてどれを優先してどれを落とすのかというトレードオフを意識するということがこの本の中で私が個人的に一番感じた部分である。
アーキテクチャの小難しい話だけではない
この本のタイトルを見ると「世の中にあるアーキテクチャの色々な紹介してる本？」と思われるかもしれないが、半分正解で半分誤っている。
もちろんアーキテクチャ選定のためにさまざまな設計パターンを知っておいたほうがいいので色々なパターンを紹介もしているがそれだけではなく、日々そう言った新しいインプットをするにはどうしたらいいのかと言った周辺知識もこの本には詰まっているのでとても良いと感じた。
まとめ
エンジニアになりたての人もぜひ読んでほしいと思うが何より、ある程度意思決定をする立場になった人は一読する価値のある本だと思っているのでもし読んだことがない方がいたらぜひ読んでほしい。
余談
なぜオライリーの本はkindleで読めるようにならないのだろう...
ためになる本が多いのにあの分厚さは気軽に持ち歩けなくて...これを執筆しながら読み直したいとも思っているが...辞書すぎる(？)