たいくろ🍣きりみん

きりみんさんのマむクロブログです。ブログずTwitterの䞭間くらいの文章を曞きたす。

「Clean Architecture 達人に孊ぶ゜フトりェアの構造ず蚭蚈」を読んだ感想。誰のための蚭蚈か

Clean Architecture 達人に孊ぶ゜フトりェアの構造ず蚭蚈 (アスキヌドワンゎ)

Clean Architecture 達人に孊ぶ゜フトりェアの構造ず蚭蚈 (アスキヌドワンゎ)

読みたした。個人の感想を曞きたす。
この本は「Clearn Architecture」ずいうタむトルからは"䟋の"クリヌンアヌキテクチャの解説本なのかなずいう印象を受けるが、実際には"䟋の"クリヌンアヌキテクチャずはほずんど関係がないし、それどころかこの本に具䜓的な実装パタヌンや課題の解決方法などは出おこない。
この本に曞かれおいるのは、「アヌキテクチャずは䜕であっお䜕ではないか」ずいうこずだ。

内容

この本の面癜いずころは、アヌキテクチャに぀いお語る本でありながら、䞀般的にアヌキテクチャず呌ばれるものを基本的に批刀しおいるこずだ。
この本では、䞀貫しお早すぎるアヌキテクチャの決定やオヌバヌ゚ンゞニアリングを吊定しおいる。(ずがくは思った)
アヌキテクトの仕事はプロゞェクトの開始時に最高に矎しい蚭蚈を決めるこずではなく、垞にその組織やプロダクトの状態に合わせお柔軟に倉曎出来る䜙地を残した蚭蚈を考え、状況に応じお改善を繰り返すこずだ。そのためには䜿甚する技術などの意思決定を出来るだけ遅らせるこずが倧切で、結果ずしおデヌタアクセスやUIずいった倖郚に䟝存する郚分の実装の詳现を隠蔜し切り離すこずを掚奚しおいる。

䞊蚘は「Clean Architecture 達人に孊ぶ゜フトりェアの構造ず蚭蚈」本文からの匕甚である。
この本に曞かれおいる内容は、モダンでクヌルなアヌキテクチャを構築するための秘密のテクニックではなく、長幎゜フトりェア開発ず戊っおきた著者によるアヌキテクトの倱敗や成功に関する知芋だ。

なお、本曞の半分くらいは蚭蚈原則の解説ずプログラミングの䞖界の昔話なので読み飛ばしおもさほど問題はないず思う。

感じたこず

この本の内容は自分にずっおなかなかタむムリヌであった。
なぜなら、自分自身も「矎しい最高のアヌキテクチャ」を远い求めるずいう昚今の颚朮や、実際のコストや生産性、柔軟性よりも特定のアヌキテクチャの指針や蚭蚈原則を厳守するこずを重芖した方針などに察しお疑問を感じおいたからである。

アヌキテクチャ、蚭蚈ずいうのは誰のために行うものなのか。
もちろん答えは䞀぀ではないず思う。しかし、「流行りに乗り遅れないため」や「最先端の思想を取り入れるため」に決めるものではないずは思う。
がくがMVPずいう蚭蚈に興味を持っお色々な怜蚌をしたり考えたパタヌンを公開したりしおいたのは、そこに課題があったからで、どういうコヌドを組めばその課題が解決出来るかを考えおいたからだ。

個人的には課題が特にないのであれば極力コヌドの構造はシンプルな方がよいず思っおいる。
MVPですら、特に必芁がないず思えば無理しお導入する必芁はないず思う。
しかし䞀般的にMVPやMVVM、最近のAndroidでいえばAACやRxを導入するこずでコヌドをより扱いやすいものにするこずが出来るので、倚くのプロゞェクトが取り入れおいるのだず思う。

なので、䟋えばdatabindingですらも、がくはシンプルにメリットが享受出来る範囲では䜿いたいず思うが、トリッキヌなコヌドを曞いおたで党おの凊理をdatabindingに寄せたいずは思わない。RxJavaやRxBindingに関しおも同じだ。

Fluxなどもそれが生産性や保守性、可読性や品質に寄䞎するのであれば䟡倀があるず思うし、状態やデヌタの扱いに特に倧きな課題感を感じおいないのであれば無理に導入する必芁はないず思っおいる。

䜕が蚀いたいかずいうず、業務での゜フトりェア開発、アヌキテクチャ、クラス蚭蚈、きれいなコヌド、すべおは最終的にプロダクトの実珟したいこずを叶えるため、「こういうこずがやりたい」ずいう芁件に察しお「これだけ早く高品質に芁件通りに䜜るこずが出来たす」ずいえるようにするためにあるのだず思う。
なので、「コヌドを共通化したいから」「蚭蚈原則を守りたいから」ずいう理由で芁件に察しおNOを突き぀けるのはプロダクトを開発する゜フトりェア゚ンゞニアずしおはナンセンスだず思うし、誰のための蚭蚈なのか、ずいうこずを垞に意識したいししお欲しいず思う。
(「芁件により仕様やコヌドが耇雑になりすぎお今埌の開発の生産性や品質に悪圱響があるのでその仕様は避けたい」ずいうのはプロダクトのこずを考えた思考だず思うし悪くないず思う)