フロントエンドで長持ちするプロダクトを開発するための心構え
こんにちは、クレスウェア株式会社の奥野賢太郎 ( @okunokentaro ) です。今年もよろしくお願いします。
今回は、Reactでのクリーンアーキテクチャの採用の是非についてTwitterにつぶやいたところ、思いの外Likeが集まったため、まとめて閲覧できるようにツイートをまとめつつ、簡単に補足しようかと思います。
リアクションのもととなった記事
@adwdさんのこの記事に感銘を受けて、Twitterでちらほら感想をつぶやいたところLikeやRTが予想外に集まりました。それが下記のツイートです。
筆者がツイートしたもの
補足
筆者は、元記事で言及されている『「悪い方が良い」原則と僕の体験談』や『質とスピード（2020秋100分拡大版）』は確認済みであり、『 Clean Architecture 達人に学ぶソフトウェアの構造と設計』も読了しております。
大掛かりな仕組みをいれたがる、リファクタリングで細部をこだわりたがるというのは筆者自身若い頃に通ってきた道であり、記事中で言及されていたDIの手法であったりDDDといった概念に傾倒したこともありましたので耳の痛い話ではありますが、まさにその通りと感じます。
8年近くこの業界にいますが「そういった施策が大成功した」と実感した機会よりもむしろ「あのときなんであんなに無駄に頑張ったんだろ」と反省したことの方が非常に多いと記憶しており、この歳になると若い開発者がそういった仕組みをがんばって構築する様子を微笑ましくも感じながら、適宜見切りをつける判断をせざるを得ないことも多々あります。
現在筆者はシステム全体の設計や、サービス全体の設計を任されつつ、現場の些末な実装のレビューも担当するという立場です。そのためコードレビュー時は可読性や処理の効率ももちろんそうですが、そういった「大げさなこと」をしていないか気を配る、そしてそういったことを減らしながら無駄のない筋肉質な実装を積み重ねていく、そういった舵取りを心がけるようにしています。
Reactにあまり関係のない能書きを重ねましたが、Reactに特化していうと、何かを導入する際には導入を目的にするのではなく、それを導入することで解決する問題に常に着目すべきです。例えば筆者が最近感銘を受けた記事に『「3種類」で管理するReactのState戦略』というものがありますが、アプリケーション内・サービス内のあらゆる値、あらゆる通信についてひとつひとつ「どうあるのが好ましいか」を吟味し、それぞれの特性ごとに無駄のない簡潔な手法によって解決させています。筆者も、この記事とほぼ変わらない構成で現在の案件を進めており、筆者自身（2022年初頭において）この構成が無駄のない筋肉質な選定であると感じています。
回りまわって、今やるべきインプットは「使っているライブラリのドキュメントをちゃんと読む」や「書いている言語の仕様をちゃんと把握する」に尽きず、今やるべきアウトプットは「自分が何をすることになったのか自分で理解して作る」や「常に自分がいなくなっても他人に説明できるものを書く」に尽きません。
Discussion