utilパッケージ不要論(及び、書籍刊行に向けた進捗共有)


From:

Stephen S. HANADA

Shinjuku, Tokyo

Sunday, 01:11 p.m.

親愛なる友人へ、

いかがお過ごしですか?

utilなどというパッケージは不要だ」

先日、私は職場でそのように叫びました。事実、私はそう信じています。特にWebアプリケーションのDDDやClean Architecture、OOPにおいて本当に必要な状況はかなり限定的で、本質的には不要、さらに言えば、存在するべきではない、とすら言えます。同じことはcommonlibrarycoreなどといったものにも該当します。私はこれらのものが出てきた時に、次のように冗談を言います。

  • core →「核となるもの? 核爆弾でも作る気か?」
  • common →「常識(common sense)なのか? 少なくともこれは良識(bon sense)的なパッケージ/関数ではない」
  • utility →「公共事業(utilities)をやるのは結構だが、ゴミ最終処分場を街中に作るのはやめろ」
  • library →「図書館運営をするほどの余裕があるのか?」

言葉遊びでしかないです。しかし、このような言葉遊びで問いかけるべき時があります。

もちろん、こういう冗談や言葉遊びをせずに、純粋に技術的に、これらのパッケージに対してその是非を問うことは可能です。例えば、「utilに置かれる関数は、おおよそ汎用的過ぎて、作った時には意図が明確であっても、使うときにはその意図は不明瞭になる」、「そのため、その関数は使われなくなるか、パッケージが肥大化するかのいずれかの傾向にあるから、クラスや構造体、型に対しての独自実装をした方がよい」という感じに話すことができます。

しかし、このような技術的な教訓めいたものは、それに関連した痛みを味わった人にしか通じないです。痛みを味わった人は十分に考えたことがあり、この教訓の意図や意味を理解し、把握し、既にそのように行動しています。つまり、この教訓が通じる人にはこの教訓は不要です。しかし、痛みの味わったことのない人は表層的な意味しか理解せず、その場ではそのように行動しても、別の場所ではこの教訓を無視するでしょう。だから、本当に伝えたい人にはこの教訓は伝わりません

だから、考えさせなければならないのです。回りくどくても、言葉遊びで意味を問い、本当に適切な場所なのか、本当に適切な名前なのかを、考えさせ、自分で問えるようになれるように伝えなければなりません。

これは技術に限った話ではないでしょう。

適切な名前で呼べ、

というのは、日常でも科学でもそうでしょう。「アオ」と言って、緑を指すのが適切な場面もあれば、藍色を指すのが不適切な場面もあります。文脈や状況に合わせて適切さは変わるというのは自明のことです。しかし、その文脈に応じた適切さを逆手に撮って、一つの名前に多くを寄せ、自分が該当すると思ったものをなんでもかんでも人は入れるのです。「愛」に「執着」や「見栄え」を入れたり、「陰謀論」に「正しさ」や「おろかさ」などを入れたりするのです。そして、utilityによく分からない関数が大量に入れられ、コードベースが肥大化し、たとえアーキテクチャとして優れていても身動きが取りづらくなります(そのようなものを許容するのはアーキテクチャとして優れているのかはまた別の話ですが)。

utilityに入れられるような関数は、ほとんどはクラスや型の独自関数として定義可能ですし、そのクラスや型でしか通用しないロジックが含まれているでしょう(もしその関数に独自のロジックが含まれていないなら、なぜそれがOSや言語やフレームワークのレベルに入っていないのでしょうか?)。複数の型やクラスにまたがって実装したいものがあるとしても、それはインターフェイスを使えば事足りるでしょう。そう考えれば、適切な名前を適切な場所で呼ぶ、これを実践するならばutilityに含まれる関数は消え、そのパッケージは不要になるはずです。

ただし、適切な名前をつけること、適切な名前を適切な場所で呼ぶことは、難しいです。痛みを味わうことがなければ身につかないこともあります。そして、言葉遊びで意識の光の下に曝さなければならない場合もあります。何度も間違いを犯すでしょう。しかし、諦めずにより良いものを作らなければなりません。

All of old. Nothing else ever. Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better. -- Samuel Beckett

この詩を思い出してください。


それでは、

青を心に。

Stephen S. Hanada

"Gentleman Philosopher"

P.S. 現在、原稿としては3万字弱を書けました。ここから更に加筆・修正をして、本としての体裁を整えていきます。書籍の体裁にできそうになったら、まずはVLC Callに参加してくださった方に、PDFを送らせていただきます。誤字脱字のチェックをしていただくことや、意味が通じなかったらコメントをしてもらいたい、という思惑もあります。が、何よりもいち早くに価値を届けたいからでもあります。今しばらくお待ちください。(VLCには参加しなかったけれど、私と直接話したことがある人も、希望すればお送りさせていただこうと思います。)

 「知の前駆者」の真正の記録を配信する"Weekly Newsletter from Stephen S. HANADA"を登録してくれてありがとうございます。
 メールアドレスなどの変更が必要になったらPreferencesから変更できます。もうメールを受け取りたくなくなったら、Unsubscribe もできます。
Shimoochiai, Shinjuku, Tokyo 98104-2205

Gentleman Philosopher

I'm a developer, entrepreneur, and writer who loves to talk about business & entrepreneurship, philosophy, and technology. Subscribe to my newsletter.

Read more from Gentleman Philosopher

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 12:40 a.m. 親愛なる友人へ、 いかがお過ごしですか? Kiro、Antigravity、GitHub Copilot、Grok、これらを用いて、ボードゲームの戦略を作り、シミュレーションを実行するために、私は個人開発をしていましたが、そんな中にあって、私は自分の行為に疑問を抱き、嘆きました。 「こんなことのために、 貴重な資源を使っていいのか?」 Issueを作り、CopilotとAntigravityに実装させ、テストさせ、それぞれで出されたPRをGrokにReviewさせ、良い方を採用し、シミュレーションとその結果をAntigravityに実行させる。KiroにSpecから作らせて、後はポチポチとボタンをクリックするだけで済ませることも、別レポジトリでやっています。 しかし、その裏には何があるのでしょうか?...

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 12:11 p.m. 親愛なる友人へ、 いかがお過ごしですか? 「経済学に科学的モデルはない! 予測もなければ説明もない!」 友人たちとの会話の中で、そのような話が出てきたことを私は記憶しています。 確かに、経済学者の語る予測が当たることも少ないですし、起きている事象の説明もあまり有効ではないように見受けられます。もちろん、経済活動というのは人間の信念や行動、そして、組織、行政、気候も関わりますから、予測も説明も困難かもしれません。しかし、科学的なモデルとして期待しているほどのものは提供されていない、と感じてしまうのは、一定の納得感があります。 しかし、それは経済学だけでしょうか? 物理学や生物学でも予測や説明に失敗することはあります。生物学で言えば、そもそもは記録がメインなところが多い学問です。そして、物理学でも、飛行機が飛べる現象や原理の説明も、結局は飛んでいることをそのまま記述し直しただけであり、説明とは言えないものでしょう。...

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 09:51 a.m. 親愛なる友人へ、 いかがお過ごしですか? 「顧客はドリルを求めているわけではない。穴を求めているのだ」というフレーズはビジネスの場面で度々見かけます。しかし、この主張は字義通りに受け取ってはなりません。そして、 顧客の本質的課題など存在しない 、と私は考えます。 ドリルではなく、穴を。穴ではなく、電線を通す穴を。電線ではなく、計算機が動くことを。計算機が動くことではなく、仕事が楽になることを。……と、このように後退し続け、結局は、富・健康・関係のいずれかの課題に帰着します。しかし、それらの課題を解決する方法はドリルを売っているホームセンターでは取り扱われていませんし、ホームセンターで話すのはナンセンスです。さらに、富・健康・関係というのは、人が関わる市場における重要な課題やテーマではありますが、それらは人や市場において普遍的であるわけでもなく、通時的でもなく、そして偶有的です。だから、帰着したところの富・健康・関係もまた、顧客の本質的課題ではありません。(†1)...