システムは推論しやすくしておくのが大事
なんか以下のリンク見つけたので読んでみたら「やっぱりそうだよなー」と思ったのでつらつらと思うがままに書く。
Tomato Architectureの概要
Tomato Architectureは、ソフトウェアアーキテクチャへの一般的な感覚に基づいたアプローチ。このアーキテクチャは、人気のある人々の提案を盲目的に追うのではなく、あなたのソフトウェアにとって最善のことを考えることを推奨しているよってことなのかな・・？
なんでTomatoなんだろうと思っていたら最後に書いてあったw
What's with the name "Tomato"?
If you are okay with "Hexagonal" knowing 6 edges has no significance, you should be okay with "Tomato". After all, we have Onion Architecture, why not Tomato:-)
Common Sense Manifesto
Tomato Architectureは、Common Sense Manifestoを基にしてて推奨している考え方は以下。（個人的な超意訳）
次の10年間の要件を予測して作るこむのではなく、物事をシンプルな状態にしておこう。
実際に触ったり考えたりしてライブラリを選択したら変なことをせずに素直にそれを使うようにしよう
ちゃんとプロダクトとして、サービスとして形にしよう
Implementation Guidelines
次に「Implementation Guidelines」と書かれており、実際のコードのイメージも張ってくれている。
いわゆる「単一責任の原理」とかその辺の話をしている印象。
まとめ
なんか色々書いてあるが、個人的に響くのが「物事をシンプルな状態にしておこう」という意訳してしまったがこの部分。
Strive to keep things simple instead of over-engineering the solution by guessing the requirements for the next decade.
実装していると「あーこれこういうこともあり得るような気がする」的な感じでとりあえず作っておくみたいなことがちょくちょく発生してしまうので気をつけたいところでありまする。。
まとめた がまだ終わらない・・・
Tomato Architectureを読んでいて頭によぎったのが以下の2つのリンク。
まずはこれ。
https://github.com/matthewrenze/clean-architecture-demo/tree/master
クリーンアーキテクチャをコードで表現してくれていてイメージしやすかった。実装するときはこのイメージを持っている。
そしてもう一つがこれ。
いつ、どこで見つけたのかは忘れてしまったがリファクタするときやコードレビューするとき、アーキテクチャ考えるときとかに頭の隅に置いているくらい個人的には影響受けたやつ。
Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.
ちょっと説明すると・・・
コードやシステム設計・最適化するときは
状態 > 結合 > 複雑性 > コード量
の順に削減するようにする。つまり
コードがよりステートレスになるなら、結合を増やすこともいとわない
(状態↓ 結合↑)
結合を減らすためには、コードをもっと複雑にすることもある
(結合↓ コード量↑)
コードの複雑さが軽減されるなら、コードをコピーすることもいとわない
(複雑性↓ コード量↑)
コードの重複排除をするのは状態・結合・複雑性を増さない時のみに限る
なぜかこの順番に最適化するのが良いのかというとそれは、最も推論しやすいなるから。
どういうことかというと
ステートレスなロジックは、通常実行・並列実行・分散実行、どんな処理をしようと同じように機能する。
セットアップコードがほとんど必要ないため、テストが最も簡単。
別のコピーを実行するだけなので、スケールアップも最も簡単。
との記述があり、なんとなく言いたいことイメージできると思います。
汎用的に使える場面が多いのでなんとなーく頭に入れておくと結構便利な考えだと個人的には思ってるので読んだことないよーという人は目を通してみると面白いかもです！
この記事が気に入ったらサポートをしてみませんか？