「奥野さんと社員のリファクタリング部屋」は、リファクタリングに励むトレタの社員と技術顧問の奥野さん ( @okunokentaro ) の間で実際に行われた会話を切り取った開発現場実録コンテンツです。
技術顧問: 奥野さん 三度の飯よりリファクタリングが好き
今回の質問者: 武市さん トレタ在籍2年。沖縄在住のフロントエンジニア
PR
こちらに登場している2人が登壇するイベント・TORETA TECH UDATEが2024/08/28に開催予定！ リファクタリングやリアーキテクトなど、サービスを提供させながらプロダクトの新陳代謝をいかにして行なってきたかを開発現場の実例と合わせて紹介します！ toreta.connpass.com
今回の質問💬
前回に引き続き、Webアプリケーション (Next.js) のプロダクトのリファクタリングを進めている武市さんから、ディレクトリ名についての質問です。
「repositories」というディレクトリ名が、特定の意味やイメージが強く付いているため避けるべき、という前回の指摘をうけて別のディレクトリ名を考えてきました。 「repositories」という言葉の代わりに「データアクセスを抽象化し、データベースや外部システムとのやり取りを行う処理」として以下の3つのディレクトリ名を考えましたが、いかがでしょうか？
- connectors
- effects
- interfaces
誤解を生む名前は避ける
奥野 正直なところ、ディレクトリ名をそこまでこだわらなくていいと思っていて、それは前回の「repositories」って名前を避けたらっていうところからも続いている話題ですが、ディレクトリ名は他の人がそれを見てわかればいい、伝わればいいと思っています。 危険な橋を渡って「repositories」って名前をつけることも別に誰も止めないし、みんなが納得してみんなが分かる名前だったら別に何でもいい。
それを踏まえて、一つちょっと注目しておくと、「interfaces」はちょっと危ないかもしれない。 なぜかというと、TypeScriptで開発している前提があるので、TypeScriptのinterface宣言を想起する部分が大きい。どうしても「types」とか「interfaces」みたいな言葉を使うと、Typescriptのinterface宣言をまとめたファイルを配置するディレクトリの印象になってしまう。
例えばReactの場合だったら「components」や「hooks」とか、Reduxだったら「redeuers」とか、ディレクトリ名の中に特定のもの・同種のものを詰めていくというのは、ディレクトリの戦略としてよく見かけるので、「interfaces」という名前をパッと見たらTypeScriptのinterfaceばっかりが入ってるように見えてしまって、データアクセスを行うものが入っているようにはちょっと見えないですね。
なので、どんな名前つけてもいいよっとは言ったものの、誤解を与える名前を避けたほうがよくて、自分なら選ばないですね。 前回の「repositories」と理由は似てますけど、やはりみんなが連想するものが偏りがちな言葉は、それを違う用途として使うのはあまり向いてないと思うし、今回の「interfaces」も多くの人が想起する内容とは違うから誤解されてしまうと思います。
武市 そうですね。おっしゃる通りです。
語彙の引き出しを広げる
奥野 「effect」と「connectors」は、自分がとやかくつっこむほどではないですけど、自分は「connectors」という言葉をここで使う例は、実はあんま見たことないのですが、どこかからの引用ですか?
武市 いえ、このディレクトリに置くファイルは「何をやっているのか」が一つの単語で分かる言葉というのを色々と考えて、「database」や「repositories」みたいな言葉ではなく、ちゃんと意味の伝わる単語を色々探してみました。
奥野 英単語として適切な言葉、ということですね？
武市 そうです。何かとコネクトするものの集合体として、「connectors」を選択しました。それも皆を納得させやすい言葉のほうがいいなと思って、「ここは別のものとコネクトしているものなんです」という自分の中で先に納得させる理由を探してからみたいなところがあったかもしれないです。
奥野 あまり深く考えすぎると使える語彙が減っていくというのがあるから、リポジトリっていう言葉は避けようみたいにして、あれも避けよう、これも避けようってすると、どんどん自分の納得できる言葉が減っていくから、「connectors」でしっくり来るならいいんじゃないとは思います。
一方でJavaでは「Connectuor Architecture」って名前のアクテクチャーがあって、オラクルとかでもそういう「Connectuor Architecture」ってのが紹介されてはいます。それが前例としてあるなら「connectors」って言葉も避けようみたいにしていくと、どんどんと使える言葉が減っていってしまい、最終的に「functions」とか「domeins」とか「processes」とか、あまりにも抽象にもほどがあるだろうっていうぐらいの言葉になり果ててしまいます。
どこかで線は引いてもいいと思うし、「repositories」で線を引くのか、「connectors」で線を引くのかは自由だけど、最終的には誤解を生まなかったらいいと思う。だから、どんな言葉を使っても極端な話をすれば、「effect」って言葉だったり、「functions」だったり、「processes」と呼んでも、誤解を抱く人間は抱くから、うちではこれのことをこう読んでるんですよっていう説明すればいい。
こういう時に本を読んでるっていうのが大きく役立ちます。本だけではなく他社の勉強会のスライドで、うちではこういうふうにやってますとか、アトミックデザインを採用してますとか、クリーンアーキテクチャーをやってますとか、ドメイン駆動を設計に取り組んでますとか、いろんな会社のいろんなエンジニアが、いろんなLT、カンファレンスで発表をしてますよね。だから、トレタで奥野さんがどうしてるとかだけじゃなくて、あの会社ではあのようにしてるって発表してたなとか、あっちの会社はトレタとやっているビジネスや作ってるアプリケーションも似てるけどこうしているんだな、ということは探すことができます。
例えば、ここの会社ではJavaを使っているからそういう言葉を使うんだなみたいな知識や経験を積めば積むほど、どういう文化圏から来た言葉だなというのもなんとなくわかってきます。なんかJavaっぽい、Goっぽい、TypeScriptっぽいなとかあるわけですよ。
知識量っていうのはこういうところの取りまとめにすごく役立つので、語彙はたくさん持ったほうがいいし、語彙を集める方法は本だけじゃなくて、SpeakerDeckとかにアップされてるLTでもいいから、とにかく他人のLT、他人の技術ブログ、他人の他社の開発者ブログを読みまくる、というのがおすすめです。
トレタでもこのリファクタリング部屋というコンテンツでブログ公開してるわけですから、読者はトレタさんではこうやってんだって伝わります。全世界にブログとして公開することで、また新たなコミュニケーションとか新たな方法の行き来が生まれていくわけです。だからここで「connectors」を使うっていうことは全くおかしいなことではないと思います。
武市 はい、ありがとうございます！自分なりには、まず名前は何にせよ、シンプルでルールを伝えやすくできたなと思ってます。これをどう保守していくかはまた宿題として考えていこうと思います。
一旦これで進めてみて、またトライアンドエラーで、ダメだった時はまた修正しながらプロジェクトを進めていきたいと思います。
奥野 はい。いいと思います。この言葉ちょっと分かりにくいなとか、いう場面が出るようであれば見直したらいいし、特に誰も気にしてないようであればそのまま使い続けていけばいいので。
武市 はい！ありがとうございます！
