ときどき、プログラミングの間違いを追跡することの利点について人々が話しているのを耳にしました。私は、自分のコードで見つけたバグのリストと、その原因となった可能性のあるバグのリストを保持し始めました。私が持っている主な質問はこれです:
- プログラマーとして改善できるように、間違いに関連するどのような情報を追跡する必要がありますか?
そして、これに関連する他のいくつかの質問:
- 間違いを記録し始めたら、この情報をどのように使用すればよいですか?
- 間違いを追跡することは本当に有益ですか?
ときどき、プログラミングの間違いを追跡することの利点について人々が話しているのを耳にしました。私は、自分のコードで見つけたバグのリストと、その原因となった可能性のあるバグのリストを保持し始めました。私が持っている主な質問はこれです:
そして、これに関連する他のいくつかの質問:
これは、追跡とレビューに実際に注意を払っている場合にのみ役立ちます。私がチームで働いていたとき、たとえば本番環境のサーバーが壊れていて、独自のドメイン名やパブリック IP アドレスを解決できないなどの文書がどれだけあったとしても、6 か月ごとに電話がかかってきました。新しい開発者が担当していた展開チームまたは開発チームから午前 4 時に、彼らは忘れたか、気づいていませんでした。
展開を担当し、紙のチェックリストを持っていた特定のエンジニアを覚えています。私たちは彼にチェックリストを記録することを強制する展開ツールを作成しましたが、彼は常に接続文字列を設定するのを忘れていました (その結果、午前 4 時に電話がかかってきました)。ポイントは、慎重に使用する場合にのみ価値があるということです.
これを使用する最良の方法は、ルールを fxcop などのコード アナライザーに実装することです。
個々の間違いを記録するよりも役立つのは、そもそもなぜそれが間違いだったのかを確実に理解できるようにすることだと思います. ほとんどの間違いは、何かについての理解の欠如から生じており、その理解を正せば、将来の潜在的な間違いを完全に排除できます。何かをログに記録するとしたら、それは私が以前に知らなかった経験から学んだことであり、後で振り返ったときにあまり役に立たない可能性が高い、犯した間違いの詳細ではありません.
後者を適切なチェックリストに追加し、必要に応じて頻繁に参照する
間違いを追跡することは価値があると思いますが、私の経験では、それらをあるレベルで分類することは非常に役立ちます。
すべてのプログラマーは、キャリアの過程で、百科事典を埋めるのに十分な数の間違いを犯します。それらすべてから巨大なチェックリストを作成すると、最終的にすべての時間をチェックリストに費やすことになるため、コーディングを完了することはできません. そのため、自分にとって意味のある方法で間違いを分類して、現在取り組んでいるコードの種類で最も重要な間違いをリストから探し出せるようにします。
また、何を収集するかについては、上記に追加します。
はい、個人的な間違いを追跡することは有益です。多数のデータ ポイントについては、 SEIを参照してください(ここではランダムに 1 つです)。そのような方法論の 1 つがパーソナル ソフトウェア プロセス (PSP)です。ここに入るには長すぎますが、これについての本があります。PSP には、この無料の SEI 出版物もあります。
SEI に抵抗し、アジャイルが進むべき道だと考える場合は、 Clean Code: A Handbook of Agile Software Craftsmanship (publisher website) のような本を読んだほうがよいでしょう。
結論: 規律のある開発者 = 良い、規律のない開発者 = 悪い。
また、間違いを正確に追跡するにはどのくらいの時間が必要か、また、その時間を直接ソフトウェアの改善に費やすほうがよいかどうかについても質問したいと思います。最小限の時間でこれを行うことができ、記録を参照して将来の間違いを防ぐことができれば、価値があるかもしれません. しかし、長い目で見れば、あなたが犯しがちな間違いの完全にハイレベルなリストに固執する方が良いと思います.
再発する傾向がある傾向や同様のタイプのエラーを探します。自分が犯したエラーの種類に気付いたら、それらに注意を払うか、コーディング スタイルを変更してエラーを回避することができます。
例として、私は前世でオフィスメイトと非常に密接に仕事をしていました。ある時点で、私は最初の文の途中で奇妙な動作を説明していましたが、彼は「カウンターを増やしてください」と中断しました。今日もループカウンターを再確認しています!
将来の間違いのログを記録する代わりに、バグトラッカーの履歴を確認して、発生し続ける一般的なタイプのエラーを見つけてみてください。
とても刺激を受けたので、明日これを試してみようと思います。
私も同じことを考えてきました。当分の間、私はバグを修正した小さなスプレッドシートを保持しています。これの目的は、より一般的なエラーが発生していることを認識できるようにすることです。
願わくば、私がパターンを理解し始め、よくある間違いを何度も犯すことを避けられるようになることを願っています。
おそらく私は構造化された方法でデータと情報を収集するのが好きな分析担当者であるため、これが私の仕事をより興味深いものにしています。
エラーを不適切なツール、習慣、方法、または知識の使用に関連付けるようにしてください。ほとんどの場合、以前にエラーをキャッチする方法があったはずです。型安全性、単体テスト、コード レビュー、コーディング標準、より優れた API 設計、より優れたドキュメントと作業環境などのことが頭に浮かびます。
カスタム ワークフローで JIRA を使用しています。バグの場合、問題をクローズする前の最後のステップは、「根本原因」を選択できる画面です。私が構築した最後の 3 つのシステムで発生したすべてのバグの根本原因の履歴があります。
何を記録するかに注意してください。すべての悪い状況が間違いというわけではありません。状況によっては、避けられないものや、どうしようもないほど制御できないものがあります。
あなたをパニックモードに陥らせる他人の悪い計画はあなたの間違いではありません. 他人の間違いを注意深く記録することはできますが、それでは何の意味がありませんか? 他の人が何をしているかを追跡している場合は、治療を受ける必要があります。
不十分な予算、スケジュール、または変更に関するコミュニケーションを提供する不適切な計画は、複合的な問題になる可能性があります。
後から考えると (常に 20/20 です)、決定が間違っていたことがわかります。ただし、当時は入手可能な最良の情報に基づいていました。それは間違いではありません。「If wed know that X...」で始まる文は、間違いの分析には役に立ちません。次回その決定を下すときに知っておく必要があるすべての事項のチェックリストを作成してみることができます。しかし次回は、その決定を正確に行うことはできず、他の情報が欠落していることになります。
「プログラマーとして改善できるように、自分の間違いに関連するどのような情報を追跡する必要がありますか?」
他の人のブログを読む。自分で書いてください。公開する必要はありません。しかし、それぞれの間違いをストーリーに変える必要があります。
これをメタデータに溺れさせないでください。これは、データベースやバグトラッカーでさえ受け入れられません。間違いとは、誰かが間違った選択をして、そこから立ち直ったという話です。
これがあなたの概要です。
また、ほぼ同じ形式で成功を記録する必要があります。
迷ったときは映画を観ましょう。真剣に。キャラクターは選択に直面し、間違いを犯し、それらの間違いから回復します。そのストーリーラインはドラマの本質です。間違いも同じです。