本番環境に移行するバグをキャッチする機能
これがこの質問に適切な場所ではない場合はお詫びします。その場合は別の場所に案内してください:)
オブジェクトがアクティブであるかどうかを示すオブジェクトのメンバーフィールドについて、ソフトウェアエンジニアリングの経験がある（公式の教育ではない）上司と話し合っていました。
問題のオブジェクトは、オブジェクトのパラメーターと属性、およびオブジェクトの目標を指定する従業員（ウイルス対策ルールのようなものを想像してください）によって構築されます。
次に、このオブジェクトはバイナリ形式にコンパイルされ、ミラーとソフトウェアアップデーターを介してお客様のソフトウェアインストールに配布されます。
このオブジェクトには、アクティブか非アクティブかを示すフィールドが含まれています。これは、設計および開発の初期段階で、配布のエンドポイントでオブジェクトをオフにする必要があると考えられたために追加されました。
オブジェクトは、お客様のソフトウェアインストールで個別のファイルに保存されます。オブジェクトをオフにすると、バイナリオブジェクトファイルをアクティブに書き込んで、内部のフィールドを調整することになります。この内部の「アクティブ」フィールドに実際に期待されるユースケースはなく、顧客はこれらのオブジェクトについて何も知ることを期待されていません。したがって、誰も何もこれらのオブジェクトをオフにすることはないと予想されました。特に、ファイルを削除してオフにすることができ、ファイルを更新すると、ファイルを削除したか切り替えたかに関係なく、ファイルが再びオンになります。
インターフェースが完了し、オブジェクトと各オブジェクトがアクティブか非アクティブかを格納するデータベースに接続されているため、エンドポイントでオブジェクトを切り替える必要があるという考えはすぐに却下されました。
データベースで非アクティブとしてリストされている場合、インターフェイスはオブジェクトを配布用にプッシュしません。これは非常に単純なメカニズムです。
会話に早送りして、コンパイルされたオブジェクトファイルでこのフィールドの目的について話し合っていました。
オブジェクトがプッシュアウトされている場合は、とにかくインターフェイスで有効にする必要があるため、コンパイルされたオブジェクトからフィールドを簡単に削除できると述べました。
私の上司は、UIプログラマーが間違いを犯さないことを前提としているため、2番目の防御策を講じることで、押し出されることが意図されていなかったが、何らかの理由で誤って押し出されたオブジェクトの使用を防ぐことができます。
私は、「開発者のミス」を機能を実装する理由（主にこの場合）とは考えていなかったと述べました。ミスは通常、テスト/デバッグ/ QAによって検出され、副次的な機能では回避されるべきではありません。
結局のところ、それはとにかくコンパイルされたオブジェクトの「アクティブ」フィールドに入力するインターフェイスになるので、インターフェイスがアクティブであるはずのないオブジェクトを誤って押し出した場合、コンパイルされたオブジェクトもそれを示す可能性が高いですインターフェイスがそのフィールドに入力したため、内部フィールドでアクティブでした。 （もちろん、バグがインターフェースのアクティブフィールドの比較のような他の場所にある場合を除きます）
上司は「それを「機能」ではなく安全だと考えてはいけない」と述べたが、この問題に対する私の立場は素朴であり、「テスト/デバッグ/ QAによって間違いを見つけなければならない」という声明は確かに真実ではない現実世界では。
結局のところ、これは非常に小さな問題であり、フィールドが保持されるかどうかを議論することを目的とはしていません。私は上司による議論で取られたスタンスの原則に興味があり、他のどの専門家に興味があります。業界はこれについて言わなければなりません。
これが悪いアプローチである私の理由は次のとおりです。
テスト/デバッグ/ QAが最も単純なバグもキャッチできないと想定し、これらの単純なバグから保護するために追加の機能をコーディングする必要がある場合、開発プロセスにさらに深い問題があることを示しているのではないですか？
さらに、バグから保護するために追加機能をコーディングする必要がある場合、それらの追加機能にバグがある場合はどうなりますか？バグから保護する機能で起こりうるバグから保護するために、さらに多くの追加機能をプログラムしますか？
あなたが尋ねる：
テスト/デバッグ/ QAが最も単純なバグもキャッチできないと想定し、これらの単純なバグから保護するために追加の機能をコーディングする必要がある場合、開発プロセスにさらに深い問題があることを示しているのではないですか？
これらのプロセスや人々が「最も単純なバグでさえも捕まえられない」と誰が示唆しているのでしょうか。それはあなたの上司によって育てられなかったストローマンのように聞こえます。非常に単純なバグが、高品質のテストの多くの層を通過して出荷されることを確認しました。それは間違いなく起こります、そしてそれは人々が無能であるかプロセスが役に立たないからではありません。これは、ソフトウェアが非常に複雑であり、宇宙の存続期間中に、プログラムが持つ可能性のある入力のごく一部でさえもカバーするのに文字通り十分な時間がないためです。
さらに、バグから保護するために追加機能をコーディングする必要がある場合、それらの追加機能にバグがある場合はどうなりますか？バグから保護する機能で起こりうるバグから保護するために、さらに多くの追加機能をプログラムしますか？
それは滑りやすい傾斜の議論のように聞こえます。他の方向に進むこともできます。バグからの保護やバグの発見に役立つ追加機能のコーディングが機能しない場合、通常の機能のコーディングでも機能しますか？ソフトウェアはまったく機能しますか？
答えはもちろん、はいソフトウェアが機能し、テストが機能し、防御的なプログラミング手法が機能するということです。しかし、それらは完璧ではなく、決して完璧ではありません。ビジネスにとどまり、ユーザーが必要とするタスクを実行できるように、これらの適切なバランスを見つける必要があります。場合によっては、次善のコードを記述したり、大まかな回避策を使用して何かを戸外に出すことを意味します。
これらのタスクの一部を自動化して、バグを見つける可能性を高め、コードがリグレッションを起こして以前に修正されたバグが再びポップアップするのを防ぐ方法はいくつかあります。まだ使用していない場合は、コンパイラの警告、コードの静的分析、テスト駆動開発、およびその他の自動化された手法を調べる必要があります。これらは手動テストの優れた賛辞であり、多くの場合、実装するのに安価です。
私はあなたの特定の詳細の細かい点で少し迷いましたが、そこにいくつかの興味深い質問を見つけました：
テスト/デバッグ/ QAが最も単純なバグもキャッチできないと想定し、これらの単純なバグから保護するために追加の機能をコーディングする必要がある場合、開発プロセスにさらに深い問題があることを示しているのではないですか？
単純なバグについては知りませんが、確かに私の一部のバグは、単体テスト、統合テスト、およびQAのレーダーのもとで飛ぶことがあり、残念ながら、時には内部テストさえあります（これがそれほど頻繁に発生しないことを願っています） NASAで）。
私の場合、それに対する最も価値のある保護手段はロギングです。ユーザーのマシンでデバッガーを実行できると期待するのは現実的ではないため、残念ながら出荷できたバグを絞り込むための唯一の目的を除いて、実際には機能としてロギングはまったく必要ありません。私たちのテスト手順はかなり厳しいですが、ロガーは特に、SIMDとGPUシェーダーでいくつかの素晴らしい最先端のものを実行するため、チーム全体で誰も再現できない方法で発生することがあるハードウェアの非互換性の問題を絞り込むのに役立ちます。 （これは、出荷できたバグが最も多い場所でもある傾向がありますが、ユーザーがハードウェアの最小要件を読んでいないことが原因である場合もありますが、少なくともソフトウェアでそれが正しく検出されていないことがわかりました）。
さらに、バグから保護するために追加機能をコーディングする必要がある場合、それらの追加機能にバグがある場合はどうなりますか？バグから保護する機能で起こりうるバグから保護するために、さらに多くの追加機能をプログラムしますか？
例としてロギングに戻ると、それは最後の手段です。どういうわけか、私たちのロギングも（ある程度テストはしますが）機能していなければ、SOLのような場合です。絞り込むためだけに、固定ロギングを使用してビルドを送信する必要があるかもしれません）しかし、最後の防御の要塞として、それはかなりうまく持ちこたえています。とはいえ、実際にそれを利用して、ある程度テストしています。また、時々それを見て、すべてのプログラムがデバッグ以外の方法で何をしたかを確認します。
現在、最後の手段としての防御は、バグを隠すこととは異なります。私はこのような恐ろしいコードを見てきました：
// Pre-condition foo should never be null:
void do_something(Foo* foo)
{
if (!foo)
return;
...
}
エラーが発生していないことを考えると、これは絶対に恐ろしいことです。残念なことに、私が若い頃のチームの年齢で働いていたとき、シニア開発者はこれが良い習慣だと思っていました。彼らは、バグを修正するプログラマーが2つの新しいバグを「修正」した方法で現実のものに変えるという神話的な考えを作りました。バグ。しかし、それはロギングのようなものとは大きく異なります。彼らがやっていたことは、意図的にバグを修正するのではなく、隠すことでした。私は時々、そのチームにいる経験のせいにするという不快で議論の余地のある側面を持っています。 :-D
あなたの場合、私はあなたの上司の議論がこれらのオブジェクトをオフ/無効にするための安全機能を持っていることがどれほど愚かであるか（またはそうでないか）を判断するためのニュアンスと詳細を知りません。しかし、それはお金を稼ぎ、ビジネスを運営することであり、これがあなたにとって本当の生産性の問題を引き起こしているのであれば、「正確さ」や「最適な実践」の観点から取り組むのではなく、そのように話すことを忘れないでください「上司はそれにもっと関係があると思うからです。しかし、あなたが知っている、とても素晴らしいまたはかっこいい男（女性のための私のような）であるかわいい女の子のような人生にはたくさんのものがあります、そして私は何年にもわたって争われるかもしれないもののために少し冷やすことが役立つと思いましたそれが本当に、本当にあなたの仕事を成し遂げるのを邪魔しない限り。
あなたの特定の問題を正確に理解しているかどうかはわかりませんが、一般的なテーマ自体は非常に一般的であり、いくつかの側面があります。
要件
明確で、文書化され、合意された目標がなければ、どのシステムの機能も手に入れることができます。要件がない場合、システムがより上級のスタッフとどのように連携するかについて、意見の相違が多くある可能性があります。それがコードベースの利益のためであるかどうかにかかわらず、彼らの見解を押し進める立場。
プロセススパイラル
手動プロセスがうまくいかない場合、簡単な反応は、まだ別のプロセスを追加して、最初のプロセスをチェックすることです。これは愚かな用事です。問題が発生する可能性が2つあり、チェックと対策の増加によりプロセス全体に時間がかかるためです。
これは、重要な機能でこれが決して起こらないと言っているわけではありませんが、どこにでも展開できる特効薬と見なすべきではありません。
ビジネスプロセス
（特に管理において）ソフトウェアはただ流れ、エラーを示さず、ユーザーを助け、直感的であるべきであるという概念があります。これらの非現実的な要求は、要件自体に直交する場合があります。これらの高尚な願望がチェックされないままでなければ、ここで多くの開発時間を費やすことができます。
あなたがどこにいるかを考えると、私は文書化された要件がいくらか欠けていると思いますが、それでこれから始めることを止めるべきではありません。ソフトウェアの変更を完全に文書化して正当化する権限を求めると、多くの新しい重要な機能が途中で失敗することに驚かれることでしょう。多くのマネージャー（ソフトウェアに関して）は、開発者だけでなくコードベースも理解していないため、多くの時間を費やしています。