出囃子
進化的アーキテクチャというオライリーの本を読んでいます。
まだ最後まで読んでないですが、あと30Pぐらいまで来たので、アウトプットしようかと。
とりあえず、すごく良い本だと思います。
初心者には難しいかもですが、DDDやったりとかシステム開発で基盤部分を作ったことがある人なら、すんなり読めそうです。
トレードオフについて
トレードオフ（英: Trade-off）とは、一方を追求すれば他方を犠牲にせざるを得ないという状態・関係のことである。トレードオフのある状況では具体的な選択肢の長所と短所をすべて考慮したうえで決定を行うことが求められる。
開発者は利益についてはすべて理解しているくせに、トレードオフについてはまったくわかっちゃいない！
引用元：Rich Hickey（Clojureの作者）（本の中で引用されてました）
フレームワーク使うとかまったくわかっちゃいない！！
- フレームワーク：呼び出されるもの（だからこそ合わせなくてはならず振り回される）
- ライブラリ：呼び出すもの
僕はフレームワークが嫌いです。
現実世界の要求に答えるシステムを作りたい場合、フレームワークは最終的に邪魔者になります。
進化的アーキテクチャの本では、フレームワークのせいでビジネス要求の10%が満たせないことを ラスト10%の罠 と名付けていました。
フレームワーク自体が、ライブラリの集合体なのだから、自分が関わるシステムに必要な最小限のライブラリだけ使えばいいと思います。
今の現場で、JavaでSpringフレームワークを使っているのですが、DIが遅いせいで1ファイルのテスト実行に2分くらい掛かります（そのほとんどがDIの実行時間です）
フルビルドから起動して確認できるようになるまでは、10分くらい掛かります。
DI無ければ1分も掛からず起動できるはず。
バッチを書こうにも、SpringのDI動かしてからだとすぐに実行できないから、起動しているバッチサーバにAPIを投げるとか微妙なことをやらざるを得ない。
余談ですが、GoogleのSRE本では、人間は2秒以上時間が掛ると他のことを考え出すので、それ以内に実行時間を収めるのが理想と書いてありました。
起動時間には目を瞑っても、テストの実行くらいは2秒以内に収めたいですね。
なぜ、フレームワークを採用するのでしょうか？聞いてみた
聞いてみたらオレオレフレームワークは悪じゃないか？とか、JavaではSpringフレームワークがデファクトでしょ？とか、そもそも今から変更できないとか、そんな話だった。
新規プロジェクトでも、開発期間短縮のため、既存プロジェクトをコピペで作るからSpringが自動導入されてます。
将来的に開発者がビルド時間で費やす膨大な時間の損失については、開発期間に含まれないらしい。
開発に時間がかかるシステム作ると開発期間が長くなるから、できるだけ開発期間が短くなるように設計されたシステムを作ったほうが良いと思います。
現実の変化よりも、システムの変化が遅い場合、何を開発しても出来たときには不要のものとなってしまいます。
Rubyでも、Rails Wayから外れた使い方が必要になった場合、すごく大変になるという話もチラホラ聞きます。
結局、フレームワークは開発元のビジネス要求に最適化されていて、どこかの会社で使おうとしてもマッチしないというだけの気もします。
考えることの重要さ、シンプルさの必要性
IBMのスローガンが「THINK」の理由
「我々は読んだり、聞いたり、討論したり、観察したり、考えたりすることで学習を続けなければならない。我々は考えることをやめてはいけない。それをやめることで、トラブルに陥るからだ。マレイ博士(ニコラス・マレイ・バトラー博士)は最近『世界中の問題のほとんどは、人々が考えることをやめなければ容易に解決できる』と述べている」
引用：業界に多大な影響を与えた現存メーカー Thinkというスローガンを掲げたIBM
GoogleのSREの本を読んでも、Rich Hickeyさんの記事でも、シンプルさが重要と書いてあります。
今のビジネスに必要な最低限のライブラリで、システムを作るべきだと思います。
そうすれば、複雑な依存関係の解消作業とか、特定のライブラリのせいで言語のバージョンが上げられないとかそういうのが少なくなります。
今、自分のシステムに何が必要か？
どうやったらシンプルにできるのか？
それを考えて作って欲しいです。
モダンかどうか？とかみんな言っているから。。とか、そんな考えることを放棄した発言はしないでほしいです。
僕の考え
色々とWebシステム見てきたのですが、下記があるとすごく速く作れそうだなぁと。
■コード
- テスト駆動開発
- 静的解析ツールを初期段階から導入
- ソースコードのテンプレート自動生成ツール
- ドメインごとにロジックをまとめる
- 外部境界（Controllerなど）以外は、コードを1フォルダにまとめる
- レイヤ化アーキテクチャ
- ビルドするなら分割ビルドなり、ビルドが2秒以内に終わる機構の作成
- データと実装の連携による処理の実現（これについては、うまくいったら記事でもあげようかと）
- JSON-RPCを使う（API設計からの開放）
- これにより、ルーティングライブラリを使わなくて済む
- Javaならほぼ素のままのJettyを使ったアプリケーションサーバを作る
- 起動の速さを重視
■DBとかミドルウェア
- Excelやスプレッドシートを意識したマスタデータの作成
- イミュータブルインフラストラクチャ（Dockerみたいなもの）
■組織
- Just In Time出来る組織か？
- そもそも作らないで代替品を用意できないか？とか考えられる組織か？
上げた例が多すぎて、シンプルじゃない気もしますね(；・∀・)
まとめ
それぞれの現場で、状況や、メンバーや、組織体系など違うと思います。
その現場にできるだけうまくマッチするように、できる限り良いトレードオフしたシステムが作れたらいいなぁと思います。
銀の弾丸は無いといいますが、シンプルさというのは実は銀の弾丸なのでは？とか、最近思ったので記事化してみました。