書籍「進化的アーキテクチャ」を読みました

2018-11-20

オライリー本がひとつ、「進化的アーキテクチャ」を読みました。実際に読み進めていたのは 2018 年 10 月の下旬で、ようやっと落ち着いて読書記録を書ける状況になったので書きます。

書籍の公式サイトに加えて、翻訳を担当された Koji Shimada / 島田浩二 (@snoozer05) さんによる紹介記事にもリンクしておきます。熱の感じられる紹介文で、紹介したくなるからです。

多かれ少なかれ、やっていること

ぼくが現職の同僚や、これまでにお仕事でごいっしょさせてもらったソフトウェア・エンジニアを思い浮かべると、本書に書かれているような考えは、誰しもが多かれ少なかれ実践していることだな〜と思いました。「最初にしっかり設計したから、あとはもう安泰！余生を楽しみましょう」なんてスタンスで継続的なソフトウェア開発に携わっている人を探す方がむつかしい。

ふだんぼくらが考え、実践しているようなこと。そのロジックを整理して突き詰めるとこういう話になるのだろうな、という印象を持ちました。

自分にはけっこう難しく感じられた

それでいうと、ぼくは「チョットヤッテイル」という現状なのだと思います。たとえば本書の内容に倣って、なにかしらのプロジェクトで「とりあえず、騙されたと思って 1 から 10 までこの本の通りにやってみよう」と決意したとしても、実際になにをどこまでやったらよいかは自明ではありません。

継続的インテグレーション、あるいはダッシュボードのような

適応度関数の話を読んでいて、ぼくはずっと「継続的インテグレーション」っぽい話かな、と感じていました。もし、自分たちのシステムが満たすべき「◯◯性」と呼ばれるような性質をすべて列挙できて、かつ、ひとつひとつを定量化できたとして。そうすると、ソフトウェアに変更を加えようとするたびに、もしくは毎日の決まった時刻に、CI を走らせて Green か Red かを判定できるはずですよね。これはたしかにおもしろいと思います。

あるいは、チームの視界に入りやすいように目立つところにディスプレイを置いて「今月の売上」「目標まであと◯◯円」と示すような感じで、ビジネス上の KPI と同列に「デプロイ回数 / 日」だとか「セキュリティ的観点から見た望ましさ」「耐障害性」「パフォーマンス」などが表示されていたら。なんとなくの雰囲気で語られがちな「最近、技術的負債が牙をむいてきたね」「開発スピードが落ちている気がする」「開発効率が〜」「コードの質が〜」といった類のことも、もうちょっと科学的に扱えるようになるのかもしれません。