共感的コーディング
使用するのが難しいコンポーネントを継承したことがありますか？
次のような問題があります：
classNameなど、普通に使えるであろうPropsを受け入れない。classNameを受け入れるが、!importantを使用しないとclassが機能しないか、あるいはclassが全く適用されない。- 複雑さや他の理由により、リファクタリングが選択肢にない。
- コンポーネントの制限を回避するために解決策をハックする必要があり、その結果、技術的負債が生じる。
ソフトスキルはプログラミングスキルと対照的によく言及されます。しかし、ソフトスキルはプログラミングの「ハードスキル」にも適用できます。
これらの問題を回避または最小限に抑え、他の人が喜んで使用するコンポーネントを構築する方法は、私が「共感的コーディング」と呼ぶ考え方のことです。
要約
- 多くのコーディング哲学がありますが、ほとんどはエンジニアリングソリューションに基づいています。一方、共感的コーディングは、他の開発者を中心にしたソリューションに焦点を当てています。
- コンポーネントを記述する際、便利さと制限の間で選択を迫られます。共感的コーディングは、まず便利さに焦点を当てています。
- 共感的コーディングにより、コンポーネントが柔軟で使いやすく、複雑さが少なくなります。
一般的な哲学
熟練した開発者になる過程で、KISS、DRY、YAGNIなどのコーディング哲学に出会ったことでしょう。
以下のような言葉を聞いたことがあるかもしれません：
最適化を早めに行うことはすべての悪の根源である
および
動くものを作り、正しくする、速くする
理論的には、これらの哲学を適用することで、今日クリーンで簡潔なコードを書くのに役立ち、将来の変更やメンテナンスが容易になります。しかし、実際には、これらの哲学を適用することが過度のエンジニアリングにつながることがあります。なぜなら、これらはエンジニアリングソリューションを提唱しているからです。
重要なことは、将来、誰かがあなたのコンポーネントを理解し使用する必要があること（将来の自分を含む）、おそらくあなたが質問に答えることができない状況である可能性があることを覚えておくことです。彼らは、今日予測できない方法であなたのコンポーネントを使用する必要があるかもしれません。
便利さ vs 制限
コンポーネントを構築する際、機能要件を満たすためだけのコードを書いているわけではありません。開発者がコンポーネントをどのように使用するかについての一連の意思決定も行っています。これらの選択肢は主に便利さと制限の間のトレードオフの関係にあります。
共感的なアプローチは、制限よりも便利さを優先します。制限は柔軟性を減らすため、注意深く検討する必要があります。この考え方を取り入れることで、必要な制限のみを追加する可能性が高くなります。
その結果、あなたのコンポーネントはより柔軟になり、他の開発者の作業を容易にします。
便利さ第一マインドセット
便利さ第一マインドセットの大きな利点は、コンポーネントをよりシンプルに保つことを奨励する点です。これにより、テストやメンテナンスが容易になります。
機能のあらゆる可能なバリエーションを予測しようとして、コンポーネントを過度に設計してしまう罠に陥りやすいことがあります。
コンポーネントを使いやすくすると、それらを簡単に組み合わせることができ、開発者は基礎となるコンポーネントコードを変更せずに機能を拡張したりカスタマイズしたりできます。
実践例
便利さ第一のマインドセットが実践でどのように見えるかを示す一連の記事をリリースします。各記事では、実際のコンポーネントをステップバイステップで構築し、各決定を説明します。
これらのコンポーネントはReactで構築され、Tailwindでスタイリングされていますが、この考え方は一般的な開発や好きなスタイリングライブラリにも適用できます。