コーディングにおける道のデザイン

ドラレプ

チームのコードの品質を担保する責務を負わされたとき、他者の分も含めて維持し続けるのは難しい。
もちろんコードレビューで細かく指摘するなど、過剰に干渉することである程度担保することは可能だ。
しかし自分１人に依存してるためスケーラブルでなく、得てしてレビュワーが自分でなくなった途端崩壊し、気づいたら全体が崩壊してるようなことは多々ある。

なので極力自分に依存させずにコードの品質を担保する方向性が求められる。

まず考えられるのはlinterだろう。

またLLMによるコードレビューもおそらく今年中にはGithubと連携して行えるようになるだろうし、自然言語で書くlinterも普及するかもしれない。

正攻法としてはこの辺りになると思うが、道のデザインという観点で考えてみる。

道は人の動きを規定する

見ていると、自由度が高いライブラリやフレームワークほど好まれる傾向はあるように感じる。
しかしそれは平野にポツンと立っているようなもので、各々が好きな方向に歩けてしまうということでもある。

もしこの方向に進んで欲しいと思ったらどうすれば良いだろうか？
毎回コードレビューで指摘するのは、左に進んでるものに対して前へ進めと毎回矯正するようなものだ。

では歩いてはいけない方向に壁が立っていて、歩いて欲しい方向に道ができていたらどうだろうか？
特に指摘しなくても、多くの人は自然とその道を歩くようになるのではないだろうか？

同じように歩いてはいけない方向には障害物をたて、歩いて欲しい方向に道を整備することで、望む方向にコーディングを誘導することができる。

楽に仕様を実現したい層

優秀なエンジニアは成長や良いコードを求め、そのために学習や書き直しを惜しまない。
「コードレビューしてもらえるなんて福利厚生」「お金払ってでもレビューしてほしい」なんて人もいる。
しかしそれは一部の人の話であり、多くの人は新しいやり方を覚えるのが嫌で昨日と同じことを繰り返したい層もいる。
そうした層にとっては楽に仕様が実現できれば良く、その目的意識に対して品質を高めろという要求は障害と感じられるだろう。
つまりそうした人たちにコードレビューで指摘してもストレスを与えることになり、不満につながりうるのだ。
一方で歩きやすい道を舗装して、自分の意思でそこを歩いてもらえれば「自分で選択した感」を覚えながら品質を担保することができる。

つまりマネジメント観点においても、道を整備してそれで済むならこれ以上のことはない。

壁を作ることの難しさ

では壁を作るだけだとどうだろうか？

たとえばアーキテクチャを分割し、特定の方向性でしか依存できなくさせることはまさに人々に歩く方向を規定するものになりそうだ。

しかしそう簡単な話でなく、その中で最も楽な方法で実装されるようになってしまう。

たとえば壁で囲まれた街を３つ作り、一方通行な道を整備する。
これで街を期待する順番に巡るように人々が歩くかというと必ずしもそうではない。
「そもそも１つの街で全部完結させる方が楽じゃん」となってしまうからだ。

たとえばフロントエンドチームの人は、バックエンドの人にお願いするのが面倒でドメイン知識をフロントエンドに埋め込んだコードを書いてしまったりする。

そして得てして「壁があると実装期間的に厳しいから抜け道を作ろう」と言って抜け道ができ、みんながそこを通るようになる。

レイヤーの責務を整理し、「この責務のものはここに書いてね」と言ってもそれを維持するのは難しいのだ。

道と組み合わせる

これを解決するには、「この街はこれがやりやすい」って特徴づけが大事に思う。

たとえば「10行のコードを書かなければならない」のと「1行のコードですむ」のであれば多くの人は後者を好むだろう。
壁を作るだけでなく、道を作ることでこっちに進みたいと思わせることが重要となってくる。

道と壁でフレームワークを眺める

この道と壁の観点は、さまざまなフレームワークの思想にも表れている。
たとえばRailsはまさにRails wayと言われるように公式の道を作り全員にそこに歩くように強要することでコミュニティ全体の品質を保ってきたフレームワークだ。

一方でフレームワークとしてはルーティング機能ぐらいしか提供せず「後は自由に書いてね」というフレームワークも多い。

自由に歩きたいシニアエンジニアには壁がない方が好まれがちだが、技術選択という観点では道と壁のバランスを考えなければならない。

この記事が気に入ったらサポートをしてみませんか？