そもそも、すべての欠陥は一種の謎です。 「ディビルがそのように書くことができるもの」という形式の場合もありますが、特にプロジェクトが優れたチームによって開発されている場合は、より複雑になることがよくあります。 これらのなぞなぞを解くのは非常に興味深い。 私は、いくつかの欠陥を見て、「これは単純に不可能だ」と考えていたに違いない。 そのようなパズルを解くことは脳を刺激し、革新的で興味深い解決策を見つけるためにそれを訓練します。
欠陥は通常「悪」であり、最も人里離れた隅に隠れています。 それらを見つけて修正すればするほど、システム、その操作、および機能についての知識が深まります。 結局のところ、多くの場合、途中で大量のコードを掘る必要があります。 これは、システムの知識があればそれらをより効果的に解決できるため、将来のタスクに非常に良い影響を与えます。
欠陥は、プロジェクトで使用されるツールとライブラリをよりよく理解するのに役立ちます。 結局のところ、彼らにも欠陥があり、そのために何かが機能しなくなる。 欠陥がなければ、一般的なライブラリの内部動作にあまり注意を払うことはほとんどありません。 欠陥は、他の人のコードを理解し、それを読んで理解する能力を刺激します。これは優れた開発者の主要なスキルの1つです。
最後に、私たちは自分の過ちや他人の過ちから学びます。 欠陥の原因を理解したので、教訓を得て、将来同じレーキを踏まないでください。 そのようなレッスンが多ければ多いほど、コードは良くなり、将来的には欠陥が少なくなります。
そして、ボーナスとして、あなたは常に何か言いたいことがあります。 実際、多くの欠陥が単一のコピーに存在し、それらを「釣り上げた」のはあなたでした。 これは漁師とほぼ同じです。
しかし、すべての欠陥にこれらの利点があるわけではありません。 ありふれた、同じ愚かな欠陥があります。 誰もそれらを修正するのが好きではありません、彼らは退屈で面白くないです。 しかし、これは大きなプラスです。 このような欠陥の有能な開発者は、チームプロセスの変更と、不必要な退屈な作業を回避するコードを記述するアプローチを促します。 このため、テスターとの作業が変わり、開発者によってより自動化されたテストが作成されており、TDD、コードレビュー、静的コード分析が使用されています。 愚かな間違いを避けるよう努めています。
そのため、発見されたすべての欠陥に感謝しています。 詳細な説明、追加のアーティファクト、その他の一般的なものは必要ありません。 コードをざっと調べて理由を見つける準備ができています。結局のところ、これは私が学ぶ機会であり、それが顧客に喜びをもたらすでしょう。 誰かを幸せにすることがどれほど簡単かを考えてみてください、それは素晴らしいことです！ おもしろくて有益な欠陥だけをお祈りします！