プログラム内のゾンビコードを削除する-php手册-php.cn

ハロウィーンの人気がますます高まる中、ソフトウェア開発における非常に一般的な問題であるゾンビコードについて説明したいと思います。誰もが触れるほぼすべてのコードベースには、多数の小さなセクション、またはコメントアウトされたコードの大きな領域が散在しています。これはゾンビコードです。

//この機能は現在無効になっています。ジミーはこのコードを書いたとき酔っていたに違いありません。

// ここで恐ろしいコード殺人が起こっていると思うかもしれません...いいえ、いいえ、コメントアウトしただけです...

なぜゾンビコードと呼ばれるのですか?ご存知のように、ゾンビは実際には死んでいません。映画でわかると思いますが、ゾンビは死んでいるように見えても、まだ出てきて私たちを攻撃する能力を持っています。同様に、ゾンビのコードも生と死の境にあり、私たちの仕事を台無しにする機会を待っています。コメントアウトされたコードはまだ生きており、コードベースに存在します。プログラマーはコードの保守やリファクタリング中にこれらに遭遇し、多くの場合、スクロール中にこれらを通過したり、キーワード検索を実行中に遭遇したりします。しかし、これらのコードはソフトウェア製品内で実行されないため、実際には機能しません。したがって、これらのゾンビはすぐに燃やされる必要があります。

ゾンビコードイモータル

ゾンビコードが蔓延している理由は 2 つあると思います。それは怠惰とリスクへの恐怖です。怠惰なプログラマーはコードを収集する傾向があります。彼らは役に立たないコードを削除する勇気と明晰さに欠けているため、いつか戻ってきて人々を悩ませることを期待して、コメントにコードを隠します。優れたプログラマーはコードが負債であることを知っているため、コードは頻繁かつ体系的に削除する必要があります。少ないほど良いです。もちろん、コメントアウトされたコードもコードです。

悪いプログラマーは、後で誰かが必要とする場合に備えてコードをコメントアウトしていると主張するかもしれません。実際、この善意は実際にすべての人を傷つけました。これが実際に意味するのは、リスクに対する恐怖心と、バージョン管理システムの役割に対する信頼の欠如です。バージョン管理システムが導入されていれば、削除されたコードが完全に死んだ状態になることはありません。彼らは棺に埋葬されていますが、生きています。したがって、コードをコメント化する方法は実際的な効果はほとんどありません。

プログラムの場合、コメントアウトされたコードは削除されたコードと同じであり、効果はありません。コードが半分死んだままゾンビの形で存在すると、最終的にチームに損害を与える技術的負債が生じます。思い切って削除してください。

ゾンビコードにより S/N 比が低下します

プログラムを書くときは、コード内の有効な情報の割合をできるだけ高くするように努めなければなりません。これにより、人々がプログラムを理解し、コードをより速く読むことができ、誤解によって問題のあるコードを作成するのを防ぐことができます。ゾンビコードはコードの理解度と直接対決します。画面上に表示される有効なコードが少なくなるため、コードの読み取りと保守が遅くなります。これらは、人々の通常の読書を妨げる視覚的なノイズです。何らかの理由で、一部のプログラマーはこの妥協案を受け入れるでしょうが、実際のところ、この厄介な状況を誰が受け入れるでしょうか。ニューヨーク・タイムズが次のようだったらと想像してみてください:

この断続的なテキストをどう読むか?ノイズの増加は明瞭度に悪影響を及ぼします。これらのコメントアウトされた部分は無関係で誤解を招きますが、無視することはできません。これは最終リリース製品ではなく、これらのコードは開発プロセスに存在し、リリース製品と比較するのはリンゴとオレンジを比較するようなものだと言う人もいるでしょう。ただし、書かれたコードの各行は平均して 10 回読み取られることを覚えておいてください。確かに、あなたのコードはニューヨークタイムズほど多くの人に読まれていませんが、あなたが持っているのは最も重要な忠実な読書グループです。それが私たちです。クヌース氏はこの懸念を見事に次のように要約しました。

「プログラミングとは、ある人がコンピューターにやってほしいことを別の人に伝える技術です。」

ゾンビコードにより、あなたのスピーチは不明瞭になります。プログラマーはコメントアウトされたコードを読む必要がありますか?

ゾンビコードは曖昧さを生み出し、デバッグを妨げます

コメントアウトされたコードはあいまいさを生み出し、コードをコメントアウトする必要があるかどうか疑問を抱かせる可能性があります。あなたがプログラムを保守しているプログラマで、突然コメントアウトされたコードが表示され、その近くでプログラムに問題があると想像してください。プログラマーの仕事はますます難しくなります。コメントアウトされたコードを読んで理解し、コメント化の影響を理解する必要があります。テスト用にコードをコメントアウトして、元に戻すのを忘れていませんか?このコードにコメントを付けた人が役立つかもしれませんが、彼は誰でしょうか?調査が始まります。不必要なあいまいさは時間を浪費し、簡単なデバッグプロセスでの思考の負担を増大させます。

ゾンビコードはキーワード検索に影響します

大規模なライブラリでは、grep/find コマンドがコードの特定のスニペットをターゲットにするためのレーダーになります。ただし、ライブラリにゾンビコードが散在している場合は、キャプチャしたターゲットがコメントアウトされる可能性が高くなります。これは干渉です。時間の無駄。

ゾンビコードはコードリファクタリングに影響します

反省（再構築）は私たちの魂を修復することができます。私たちはキッズスカウトの行動原則を誇りに思い、コードを常にあなたが思っているよりもきれいに保つ必要があります。ただし、クラスまたはメソッドに大量のゾンビコードが含まれている場合、事態は難しくなります。このプログラムをリファクタリングした場合でも、コメントアウトされたコードを参照する必要がありますか?近い将来再利用されるのでしょうか？新しいバージョンの実装に影響しますか?これらの質問にメンテナンスプログラマが答える必要はありません。

さらに、統合リファクタリングツールは、このコメントアウトされたコードをまったく考慮しません。したがって、メソッド、変数、クラスの名前が変更されるか、修飾子が変更される場合、コメントアウトされたコードは同期的に変更されません。コメントアウトされたコードを復活させようとすると、まったくコンパイルされない可能性があります。

例外はありますか?

いいえ。非常に明確です。誰かが「後で復元するので、今注釈を付けています。」と言うかもしれません。OK、あなたが主婦で、リビングルームに入って次のようなものを見たとしましょう。

自分の内なる対話について考えてみましょう。美しい家だけど、この家は醜くて奇妙だ。ライトをつけたいのですが、なぜテープがあるのでしょうか？テープを剥がしてライトをつけるとどうなるでしょうか？おそらくテープを貼ってくれる人を探すことになるでしょう。「ああ、シーリングファンをつけようと思ったんですが、回すと前後に揺れて落ちてしまったので直したいのですが…」それは当然です。そして、テープは修理するまでスイッチに貼り付けられたままになります。こういった修理途中の物を家の中に放置すべきではありません。同様に、そのようなコードは受け入れられません。

より明確に言うと、コメントアウトされたコードはすべてゾンビコードであり、削除する必要があります。いくつあっても構いません。リリースされた製品でも開発環境でも。ゾンビのコードは生と死の間で揺れ動くことがあります。コードがコメントアウトされている場合は、何かが行われていない可能性が高くなります。多くの場合、構成を前後に切り替えたり、論理ブランチを左右に動かしたりする必要があります。コメント化されたコードを実験的に前後に切り替えたり、コードを削除したり、何を行う必要があるかを記録するメモを作成したりすることができます。コードが削除されたコミットを付箋にメモします。または、この目的専用に新しいバージョンブランチを作成し、マージ時にそれらを削除します。このようにして、メンテナンス作業が中断されることはありません。