メモリ リークなど、誤ってプログラムに簡単に組み込まれてしまうさまざまな悪い慣行があります。場合によっては、彼らはあなたのプログラムを一緒に仮組みすることさえできるかもしれません.
私は現在プロジェクトに取り組んでおり、コードに故意にメモリリークを入れればうまくいきます。リークを取り除くと、コードがクラッシュします。明らかにこれは悪いことであり、すぐに修正する必要があります (そして修正される予定です)。
私の質問は、これらの不適切な慣行なしでは時間内にコードをリリースできない場合、いつこの状態でコードを配信することを決定するのですか?
システムの実際の使用に対する問題の影響がゼロまたはごくわずかであると合理的に予想でき、納期を遅らせることができず、問題の影響が無視できない程度になる前に一定の期間内に修正できる場合は、出荷します。 .
明らかに、これは理想的ではなく、推奨されるものでもありませんが、この時点で明らかに窮地に追い込まれています。良い選択がない場合もありますが、プラグマティズムは正式な正しさよりも勝たなければなりません。アプリケーションにメモリ リークがあっても、リークが実際の問題になる前に、アプリがリサイクルされたり、マシンが再起動されたりすることが合理的に期待できる場合は、配信が遅れるよりはましな場合があります。契約条件やお客様により異なります。
少なくとも配達日を遅らせようとすることは常に良いことですが、すでにそれを試したことがあると思います。ここではオプションではありません.
アプリケーションが出荷されたら、技術的負債を無視して先に進むのが一般的です。特にこのような場合、その負債の一部を返済することの重要性を利害関係者に明確に伝えることは、開発者の責任です。
ただし、顧客が正確さよりも納期を気にしているように見えることを考えると、ライブになったら借金を返済することを誰もが納得する可能性は低い. これは悪い状況です。すべての事実を知っている人だけが正しい選択をすることができます。
「私の質問は、これらの不適切な慣行なしにコードをリリースすることができない場合、いつこの状態でコードを配信することを決定するのですか?」
一度もない。
代わりに行うこと: 優先順位を付けて集中します。
あなたが取り組んでいることの優先度が非常に高く、その設計を誤った場合、優先度の低い何かを犠牲にする必要があります。多くの場合、動作しない優先度の高い機能に集中する時間を確保するために、一部の機能を遅らせる必要があります。
あなたが取り組んでいることの優先度が本当に低い場合は、優先度の高いことに取り組んでいない理由を尋ねる必要があります。そして、集中して優先順位を付ける必要があります。優先度が非常に低いものを犠牲にしなければならない場合があります。
「すべて」を行うことができない場合は、合理的にバグのない、できることを選択する必要があります。
ソフトウェアを出荷するときに回すことができるノブは 3 つだけです。開発者の数が固定されていると仮定すると、機能、品質、出荷日です。
ソフトウェア開発で最も難しいことの 1 つは、ノブを適切に設定して製品を構築することです。たとえば、Duke Nukem Forever の連中は、機能と品質のノブを 11 まで上げ、出荷日のノブを窓の外に放り出しました。マイクロソフトは、出荷日のノブを所定の位置に接着し、必要に応じて機能のノブを下げてから、出荷日のノブの接着を外し、少し上げて、接着して元に戻し、他の 2 つをいじり続けるようです。また、常に出荷されているにもかかわらず、成功するために必要な機能が組み込まれていない製品が無数にあるようです。
結局、配達しないとお金はもらえません。品質が悪いと、長期的にはひどく傷つきます。評判を再構築するのは難しいです。ほとんどの場合、バグが多すぎる場合は機能を削減するのが正しいとされてきました。いつも。
ただし、バグのトリアージは機能開発と同じくらい重要です。ここで話しているのはどのようなリークですか？あなたはバイトを漏らしていますか？小さな物体？千のオブジェクト？DLL 全体? 製品の提供に失敗するよりも、少し漏れた方がおそらく良いシナリオがあります.
そして、あなたはリークとはどういう意味ですか？アプリケーションのライフサイクルは明確に定義されていますか? 起動時に一度何かを割り当て、プロセスが終了するまで解放しない場所はどこですか? さて、あなたのプロセスはどのくらい実行されますか? プロセスの複数のコピーを実行する予定ですか?
当然のことながら、リークを最小限に抑えるためのベスト プラクティスの開発に取り組む必要がありますが、最終的には判断を下す必要があります。おそらく、顧客にバグを説明し、その影響を説明するだけで、顧客は購入するでしょう。たぶん、1週間後にパッチを当てることができます。たぶん、あなたは本当にそれを修正する必要があります。しかし、良いアドバイスをするためには、それについてもっと知る必要があります.
私は過去に既知のリークを出荷したと言います. どの製品や会社かは言いませんが、DLL の依存関係と常軌を逸したライフタイム管理により、特定の DLL への参照を一度ロードすると正しく解放することがほとんど不可能になるというバグがありました。そして、それは正しいことだったと今でも思っています。また、誤って記述されたサードパーティのコードがクラッシュしないようにするために、故意にリークされたものを見たこともあります (ただし、それは完全に別の議論です)。
しかし、結局のところ、そのような事例はまれであり、メモリ リークの原因を突き止めれば、それを修正するのに 1 日以上かかることはないと思います。既知のメモリ リークがあり、修正が既知である状態で出荷することは、実際にはほとんどありません。スレッド モデルの変更や大量のコードのリファクタリングを含む大規模な再設計が必要であり、製品の出荷までに文字通り 1 日か 2 日かかる必要がありました。その時点で、私はメモリをリークして、再設計者で適切なテストが行われた後に脆弱なパッチを約束するかもしれません.
技術的負債の概念に興味があるかもしれません。
おそらく、後でコードを保守するつもりがない場合、クライアント/雇用主のことは気にせず、コードの影響があなたに影響を与える可能性はありません.
言い換えれば、あなたのプロのコーディング生活では、それは決して良い考えではありません.
あなたほどコードの品質に関心がなく、何としてもコードを完成させたいと思っている人の下で働いているなら、あなたがいかに困難な状況に陥るかは理解できます。より速く、より貧弱に終了すると、すぐに報酬が得られます。ただし、マイルストーンに対する雇用主/クライアントの期待に応えられなかったことが一度だけでも、あなたの貧弱なコードは、それを維持することの難しさだけでなく、他の人からの否定的な印象を通じて、将来にわたってあなたを噛み締め続ける可能性があることを覚えておく必要があります。トラックの下であなたの形になるかもしれません。
このような既知のバグでリリースするのは非常に不快です。別の方法で発生する可能性があります。
環境や言語を指定していませんが、次のようなメモリ チェック ツールの使用を検討することをお勧めします。
浄化（試用可能）
または無料のもの、Visual Leak Detector
最終的に、このような決定は、顧客またはプロジェクトマネージャーが行う必要があります。個々の開発者は、この種の決定を単独で行ったり、この情報を自分自身に保持したりするべきではありません。
問題が何であるか、そしてそれを修正しないとどうなるかを彼らに伝えてください。彼らがあなたにそれを時間通りに壊れて出荷することを望むなら、それは彼らの呼びかけです。
粗雑な製品を受け入れる人々のために働きたくないのであれば、それはあなたの呼びかけですが、開発者がクライアントと上司の品質/コスト/時間の優先順位を無視する何らかの専門的責任があると考えるのは間違いです。
悪いソフトウェアを出荷した場合に誰かが実際に死ぬ可能性がある場合は、それを行わないでください。ただし、最悪のシナリオでは、誰かが1日に数回再起動する必要がある場合は、言われたことを実行するか、別のソフトウェアを見つけてください。仕事。
後であなたの仕事を維持しようとしている貧しい開発者を気にしない限り、絶対にしないでください。
単一の (または限定的な) メモリ リークであり、それが大きくならず、シャットダウン時にのみクラッシュを引き起こすと言う場合 (このようなものの最も一般的なケース)、状況によって異なります。それがクライアント/デスクトップ ソフトウェアであり、ユーザーが外出するたびにクラッシュする場合、私はそれを非常に優先度の高いものにします。そのサーバーと、サーバーを実行しているのはあなただけで、他のすべてが正常に機能している場合は、ベータ版に入っても問題ないと思います. しかし、リークが拡大したり、「ランダムな」時間にクラッシュを引き起こす可能性がある場合は、できるだけ早く修正する必要があります.
社内のマイルストーンを乗り越えるためには議論の余地がありますが、まだ可能性が高いものは何もありません.
リリースすることはありません。それはいつも戻ってきてあなたを噛みます。あなたのソフトウェアがあまりにも劣悪な場所にあり、デザインの一部がうまくいかない場合は、はるかに大きな問題がすぐそこに迫っています.