すべてを受け入れ、何も理解しない
コードの提案を受け入れるためにEnterキーを押すことは、それらをスクロールして通り過ぎるよりも労力がかかりません。たった1回の打鍵で、そのコードはあなたのものになります。しかし、そのコードを読み、理解するスピードは、少しも速くなっていないのです。
コードを受け入れる速さと、それを理解する速さの間には、ギャップが存在します。ミスが起こるのは、まさにこのギャップにおいてです。
技術的負債には、かつて明確な原因がありました。厳しい締め切りがあったか、あるいは手を抜いたかです。その理由は特定できました。しかし今では、穏やかな火曜日に負債を築き上げることさえあります。見た目が良さそうだからという理由で、6つ連続で提案を受け入れてしまう。誰も急かしてはいないのに、コードは検証されないまま残るのです。
ブライアン・カーニハンは1974年に、デバッグはプログラムを書くことの2倍難しいと述べました。彼が言っていたのは、人間が書くコードのことです。少なくとも人間は、自分自身の成果物を理解しています。
今日では、提案されたコードがリンターを通過し、テストさえもパスすることがあります。それでも、間違った前提に基づいている可能性があるのです。これは、人々が提案を「コード」としてではなく、「出力結果」として読んでしまうために起こります。見た目が良さそうな出力は、そのまま承認されてしまうのです。
もしモデルがコードとテストの両方を書いているとしたら、あなたは生徒自身の回答を使って宿題の採点をしているようなものです。これでは、ロジックが健全であるかどうかも、エッジケースがカバーされているかどうかも分かりません。コードが自分のエディタに、自分のスタイルで表示されると、このことを忘れがちになります。
これにより、以下のような実害が生じます：
- 読んだこともないコードのデバッグをすることになります。 数週間後に何かが壊れたとき、あなたはゼロから調査を始めることになります。
- エッジケースで失敗します。 提案されたコードは、ハッピーパス（正常系）はうまく処理します。nullチェックも含まれているかもしれません。しかし、ビジネスに必要な特定のロジックを見落としているのです。
- 自分のプルリクエストを弁護できなくなります。 レビュアーから「なぜこのメソッドを選んだのか」と聞かれても、答えられません。あなたは決定を下したのではなく、ただ拒否しなかっただけなのですから。
これらのツールは有用です。コードベースの探索や、新機能の計画に役立ちます。問題は、あなたの「姿勢」です。すべての提案を、単にちらっと見るものではなく、読み、判断すべきものとして扱わなければなりません。
ボイラープレートやクイックスクリプトであれば、スピード重視でも構いません。しかし、ビジネスロジックやセキュリティに関しては、アプローチを変える必要があります。そのコードを、自分が責任を持つものとして読んでください。実際、あなたが責任を負うことになるのですから。
代わりに、以下のことを行いましょう：
- コードを求める前に、解決策についてモデルと議論する。
- 自分で書いたかのように、差分（diff）をレビューする。
- コードを受け入れる前に、ツールにその推論の根拠を説明させる。
- 提案をジュニアデベロッパーの成果物のように扱う。有用ではあるが、それが「正解」とは限らない。
- 驚いた行ではスピードを落とす。驚きはシグナルです。
打鍵のコストは下がりました。しかし、あなたの責任が軽くなったわけではありません。理解を伴わないスピードは、単に「高速な負債」を生むだけです。
Source: https://dev.to/cloudx/accept-all-understand-none-4dob
Optional learning community: https://t.me/GyaanSetuAi