2018 年の初め以来、私はチームのリーダー/ボス/主任開発者の役職に就いています。好きなように呼んでください。しかし重要なのは、私が XNUMX つのモジュールと、作業するすべての開発者に対して完全に責任を負っているということです。その上で。 このポジションにより、より多くのプロジェクトに参加し、より積極的に意思決定に関与できるようになるため、開発プロセスに対する新たな視点が得られます。 最近、これら XNUMX つの状況のおかげで、理解の尺度がコードとアプリケーションにどれほど影響を与えるかに突然気づきました。
私が言いたいのは、コード (および最終製品) の品質は、コードを設計および作成する人々が自分たちが何をしているのかをどの程度認識しているかに密接に関係しているということです。
あなたは今こう思っているかもしれません。「ありがとう、キャップ。」 もちろん、一般的に何を書いているかを理解するのは良いことです。 それ以外の場合は、猿のグループを雇って任意のキーを打ってもらい、そのままにしておくほうがよいでしょう。」 そして、あなたは完全に正しいです。 したがって、自分が何をしているのかについての全体的なアイデアを持っていることが必要であることを認識していることは当然のことだと思います。 これは理解度ゼロと言えるので、詳細な分析は行いません。 正確に何を理解する必要があるのか、そしてそれが毎日の意思決定にどのような影響を与えるのかを詳しく見ていきます。 これらのことを事前に知っていれば、多くの時間の無駄や疑わしいコードを節約できたでしょう。
以下にコードは XNUMX 行も表示されていませんが、ここで述べたことはすべて、高品質で表現力豊かなコードを作成するために非常に重要であると信じています。
第 XNUMX レベルの理解: なぜ機能しないのか?
少なくとも私の経験では、開発者は通常、キャリアの非常に早い段階で、他の人の助けがなくてもこのレベルに達することがあります。 アプリケーションの一部の機能が動作しないため、修正する必要があるというバグレポートを受け取ったと想像してください。 どうやって進めますか？
標準的なスキームは次のようになります。
- 問題の原因となっているコード部分を見つけます (これを行う方法は別のトピックです。レガシー コードに関する私の本で説明しています)。
- このスニペットを変更する
- バグが修正され、回帰エラーが発生していないことを確認してください。
次に、1 番目のポイント、つまりコードの変更に焦点を当てましょう。 このプロセスには XNUMX つのアプローチがあります。 XNUMX つ目は、現在のコードで何が起こっているのかを正確に調査し、エラーを特定して修正することです。 XNUMX 番目: 感覚で移動する - 条件ステートメントまたはループに、たとえば +XNUMX を追加し、関数が目的のシナリオで機能するかどうかを確認し、その後、別のことを試す、などを無限に繰り返します。
最初のアプローチは正しいです。 Steve McConnell が著書 Code Complete (ちなみに、私はこの本を強くお勧めします) で説明しているように、コード内の何かを変更するたびに、それがアプリケーションにどのような影響を与えるかを自信を持って予測できる必要があります。 記憶を頼りに引用していますが、バグ修正が期待どおりに機能しない場合は、非常に警戒し、自分の行動計画全体を疑う必要があります。
これまでの内容を要約すると、コードの品質を低下させずに適切なバグ修正を実行するには、コード全体の構造と特定の問題の原因の両方を理解する必要があります。
第 XNUMX レベルの理解: なぜそれが機能するのか?
このレベルは、前のレベルに比べて直感的にはあまり理解されません。 新人開発者の私は上司のおかげでそれを学び、その後は新人に本質を説明することを繰り返しました。
今回は、一度に XNUMX つのバグ レポートを受け取ったとします。XNUMX つ目はシナリオ A に関するもので、XNUMX つ目はシナリオ B に関するものです。どちらのシナリオでも、何か問題が発生します。 したがって、最初のバグに最初に取り組みます。 レベル XNUMX の理解のために開発した原則を使用して、問題に関連するコードを深く掘り下げ、アプリケーションがシナリオ A のような動作をする原因を解明し、必要な結果を生み出す適切な調整を行います。 。 すべてが順調に進んでいます。
次に、シナリオ B に進みます。エラーを引き起こそうとシナリオを繰り返しましたが、驚くべきことに! — これで、すべてが正常に機能します。 推測を確認するために、バグ A の作業中に行った変更を元に戻すと、バグ B が戻ってきます。 バグ修正により両方の問題が解決されました。 ラッキー！
あなたはこれをまったく当てにしていませんでした。 シナリオ A のエラーを修正する方法を思いつきましたが、それがシナリオ B で機能した理由がわかりません。この段階では、両方のタスクが正常に完了したと考えがちです。 これは非常に論理的です。重要なのはエラーを排除することでしたね。 しかし、作業はまだ終わっていません。自分のアクションがシナリオ B のエラーを修正した理由をまだ理解する必要があります。なぜですか? なぜなら、それは間違った原則に基づいて機能している可能性があり、その場合は別の方法を探す必要があるからです。 そのようなケースの例をいくつか示します。
- 解決策はエラー B に合わせて調整されていないため、すべての要因を考慮すると、知らず知らずのうちに関数 C が壊れている可能性があります。
- 同じ機能に関連する XNUMX 番目のバグがどこかに潜んでいる可能性もあり、シナリオ B でシステムが正しく動作するかどうかはバグ修正に依存します。 今はすべてがうまくいっているように見えますが、いつかこの XNUMX 番目のバグが発見され、修正されるでしょう。 その後、シナリオ B でエラーが再び発生しますが、そこだけであれば問題ありません。
これらすべてがコードに混乱をもたらし、いつか、おそらく最も不都合な瞬間に、あなたの頭に落ちてくるでしょう。 すべてがうまくいくように見える理由を理解するために時間を費やすには、意志力を奮い立たせる必要がありますが、それだけの価値はあります。
理解の第 XNUMX レベル: なぜそれが機能するのか?
私の最近の洞察はまさにこのレベルに関連しており、もっと早くこの考えに至っていたらおそらく最も有益だったと思われる洞察です。
わかりやすくするために、例を見てみましょう: モジュールは関数 X と互換性を持たせる必要があります。あなたは関数 X に特に詳しくありませんが、関数 X と互換性を持たせるには F フレームワークを使用する必要があると言われました。 X と統合されたモジュールは、X と正確に連携して動作します。
あなたのコードは、その誕生の初日から F フレームワークとまったく接触していないため、実装はそれほど簡単ではありません。 これはモジュールの一部に重大な影響を及ぼします。 しかし、あなたは開発に身を投じます。コードの作成、テスト、パイロット バージョンの展開、フィードバックの取得、回帰エラーの修正、予期せぬ複雑な問題の発見、当初合意された期限に間に合わない、追加のコードの作成、テスト、フィードバックの伝達に何週間も費やします。回帰エラーの修正 - これはすべて、F フレームワークを実装するためです。
そして、ある時点で突然、フレームワーク F では機能 X との互換性がまったく得られないことに突然気づき、あるいは誰かから聞いたかもしれません。もしかしたら、費やした時間と労力は完全に間違っていたのかもしれません。
以前、私が担当していたプロジェクトで似たようなことがありました。 なぜこのようなことが起こったのでしょうか? なぜなら、関数 X がどのようなもので、それがフレームワーク F とどのように関係しているのかをほとんど理解していなかったからだ。どうすればよかったでしょうか? 開発タスクを割り当てる担当者に、他のモジュールで行われたことを単に繰り返すのではなく、またはこれが機能 X が行う必要があるという言葉を鵜呑みにするのではなく、意図した一連のアクションがどのように望ましい結果につながるかを明確に説明するよう依頼してください。
このプロジェクトの経験から、なぜ特定のことをするように求められているのかを明確に理解するまでは開発プロセスを開始しないことを学びました。 きっぱりと断ります。 仕事を受け取ると、最初の衝動は時間を無駄にしないようにすぐにそれを引き受けることです。 しかし、「すべての詳細に入るまでプロジェクトを凍結する」というポリシーにより、無駄な時間を大幅に削減できます。
たとえ彼らがあなたにプレッシャーをかけようとしたり、あなたに仕事を始めさせようとしたとしても、その理論的根拠は理解できませんが、抵抗してください。 まず、なぜそのような仕事が自分に与えられているのかを理解し、それが目標への正しい道であるかどうかを判断してください。 私はこれらすべてを大変な方法で学ばなければなりませんでした。私の例がこれを読んだ人たちの生活を楽にすることを願っています。
第 XNUMX レベルの理解: ???
プログラミングでは常に学ぶべきことがたくさんありますが、私はまだ理解というテーマの表面をなぞっただけだと思っています。 長年コードを扱う中で、他にどのような理解レベルを発見しましたか? コードとアプリケーションの品質にプラスの影響を与えたどのような決定を下しましたか? 間違っていたことが判明し、貴重な教訓を得た決定は何ですか? コメントであなたの経験を共有してください。
出所： habr.com