デッドコードは取り除かなければならない

デッドコードは、見つけて、取り除く必要がある。デッドコードを残しておくと、プログラマの理解と行動を妨げることがあり、コードが実行されて、重大な問題を引き起こすリスクもある。 デッドコードの削除は、技術的な問題ではない。Kevlin Henney氏によると、それは考え方と文化の問題だ。

独立したコンサルタントでトレーナであるKevlin Henney氏が、ヨーロッパテストカンファレンス 2017において、基調講演「やり方の間違い」を行った。この基調講演で、デッドコードが実行されたために、ある企業が何億ドルもの損害を被ったことを発表した。 InfoQは、このカンファレンスをQ&A、要約、記事で扱う。

ソフトウェアの失敗は、個人的に不便だったり、迷惑だったりするが、経済的、または、社会的に重大な影響を与えることもある。Henney氏は、小さな不具合のせいで、何百万ドルもの損害を出した例をいくつか挙げた。

システムに存在しているが、もはや使われるはずのないコード、デッドコードが原因で失敗は起こり得る。 偶然、このコードが実行された時、システムを劇的に失敗させることがあるとHenney氏は言う。 だから、Henney氏は、このような失敗を防ぐために、デッドコードを取り除くことを勧める。

InfoQは、Kevlin Henney氏にインタビューして、デッドコードから起こり得る問題の扱い方を聞き、エラー条件と例外の扱い方についてアドバイスを求めた。

InfoQ: あなたは、デッドコードが、どのように1つの企業に大きな損失をもたらしたかについて話しました。 何が起きたのか説明してもらえますか?

Kevlin Henney氏: 2012年8月1日の朝、New York証券取引所の取引が開始された時、Knight Capital Groupの新しく更新した高速アルゴリズムルータが、多量の売買でマーケットをあふれさせるオーダーを誤って発生させました。 45分間、4億株を扱った後、やっとシステムをオフラインにできました。 騒ぎが収まった時、実際に、1分毎に1千万ドル以上も失っていました。

倒産を決定的にしたこの出来事は、最悪の事態から発生しました。 8月1日に開始される、新しいNYSEシステムを見込んで、サーバにアップデートをデプロイしました。 手動でサーバを更新しましたが、サーバへのデプロイが1つ失敗し、古いバージョンが動いていることに気付きませんでした。 新しいNYSEシステムを利用するために、古いフラグを再利用しました。そのフラグは、もはや使われておらず、何か別のことに再利用されるようになったのです。 そのフラグは、8年間使われていませんでしたが、古いバージョンのコードは、まだその古いフラグに依存していました。

コードは、何年間も実行されない状態でしたが、フラグの値が変更されて、目覚めました。 ゾンビの啓示が届いて、その後、倒産しました。

InfoQ: この問題が起こらないようするために、何ができましたか?

Henney氏: 最悪の事態の中で、誰かが悪いと考えることもできますが、これは、明らかに不相応に悪いことが重なっていました。 一因となる要素をどれか変えることで、損害を防ぐか、少なくとも減らせたでしょう。

• サーバは手動で更新されました。これは、自動化が切に求められる仕事です。
• 更新に失敗したことに、誰も気付きませんでした。更新を見直した人がいなかったのです。 航空機のドアは手動でロックされますが、乗務員のクロスチェックによって安全性を高めています。
• デッドコードは葬られるまでは、本当に死んでいません。 不必要なコードは、何年も前に取り除くべきでした。
• 新しいフラグやレコードを追加せずに、再利用することは、時には非常に実用的な理由ですが、リサイクルせずに追加できるならば、追加した方がよいでしょう。
• 欠陥のある取引システムを扱うために、企業の中で段階的に拡大するプロセスはありません。 失敗の正確な本質を予想するのは難しいものですが、高速取引システムを持つ理由が、人間よりも速くすることならば、人間がお金を失う可能性もあることは明らかでしょう。 高速システムは、このような能力を倍にします。 明確な段階的拡大プロセスを持ち、問題が起きた時にラインを止める文化を持っていれば、もっとよかったでしょう。
• この45分間で、問題の原因を理解せず、実際に更新をロールバックして、うまくいきました。 これは、問題を解決したのではなく、妥協したのです。 誰も知らない理由で間違った方向へ行ったライブシステムの収拾がつかなくなったためのパニック反応だったのでしょうか? そのようにすべきではありません。
• 自動化インストールがなかったように、システムをオフラインにする簡単な方法もありませんでした。 「更新」と「緊急停止」を自動化しましょう。

InfoQ: デッドコードを扱うことについて、何か提案はありますか?

Henney氏: 見つけて、 削除する。

デッドコードを見つけるのは、難しい部分です。 デッドコードは、時々、正真正銘、到達できないところにあります。静的分析がそのことを示します。 しかし、静的分析の有効性は、ツール、言語、そして、アーキテクチャによりますが、これはよいスタートです。

インサイダ取引は、証券取引では違法操作とみなされますが、コードベースで内部知識を利用することは、完全に受け入れられます。 開発者たちは、コードが要求以上のものであることについて、すでに良い考えを持っているかもしれません。 同じく、製品機能の知識を利用しましょう。機能が利用されなくなったか、要求レベルで不要になった時に、これらの機能に関連するコードは、引退すべきかもしれません。

もう1つ使える手掛かりは、コードの安定性です。 バージョンコントロールシステムは、変更の知識データベースです。 変更されたことのないコードベースはどの部分ですか? コードが安定している理由はいろいろあります。正しいコードだからか、実行されないコードだからです。それとも、ただ怖くて触れないのかもしれません。あなたが調べなければ、その理由を知ることはできません。 もちろん、自動リファクタリングの結果、デッドコードが変更されることもありますが、そのような変更は特徴があります。他のリファクタリングの変更と関係していて、不具合の修正や機能追加の変更ではありません。

システムのランタイムモニタリングは、どの部分が実行されないのかを最終的に教えてくれるものではありませんが、どの部分が最終的に動いているかを教えてくれます。 これにより調査を絞ることができます。

簡単に言えば、仮説を展開して、調査しましょう。

デッドコードを削除するのは、技術的な問題ではありません。考え方や文化の問題です。 コードが何もしていないならば、何も影響しないので、そのままにしておいてよいと感じることがあります。 まったく同じ理由で、そのコードを取り除いてもかまいません。何もしていないならば取り除くことを覚えておく価値はあります。 取り除いたことは、バージョンコントロールシステムに記録しておけばよいのです。

デッドコードを取り除くにはいろいろな理由があります。ゾンビの啓示の可能性だけではありません。 デッドコードは、必要とされるよりも、ランタイムのフットプリントを大きくします。 パフォーマンスが気になるならば、パフォーマンスに注意しましょう。 デッドコードは、プログラマの理解と行動を妨げます。システムをデッドコードの塊にすると、開発者の時間を無駄にし、ソフトウェアをソフトとして扱う文化に水を差します。そのため、いつでも見直して、改善できるようにしましょう。

コードが実行されないかどうか確信が持てず、そのコードを削除したくないならば、その時は、その不確かさが、アーキテクチャと開発者の関係を大いに語っています。

InfoQ: 実行されない訳ではありませんが、無視されて、ほとんど実行されないまま残されるコード、エラーハンドリングコードの問題についても話します。 致命的でないエラーを間違った方法で扱った場合に、どのように破滅的な失敗になりますか?

Henney氏: コードは使われれば使われるほど、不具合が見つかって、修正されます。 エラーハンドリングコードは、システムの中で、最も調べられることがないコードです。 多くのエラーケースは、めったにないケースで、コードはそれらのエラーケースを扱うために存在していますが、コードの正確性は証明されていません。 そして、めったにない条件になり、制御しようとすると、壊れたパスに流れ込みます。コードは新しいものを作成せずに、エラー条件を扱うべきですが、そのまま失敗します。 時には、まったく文字通りに、1996年の最初のAriane 5ロケットは失われました。

InfoQ: エラー条件と例外を扱うためのアドバイスはありますか?

Henney氏: レビュー、静的分析と自動テストです。 全体を通して見て、話すことは、見落としを明らかにし、新しい疑問と気付きを生み出す助けになります。 言語によっては、ランタイムで起こり得ることについて、ツールから役に立つフィードバックを得られるでしょう。

テストは、安全な環境でコードが実行されることを確認する1つの方法です。ただし、エラーハンドリングコードが関係する部分について、人は見落とすことがあり、楽観的な偏見を持ちます。テストは幸せな日のシナリオに過ぎません。 このことを扱うために、いつも以下の点を確認しましょう。 エラー条件の合図があった時に、関連するハンドリングコードはどこにありますか? エラー条件のためにテストはどこにありますか? そして、ハンドリングコードのテストはどこにありますか?