コンピュータのためのコードを書くのは難しいが、人間のためのコードを書くのはさらに難しい
- コンピュータ向けのコードを書くことは、それ自体ですでに難しい。大きなビジネス目標を小さな論理命令へと分解しなければならないため。
- しかし、人間向けのコードを書くのはさらに難しい。これはコンピュータサイエンスと心理学が結びついた作業である。
- Richard Feynman の言葉を借りれば、もし電子が感情を持っていたら物理学がどれほど難しくなるか想像してみてほしい。これは人間向けのプログラミングを説明するのにふさわしい。
始めること自体が製品である
- ユーザーのフィードバックを聞くことは重要だが、ほとんどのフィードバックは製品を頻繁に使うパワーユーザーから来る。
- 生存バイアスが存在する。使い始めなかったユーザーのフィードバックはほとんど聞こえてこない。
- コンシューマー製品は長い時間をかけてオンボーディングのプロセスを最適化してきた。開発ツールも同様であるべきだ。
- オンボーディングのプロセスを製品の一部と見なし、設定を最小限にして、ユーザーが数分以内に製品を使えるようにすべきである。
人は「中核概念」ではなく例から学ぶ
- 人はパターンマッチングに優れている。一方でコンピュータは厳密な論理に従う。
- 多くの開発ツールのドキュメントは、コンピュータプログラムのように書かれている。これは人間には適していない。
- 例を通じて学ぶほうがより効果的である。例はユーザーがツールを理解する助けになる。
成功の罠に落とし込む
- プログラミングの基本モードはエラー修正である。ユーザーはほとんどの時間をエラー修正に費やす。
- エラーを成功へ導くことが重要である。
- エラーを機会として活用し、ユーザーを正しい道筋へ案内しなければならない。例外処理にコードスニペットを含め、警告メッセージを通じて助けを提供すべきである。
概念的な過負荷を避ける
- 新しい概念を理解しなければならないことは摩擦を生む。
- 2〜3個の概念なら問題ないが、8個の新しい概念を学ぶのは負担が大きい。
- 少ない概念で強力な機能を提供するフレームワークが理想的である。たとえば React は、いくつかのシンプルな概念だけで強力な機能を提供している。
概念的ダック原則
- 新しい概念を導入するときは、ユーザーにとって親しみのある用語を使うことが重要である。
- たとえば、新しい値を評価するものを「関数」と呼ぶのがよい。そうすることで、ユーザーは既存のメンタルモデルを活用できる。
プログラマビリティ
- ユーザーはコードベースの中で創造的な作業を行うことになる。
- フレームワークのほぼすべてが「プログラマブル」であるべきだ。
- CLI ではなくコードから直接呼び出せるようにし、設定を SDK や API に置き換えるべきである。
魔法、デフォルト、シンタックスシュガーには慎重であるべき
- デフォルトや魔法のような機能は慎重に導入すべきである。
- デフォルトが 97% 以上、魔法が 99% 以上のケースで適用されないなら、導入は避けるべきである。
- コーディングはゴルフではない。コードを最小限に書くことを目標にせず、可読性を重視すべきである。
人間のためのコードを書くのは難しい
- ほとんどのものはイミュータブルであるべきだ。
- 「スキャフォールディング」（コード生成）は避けるべきである。
- フィードバックループは極めて高速にすべきである。
- ユーザーが簡単に対処できるよう、廃棄の手順を用意すべきである。
- ドキュメントや例では、コードスニペットに対する自動テストを使うべきである。
GN⁺ のまとめ
- この記事は、人間のためのコードを書く難しさと、その解決策を扱っている。
- ユーザーフレンドリーな開発ツールを作ることが重要であり、それはオンボーディングのプロセスから始まる。
- 例を通じて学ぶことは効果的であり、エラーを成功へ導くことが鍵である。
- 新しい概念を導入するときは、ユーザーにとって親しみのある用語を使い、プログラマビリティを考慮すべきである。
- デフォルトや魔法のような機能は慎重に導入し、可読性を重視すべきである。
1件のコメント
Hacker Newsの意見
人はそれぞれ異なる方法で学ぶ
文章力と共感力が重要である
誰もが例から学ぶわけではない
コードは人間のために書かれる
Code Completeからの引用
コードを書くことは人間のためのものだ
IDEの発展に関する意見
ブログ記事の紹介
プログラミングの学習方法に関する意見
例と中核概念の重要性