使いにくいコンポーネントを引き継いだ経験はありませんか。
たとえばこんな問題です。
classNameのように当然受け取れそうな props を受け取らない。classNameは受け取るのに、!importantを付けなければクラスが効かない、もしくは指定したクラスがまったく当たらない。- 複雑さや事情が絡んで、リファクタリングという選択肢がない。
- コンポーネントの制約を回避するためにその場しのぎの実装でタスクをこなし、結果として技術的負債を積み上げてしまう。
ソフトスキルはしばしばプログラミングスキルの対極として語られますが、実のところプログラミングという「ハードスキル」の側にも応用が効きます。
こうした問題を避け、あるいは最小限に抑えながら、他の開発者が喜んで使えるコンポーネントを作る方法、それが私の言う「共感的コーディング」という考え方です。
よくある設計哲学
一人前の開発者になる過程で、KISS や DRY、YAGNI といったコーディング哲学に一度は触れているはずです。
こんな格言を耳にしたこともあるでしょう。
早すぎる最適化はあらゆる悪の根源である
あるいは、
まず動かし、正しくし、速くする
理屈の上ではこれらの哲学に従うことで、今日のコードはきれいで簡潔になり、将来の変更や保守も楽になります。ところが現場で適用してみると過剰設計に転びがちで、それはどれもあくまで「エンジニアリング上の解」を勧める原則だからです。
忘れてはいけないのは、将来そのコンポーネントを理解し、使うのは一人の「人」だということ。未来の自分も含めて、その人はあなたに質問できない状況にいるかもしれませんし、今日では想像もつかない使い方をするかもしれません。
便利さと制約
コンポーネントを作るときに書いているのは、機能要件を満たすコードだけではありません。同時に「開発者がこのコンポーネントをどう使うか」を一連の判断として決めており、その多くは便利さと制約のあいだのトレードオフです。
共感的なアプローチでは、制約より便利さを優先します。制約は柔軟性を削るため慎重に扱う必要があり、この姿勢でいることで、本当に必要な制約だけを追加するようになります。
結果として、コンポーネントは柔軟になり、他の開発者の仕事も楽になります。
便利さ第一のマインドセット
便利さを第一に置くことの大きな利点は、コンポーネントを自然とシンプルに保てる点にあり、その分テストも保守も楽になります。
機能のあらゆるバリエーションを先回りで想定しようとした結果、コンポーネントを過剰に作り込んでしまう、という罠は意外と陥りやすいものです。
コンポーネントが使いやすければ自然と組み合わせやすくなり、開発者は中のコードに手を入れなくても機能を拡張したりカスタマイズしたりできるようになります。