アーキテクチャとは？

■所感
だいぶ核心に近づいてきた感じ、と思ったけどそうでもなかった。
現在の現場では、自分の所属しているチームとは別に、アーキチームと呼ばれている人たちがいる。この人たちは、若干インフラ寄りではあるものの、俯瞰的な立場からシステム全体を調整しているようだ。なんでアーキチームなんだろう？って思っていたんだけど、どうも自分は陥りやすい言葉の罠にはまっていたらしい。
プログラマから見ると、アーキテクチャってどうやってプロジェクトを作るかという、プログラムの方針的な意味合いでとらえていたんだけど、そうではなくソフトウェアのライフサイクルのサポートを指す言葉のようだ。

この間違いを訂正できたのは大きかった。。少なからずほっとしていたりする。

■内容について

開発
開発者が5人くらいの小規模システムではアーキテクチャなんて不要。むしろ障害物になる。
アーキテクチャが必要になるのは、大規模になればなるほど効果が大きい。
確かに、と納得できる。小規模システムに在籍していたときは、アーキテクチャなんて言葉がそもそも聞かれることがなかったと思う。動けばいいやっていう考え方のエンジニアばかりで、なんだかカウボーイ的な開発というか、個人の運用に関する知識量だけで勝負しているような、へったくそなコーディングの山を築いていた。しかも、「経験年数が長いから」という一言で、自らのコードを正当化するような、そんな傾向があったと思う。

デプロイ
単一アクションで簡単にデプロイできるのが理想。これはちょっとわからなかった。すっかり.netに染まってしまったのか、デプロイといえば、基本プロジェクトが依存するすべてのdllをリリース、が基本だったからだ。アセンブリが異なれば、依存しているdllもリビルド。これが当たり前だった。
デプロイに関しては、やっぱりインタプリタ言語が圧倒的に強いなって感じた。性能的にも、phpだから遅い！なんて時代遅れもいいところだし、ブラウザゲームの大半がインタプリタやjavascriptで動いていることを考えると、まだまだ伸びるんだろうなと感じた。

運用
ぶっちゃけ、ハード側で何とでもなるよね、っていう話。まぁ、今どきのシステムらしいと笑えた。データセンターに自社サーバーを置いて、とか、自社のサーバー室で、なんて時代はもう来ないと思う。AWSやAzureのどちらで？っていうのが、どの企業の要件定義でもスタンダードな考え方なんじゃないだろうか。クラウドは確かに便利。不要な端末さえ動かさなければ、の話だけど。ずさんな運用をしているところだと、単なる金食い虫。

保守
ソフトウェアライフサイクル的に、一番金食い虫だよねっていう話。ここのランニングコストをいかに抑えるか？コンポーネントを独立させようねってこと。あまり書くことがなかったんだろうなって思える薄っぺらい内容だった。。

選択肢を残しておく
ここは重要。クリーンアーキテクチャの根幹にある考え方がそのまま記載されている感があった。
・開発初期段階でDBの考慮は不要
・ 開発初期段階で UIの考慮は不要
・ 開発初期段階で RESTの考慮は不要
・ 開発初期段階で DIフレームワークの導入は不要
なぜ不要なのか。それは、ビジネスロジックをクリーンに保つためだからだ。

デバイス非依存
読み飛ばしてもいい内容。というか、いらない。

ダイレクトメール
これもいらない。

物理アドレス
これも全くいらない昔話。何だったんだろう？？
選択肢を残しておく、の話で終わりで良かったんじゃないだろうか。

ページ数のわりに、中身が薄い章だった。