O'Reilly Japan - マイクロサービスアーキテクチャ
おすすめ度: ★★★★☆
良かった。やんごとなき理由により非自主的に読み始めた本だったが想像していた数倍の価値がある本だった。 マイクロサービスの基本などが抑えられているのもよかったが、何よりマイクロサービスベースの組織やそれを支える体制など組織論的なところまで踏み込んでいるのが良かった。 それがことごとくそのときの会社の体制と正反対だったことは皮肉だったが。 かなり思想的に影響を受けたし、考えを補強してくれた点も多かった。
O'Reilly Japan - マイクロサービスアーキテクチャ
おすすめ度: ★★★★☆
良かった。やんごとなき理由により非自主的に読み始めた本だったが想像していた数倍の価値がある本だった。 マイクロサービスの基本などが抑えられているのもよかったが、何よりマイクロサービスベースの組織やそれを支える体制など組織論的なところまで踏み込んでいるのが良かった。 それがことごとくそのときの会社の体制と正反対だったことは皮肉だったが。 かなり思想的に影響を受けたし、考えを補強してくれた点も多かった。
私が開発当初から関わったシステムでコード的に最大規模のものはScalaで書いた検索システムの2万行ほどのもので、あとは保守開発や1万行以下のサービスばかりです。 なのでその程度のへなちょこエンジニアの主張なんざ聞くに値しないという主張は一理あるかもしれません。 ですのでもっと大規模なシステムでは以下の理屈は通用しないというようなことはあるかもしれません。
Scala界隈はcake pattern, reader monad、今はtagless finalと遷移しているけれど、まだ理想形には到達していないし、流行り毎に失敗を重ねているので、一度誰かがみっちり反省した方が良いと思う。
— Taro L. Saito (@taroleo) 2018年6月7日
これを見てそういえばScalaを始めたときcake patternなど勉強したことを思い出した。 今はTagless Finalというものがあるのか、なるほどと思いつつこの手のものをそういえば使わなくなったのはなぜか思い返したところ、これがDI技術であることが理由だった。 そういえばある時からDIは根本的に良くない気がして使わなくなったのだった。
猿でも分かる! Dependency Injection: 依存性の注入 - Qiita など今はウェブ上に非常に理解しやすい説明があるので好きなやつを見たらいいと思う。
僕流に解釈して説明すると以下のようになる。
関数、プログラム、アプリケーション、サービスのどの単位でも必ずセットになるものがある、入力と出力だ。 そしてテスト*1とは特定の入力に対して期待した出力であるかを試すものである。例外はない。
基本的にテストするときは対象の外側から入力を与えてやる。関数であれば引数、クラスであればコンストラクタ引数、APIであればクエリパラメータやヘッダである。 しかしDI技術はこの原則を無視する裏技を提供する。直接テスト対象のプライベート変数(内部変数)へ値を注入(Inject)できるようにするのである。
直接テスト対象のプライベート変数(内部変数)へ値を注入(Inject)するDIは次の欠点を生み出す。
ただ、以上のような欠点をDIを使っている人に何度かぶつけてみるとそれらは一理あるものの以下の要因により必要悪としてDIは使われているという反応が多かった。
これらの反論もまた一理あるものであるが、どこか納得出来ないものを抱えてなかなかDIを積極的に使うことができなかった。
DIについて調べたり軽く使ってみつつ数年経ったのちに読んだ2つのアイデアが解決の糸口になった。
一つは "TDD is dead. Long live testing." 一番最初に読んだ日本語の記事は忘れてしまったけど、この要約など良い。どうやらテスト駆動型開発は死んだようです。これからのCI 重要なのはTDD is deadといいつつ実際にはユニットテスト的な粒度の小さいテスト駆動での開発の否定で、機能テスト・統合テストなどと呼ばれる粒度の高いテストをちゃんとしましょうということが要点(だと僕は捉えた)。
もう一つはMicroservice。 これの良いところ悪いところいろいろあるが僕が目をつけたのはインターフェイスがWeb APIとして定義されること、中身が十分に(Microservice architectureという本によれば、たしか1,2週間で書き直せる、だったかな)シンプルであることだった。
この2つのアイデアを組み合わせて僕は以下のように今は考えている。