プログラマが一度に関数を書けないのはなぜですか? それは書きたくないからでしょうか?

なぜ彼が作った関数にはこれほど多くのバグがあるのでしょうか?

導入

彼が作った関数になぜこれほど多くのバグがあるのかについて話しましょう。

皆さん、こんにちは。最近興味深い質問を見つけました。

なぜプログラマーは一度にすべてを書くことができず、常にバグを修正する必要があるのでしょうか?

私の意見では、プログラマーは機械ではなく人間です。

プログラマにこの質問をすると、答えはわずかしかありません。

1. 要件の理解

プロジェクトの開始時には、要件が完全に理解されていない場合があります。

プロジェクトが進行するにつれて、より詳細な情報が明らかになり、新しい要件やより明確な要件に対応するためにコードの調整が必要になる場合があります。

まず、要件の送信には通常、次のタイプが含まれます。

口頭伝達: プログラマーはプランナーの文章を聞いて、これが要件であると想定する場合があります。
需要会議: 関係者が協力してニーズを分析し、議論する、よりフォーマルな会議だと思います。
一時的に追加: 先にリクエストを行ったときに省略され、後で補われたもの。
非就業日の追加: 非就業日の休憩中に、マネージャーまたは上司から電話がかかります。

これにはすべて、人々の間のコミュニケーションと理解が関係します。人の状態や感情に非常に影響されやすいのです。

それは、プログラマが要件を理解する際に、意図的でない文や意図的な文を慎重に計画しているためかもしれません。

また、プログラマーが会議中に居眠りをしたり、あまり感動しなかったりしたことが原因である可能性もあります。

プログラマが不満を抱いていたときでも、この要求は受け取られました。

2. 機能の複雑さ

多くの機能には、複雑なビジネスロジック、データ処理、およびユーザーインタラクションが含まれます。

プログラマは、関数全体がどのように動作するかを理解する過程で、関数を十分に明確に理解できず、初期実装の検討が不十分になる可能性があります。

大きな関数であれ、小さな関数であれ、バグが存在することは誰もが知っていると思います。

ただし、比較的複雑な機能では、バグが発生しやすくなり、さらに発生しやすくなります。

著者は、これは人生における選択に似ていると考えています。選択が重要であればあるほど、選択は難しくなります。

3.新規コンテンツ

プロジェクトの反復プロセス中に、プロジェクトのフレームワークや方向性とはまったく異なる新機能の導入が必要になる場合があります。

これは必然的にプログラムの安定性に影響を与えます。

コンテンツが低いほど、コンテンツを変更する際の変更が容易になり、影響が広がります。

古いプロジェクトとまったく互換性のない新しいコンテンツが存在する可能性があり、そのようなコンテンツを強制的に導入することは設計レベルで正しくありません。

また、プログラマーが適切に考えず、計画やマネージャーの変更をより包括的に考慮しなかったことも原因である可能性があります。

4. 時間的プレッシャー

プロジェクトには時間が制限されていることが多く、その結果、プログラマーは限られた時間内にタスクを完了しなければならない可能性があります。

これにより、潜在的な問題が最初は見落とされ、後で修正する必要が生じる可能性があります。

時間のプレッシャーにより、プログラマは遭遇した問題をスキップし、完了しやすい方向に実行することがよくあります。

次に、これらの行き詰まった点は関数の最終処理に組み込まれます。これは、以前の試験と同様です。

先生は私たちに、試験で難しい問題に出会ったら、最初にその問題を飛ばし、問題用紙を読み終えるまで待ってから、難しい問題を読み直すようにと教えました。

しかし、多くの場合、これらのスキップされたコンテンツでも問題が発生し、それは困難または困難な問題であり、解決できません。あるいは、これらの問題を解決するための時間があまり残されていません。

5. 機能的結合

チームコラボレーション環境では、コードのさまざまな部分が複数のプログラマによって同時に変更される可能性があり、競合やバグが発生する可能性があります。

さらに、異なるモジュール間の複雑な相互作用は、テスト前に完全に予測することが難しい場合があります。

この種の問題は通常、プログラマ A がプロジェクトの関数 Aを変更するときに発生しますが、予期せずプログラマB が関数 Bに問題を抱えています。

これには、フレームワークとプロジェクト間の結合が含まれます。コードの結合が激しくなるほど(「クソ山」と呼ばれることがよくあります)、修正がきれいにならず、他の機能に予期せぬ影響を与えることになります。

6. ハードウェアと環境の変更

プログラムは異なるハードウェアや環境で実行される可能性があり、それによって考慮されていない問題が発生する可能性があります。

さまざまな環境に対応するには、いくつかの修正と調整が必要になる場合があります。

ご存知のとおり、ユーザーの使用環境は非常に奇妙な場合があります。

まず、デバイス環境は、ネイティブAndroid、iOS、 Web ページ用のH5、PC、小規模プログラムなど、いくつかのタイプに分かれています。

第二に、異なるネットワーク環境、2g、3g、4g、5g、Wi-Fi です。

プログラマーが開発中に最高のネットワークと最高のマシンを使用した場合、ユーザーの千元のマシン、数万元のマシン、または古いマシンに行くと、パフォーマンスは異なります。

対処方法

要求が与えられると、解決できない問題がたくさんありますか?

著者は、「そうではありません。人は進歩します。継続的な要約と最適化により、バグの発生を徐々に減らすことはできますが、完全になくすことはできません」と信じています。

要件理解：プログラマーとプランナー・マネージャーの関係は円満である必要があり、業務上のコミュニケーションやコミュニケーションに個人的な感情や意見が含まれないようにする必要があります。すべての要件を満たすために真剣に取り組みます。
機能の複雑さ: プログラマーとプランナー/マネージャーは機能の複雑さを一緒に考慮する必要があります。プランナーとマネージャーは複雑さを考慮せずにやみくもに要件を提示することはできませんし、プログラマーは機能の変更を考慮せずにやみくもに機能を実装することはできません。
新しいコンテンツ: プログラマーは古いプロジェクトに対する新しいコンテンツの影響を慎重に評価する必要があり、プランナー/マネージャーはこの機能がプロジェクトに本当に適しているかどうかを真剣に検討する必要があります。
時間的プレッシャー: 機能の完了時間をより合理的に評価し、不当なコスト削減や効率向上を拒否します。
機能の結合: コーディング能力を継続的に向上させ、より良い記述方法を学習し、さまざまなニーズの変化に対応します。
ハードウェアと環境の変更：異なる環境でのテストを強化するここで考慮すべきは、異なる環境でのテストの利便性ですテスト環境を常に最適化し、テストの困難がバグの発生につながらないようにします