デッドコード：検索して武装解除する

私の名前はDanilMukhametzyanovで、Badooでバックエンド開発者として7年間働いています。この間、私はなんとか大量のコードを作成して変更することができました。ある日、マネージャーが私のところにやって来て、こう言いました。何かを追加するには、何かを削除する必要があります。」



さて、それは単なる冗談です-彼はそれを言わなかった。それは残念だ！ Badooは、会社の存続期間全体にわたって、空白行と閉じ括弧を除いて、550万行を超える論理ビジネスコードを蓄積してきました。



量自体はそれほど怖いものではありません。彼は嘘をつき、食べ物を求めません。しかし、2、3年前、私はますます読んで、実稼働環境では実際には機能しないコードを見つけようとしていることに気づき始めました。つまり、実際には死んでいます。



この傾向は私だけでなく気づきました。Badooは、高給のエンジニアが常にデッドコードに時間を浪費していることに気づきました。







Badoo PHP Meetup＃4でこの講演をしました

デッドコードはどこから来たのですか？

私たちは問題の原因を探し始めました。それらを2つのカテゴリに分けました。

• プロセス-開発の結果として生じるもの。
• 履歴-レガシーコード。

まず、新たな問題の発生を防ぐために、プロセスソースを分解することにしました。

A / Bテスト

Badooは4年前にA / Bテストを積極的に使用し始めました。現在、約200のテストが常に実行されており、すべての製品機能がこの手順を実行します。



その結果、4年間で約2000件の完了したテストが蓄積され、この数字は絶えず増加しています。彼女は、各テストがもはや実行されておらず、まったく必要とされていない死んだコードの一部であることを私たちに怖がらせました。



この問題の解決策はすぐに現れました。A/ Bテストが完了した後、コードをカットするためのチケットを自動的に作成し始めました。





チケットの例



しかし、人的要因が定期的にトリガーされました。何度も何度も実行され続けるテストコードを見つけましたが、誰もそれについて考えずにテストを完了しました。



次に、厳格なフレームワークがありました。各テストには終了日が必要です。マネージャーがテスト結果を読むのを忘れた場合、マネージャーは自動的に停止してオフにします。そして、すでに述べたように、機能のロジックの元のバージョンを維持しながら、チケットを切り取るためのチケットが自動的に作成されました。



このような単純なメカニズムの助けを借りて、私たちは作業の大きな層を取り除きました。

クライアントの多様性

当社ではいくつかのブランドがサポートされていますが、サーバーは1つです。各ブランドは、Web、iOS、Androidの3つのプラットフォームで表されます。 iOSとAndroidでは、毎週の開発サイクルがあります。週に1回、更新とともに、各プラットフォームでアプリケーションの新しいバージョンを受け取ります。



このアプローチでは、1か月でサポートが必要な新しいバージョンが約12個あることは容易に推測できます。ユーザートラフィックはそれらの間で不均一に分散されます。ユーザーはあるバージョンから別のバージョンに徐々に切り替えています。一部の古いバージョンにはトラフィックがありますが、非常に小さいため、保守が困難です。それは難しくて役に立たない。

そこで、サポートしたいバージョンの数を数え始めました。クライアントには、ソフト制限とハード制限の2つの制限があります。



ソフト制限に達すると（3つまたは4つの新しいバージョンがすでにリリースされていて、アプリケーションがまだ更新されていない場合）、ユーザーにはバージョンが古くなっていることを警告する画面が表示されます。ハード制限に達すると（アプリケーションとブランドに応じて、これは約10〜20の「欠落した」バージョンです）、この画面をスキップするオプションを削除するだけです。それはブロッキングになります：それでアプリケーションを使用することはできません。





ハード制限の画面



この場合、クライアントからの要求を処理し続けることは無意味です。クライアントには画面しか表示されません。



しかし、ここでは、A / Bテストの場合と同様に、ニュアンスが生じました。クライアント開発者も人です。彼らは新しいテクノロジー、オペレーティングシステムのチップを使用します-そしてしばらくすると、アプリケーションバージョンはオペレーティングシステムの次のバージョンでサポートされなくなります。ただし、サーバーはこれらの要求を処理し続ける必要があるため、引き続き問題が発生します。



Windows Phoneのサポートが終了した場合の別の解決策を考え出しました。ユーザーに次のような画面を用意しました。あなたはとてもかっこいいです！しかし、別のプラットフォームを使い始めることはできますか？新しいクールな機能が利用できるようになりますが、ここでは何もできません。」原則として、代替プラットフォームとして常に利用可能なWebプラットフォームを提供しています。



このような単純なメカニズムにより、サーバーがサポートするクライアントバージョンの数を制限しました。すべてのブランド、すべてのプラットフォームからの約100の異なるバージョンです。

機能フラグ

ただし、古いプラットフォームのサポートを無効にすることで、使用しているコードを完全に削除できるかどうかを完全に理解できませんでした。または、古いOSバージョン用に残っているプラ​​ットフォームは、引き続き同じ機能を使用しますか？



問題は、APIがバージョン管理された部分ではなく、機能フラグの使用に基づいて構築されていることです。どうやってこれにたどり着いたのか、このレポートから知ることができます。



2種類の機能フラグがありました。それらについて例を挙げて説明します。

マイナーな機能

クライアントはサーバーにこう言います。「こんにちは、私です。写真投稿をサポートします。」サーバーはそれを見て、次のように応答します。今、私はそれについて知っていて、あなたに写真メッセージを送ります。」ここでの重要な機能は、サーバーがクライアントに影響を与えることはできないということです。サーバーからのメッセージを受け入れるだけで、サーバーを強制的にリッスンします。



これらのフラグをマイナー機能と呼びます。現在、600を超えています

が、これらのフラグを使用することのデメリットは何ですか？定期的に、クライアント側だけではカバーできない重い機能があります。サーバー側からも制御する必要があります。このために、他のタイプのフラグを導入しました。

アプリケーションの機能

同じクライアント、同じサーバー。クライアントは次のように述べています。「サーバー、ビデオストリーミングをサポートすることを学びました。それをオン？ "サーバーは、「ありがとう、それを覚えておきます」と応答します。そして彼は次のように付け加えています。私たちの最愛のユーザーにこの機能を見せましょう、彼は喜ぶでしょう。」または：「わかりました。ただし、まだ含めません。」



これらの機能をアプリケーション機能と呼びます。それらは重いので、数は少なくなりますが、それでも十分です。300を超えます。



したがって、ユーザーはクライアントのあるバージョンから別のバージョンに移動します。ある種のフラグが、すべてのアクティブなバージョンのアプリケーションでサポートされ始めています。または、逆に、サポートされていません。これを制御する方法は完全には明確ではありません：100クライアントバージョン、900フラグ！これに対処するために、ダッシュボードを作成しました。



赤い四角は、このプラットフォームのすべてのバージョンがこの機能をサポートしていないことを意味します。緑-このプラットフォームのすべてのバージョンがこのフラグをサポートしています。フラグのオンとオフを切り替えることができる場合は、定期的に点滅します。どのバージョンで何が起こるかを見ることができます。





ダッシュボード画面



このインターフェイスで、機能を切り取るためのタスクの作成を開始しました。各行のすべての赤または緑のセルに入力する必要はないことに注意してください。 1つのプラットフォームでのみ実行されるフラグがあります。 1つのブランドについてのみ記入されるフラグがあります。



プロセスの自動化はそれほど便利ではありませんが、原則として必要ありません。タスクを設定し、ダッシュボードを定期的に確認するだけです。最初の反復では、200を超えるフラグを切り取ることができました。これは、私たちが使用したフラグのほぼ4分の1です。



ここでプロセスソースが終了しました。それらは私たちの開発フローの結果として現れ、私たちはそれらとの作業をこのプロセスにうまく統合しました。

レガシーコードをどうするか

プロセスソースでの新しい問題の発生を停止しました。そして、私たちは難しい質問に直面しました：何年にもわたって蓄積されたレガシーコードをどうするか？エンジニアリングの観点からソリューションにアプローチしました。つまり、すべてを自動化することにしました。しかし、使用されていないコードを見つける方法は明確ではありませんでした。彼は居心地の良い小さな世界に隠れました。彼は決して呼ばれず、誰にも自分のことを知らせません。



私たちは反対側から行かなければなりませんでした：私たちが持っていたすべてのコードを取り、どの部分が正確に実行されたかについての情報を収集し、次に反転を行います。



次に、それをまとめて、最小限のレベルで、つまりファイルに実装しました。このようにして、適切なUNIXコマンドを実行することにより、リポジトリからファイルのリストを簡単に取得できます。



本番環境で使用されるファイルのリストを収集することは残っていました。非常に簡単です。シャットダウン時のリクエストごとに、対応するPHP関数を呼び出します。ここで行った唯一の最適化は、すべてのリクエストをリクエストするのではなく、OPCacheのリクエストを開始することです。そうしないと、データ量が非常に多くなります。



その結果、多くの興味深いアーティファクトを発見しました。しかし、より深く分析したところ、未使用のメソッドが欠落していることがわかりました。それらの数の違いは3〜7倍でした。



1つの定数またはメソッドのペアだけのために、ファイルをロード、実行、コンパイルできることが判明しました。この底なしの海に横たわるのに他のすべては役に立たないままでした。

メソッドのリストをまとめる

しかし、メソッドの完全なリストを収集するのに十分な速さで判明しました。私達はちょうど取ったニキータポポフのパーサを、彼に私たちのリポジトリを与え、我々は、コードを持っているすべてのものを得ました。



問題は残っています：プロダクションでプレイされているものをどのように組み立てるのですか？テストは私たちがまったく必要としないものをカバーできるので、私たちは生産に興味を持っています。二度と考えずに、XHProfを採用しました。クエリの一部についてはすでに本番環境で実行されているため、データベースに保存されているプロファイルサンプルがあります。これらのデータベースにアクセスし、生成されたスナップショットを解析して、ファイルのリストを取得するだけで十分でした。

XHProfのデメリット

XHProfが起動しなかったが、非常に必要だった別のクラスターでこのプロセスを繰り返しました。これは、バックグラウンドスクリプトと非同期処理を実行するためのクラスターであり、高負荷にとって重要であり、多くのロジックを実行します。



そして、XHProfが私たちにとって不便であることを確認しました。

• PHPコードを変更する必要があります。トレース開始コードを挿入し、トレースを終了し、収集したデータを取得して、ファイルに書き込む必要があります。結局のところ、これはプロファイラーですが、プロダクションがあります。つまり、リクエストがたくさんあるので、サンプリングについても考慮する必要があります。私たちの場合、これは、異なるエントリポイントを持つ多数のクラスターによって悪化しました。
• . . , OPCache. : XHProf, . , core- .
• . . XHProf . ( XHProf): CPU, , . , , . - XHProf aggregator ( XHProf Live Profiler, open-source) , , , . , : «, , », CPU , , Live Profiler . , , .
• XHProf. , . . , . : , ( , youROCK、これはlsdでは必要ありませんが、単一のラッパーを維持する方が便利でした）。XHProfにパッチを適用することは、かなり大きなプロファイラーであるため、私たちがやりたかったことではありません（不注意で何かを壊した場合はどうなりますか？）。

別のアイデアがありました。たとえば、本番環境で実行されるベンダー名義などの特定の名前名をコンポーザーから除外するのは、役に立たないためです。ベンダーパッケージをリファクタリングしたり、不要なコードを削除したりすることはありません。

ソリューション要件

私たちは再び集まり、どのような解決策が存在するかを調べました。そして、彼らは要件の最終リストを作成しました。



まず、最小限のオーバーヘッド。私たちにとって、XHProfはバーでした：それが必要とする以上のものではありません。



次に、 PHPコードを変更したくありませんでした。



第三に、 FPMとCLIの両方でソリューションがどこでも機能することを望んでいました。



第四に、フォークを扱いたかった。これらは、CLIのクラウドサーバーで積極的に使用されています。 PHP内でそれらの特定のロジックを作成したくありませんでした。



5番目：箱から出してサンプリングします。実際、これはPHPコードを変更しないという要件に基づいています。以下に、サンプリングが必要な理由を説明します。



6番目で最後：コードから強制する機能。すべてが自動的に機能する場合は気に入っていますが、手動で開始、調整、確認する方が便利な場合もあります。設定を通じて含まれる確率を設定するPHPモジュールのより一般的なメカニズムをランダムに決定するのではなく、コードから直接すべてを有効または無効にする機能が必要でした。

funcmapのしくみ

その結果、funcmapと呼ばれるソリューションが得られました。



Funcmapは本質的にPHP拡張です。 PHPの用語では、これはPHPモジュールです。それがどのように機能するかを理解するために、PHPプロセスとPHPモジュールがどのように機能するかを見てみましょう。



したがって、プロセスを開始します。 PHPを使用すると、モジュールを構築するときにフックをサブスクライブできます。プロセスが開始され、GINIT（Global Init）フックが起動されます。ここで、グローバルパラメーターを初期化できます。次に、モジュールが初期化されます。定数はそこで作成して割り当てることができますが、特定のモジュールに対してのみであり、要求に対しては割り当てられません。そうでない場合は、足を踏み入れてしまいます。



次に、ユーザーリクエストが届き、RINIT（Request Init）フックが呼び出されます。要求が完了すると、そのシャットダウンが発生し、最後にモジュールのシャットダウンが発生します：MSHUTDOWNおよびGSHUTDOWN。すべてが論理的です。



FPMについて話している場合、各ユーザー要求は既存のワーカーに送信されます。基本的に、RINITとRSHUTDOWNは、FPMがワーカーが古くなっていると判断するまで、円を描くように機能します。今度は、ワーカーを撃って新しいワーカーを作成します。 CLIについて話している場合、それは単なる線形プロセスです。すべてが一度呼び出されます。





funcmapのしくみ



このセットのうち、2つのフックに興味がありました。 1つ目はRINITです。データ収集フラグの設定を開始しました。これは、データをサンプリングするために呼び出された一種のランダムです。それが機能した場合は、このリクエストを処理しました。関数の呼び出しとそのメソッドの統計を収集しました。それが機能しなかった場合、リクエストは処理されませんでした。



次に、ハッシュテーブルが存在しない場合は作成します。ハッシュテーブルは、PHP自体によって内部的に提供されます。ここで何かを発明する必要はありません-それを持って使ってください。



次に、タイマーを初期化します。以下で彼について話しますが、今のところ、彼は重要で必要であることを忘れないでください。



2番目のフックはMSHUTDOWNです..。RSHUTDOWNではなくMSHUTDOWNであることに注意してください。私たちはリクエストごとに何かを考えたくありませんでした-私たちは労働者全体に興味を持っていました。MSHUTDOWNで、ハッシュテーブルを取得し、それを調べてファイルを書き込みます（古き良きファイルよりも信頼性が高く、便利で、用途が広いものは何でしょうか？）。



ハッシュテーブルは、ユーザー定義関数が呼び出されるたびに呼び出される同じPHPフックzend_execute_exによって非常に簡単に入力されます。レコードには、それがどのような種類の関数であるか、その名前とクラスを理解するための追加のパラメーターが含まれています。それを受け入れ、名前を読み取り、ハッシュテーブルに書き込んでから、デフォルトのフックを呼び出します。



このフックはインライン関数を書き込みません。組み込み関数をオーバーライドする場合は、zend_execute_internalと呼ばれる別個の機能があります。

構成

PHPコードを変更せずにこれを構成するにはどうすればよいですか？設定は非常に簡単です。

• 有効：有効かどうか。
• 書き込んでいるファイル。異なるPHPプロセスが同じファイルに同時に書き込む場合、競合条件を除外するためのpidプレースホルダーがあります。
• 確率ベース：確率フラグ。0に設定すると、リクエストは書き込まれません。100の場合、すべての要求がログに記録され、統計に含まれます。
• flush_interval。これは、すべてのデータをファイルにダンプする頻度です。CLIでデータ収集を実行したいのですが、長時間実行できるスクリプトがあり、大量の機能を使用するとメモリを消費します。

さらに、負荷がそれほど高くないクラスターがある場合、FPMは、ワーカーがさらに処理する準備ができていることを理解し、プロセスを強制終了しません。つまり、クラスターは存続し、メモリの一部を消費します。一定期間後、すべてをディスクにフラッシュし、ハッシュテーブルをリセットして、最初からやり直します。ただし、タイムアウトにまだ達していない場合は、MSHUTDOWNフックがトリガーされ、最終的にすべてが書き込まれます。



最後に必要だったのは、PHPコードからfuncmapを呼び出す機能でした。対応する拡張機能は、確率がどのように機能したかに関係なく、統計の収集を有効または無効にできる唯一の方法を提供します。

オーバーヘッド

これらすべてがサーバーにどのように影響するのか疑問に思いました。最も負荷の高いPHPクラスターの1つの実際の戦闘機に送信されるリクエストの数を示すグラフを作成しました。



そのようなマシンは多数存在する可能性があるため、グラフにはCPUではなく要求の数が表示されます。バランサーは、マシンが通常よりも多くのリソースを消費し始めたことを認識し、マシンが均等にロードされるように要求を均等化しようとします。これは、サーバーがどのように劣化しているかを理解するのに十分でした。



拡張機能を25％、50％、100％で順番にオンにすると、次の図が表示されます。







点線は、予想されるリクエストの数です。メインラインは、入ってくるリクエストの数です。約6％、12％、23％の低下が見られました。このサーバーは、受信リクエストの処理をほぼ4分の1少なくし始めました。



このグラフは、まず、サンプリングが重要であることを示しています。サーバーリソースの20％を統計の収集に費やすことはできません。

誤った結果

サンプリングには副作用があります。一部のメソッドは統計に含まれていませんが、実際には使用されています。私たちはいくつかの方法でこれと戦おうとしました：

• . -, . , , , , .
• . , : , , .

エラー処理のために2つの解決策を試しました。 1つ目は、エラーが発生した瞬間から強制的に統計収集を有効にすることです。エラーログを収集して分析します。ただし、ここには落とし穴があります。リソースが減少すると、エラーの数が即座に増加します。それらの処理を開始すると、さらに多くのワーカーが存在し、クラスターはゆっくりと消滅し始めます。したがって、そうすることは完全に正しいわけではありません。



別の方法でそれを行う方法は？私たちは読んで、ニキータ・ポポフのパーサーを使用して、どのメソッドがそこで呼び出されているかに注目して、賭け金を調べました。したがって、サーバーの負荷を排除し、誤検知の数を減らしました。



しかし、それでもめったに呼び出されず、それらが必要かどうかが不明なメソッドがありました。このようなメソッドを使用する事実を判断するのに役立つヘルパーを追加しました。サンプリングにより、メソッドがめったに呼び出されないことがすでに示されている場合は、処理を100％オンにして、何が起こっているかを考えないでください。このメソッドの実行はすべてログに記録されます。あなたはそれについて知っているでしょう。



その方法が使用されていることが確実にわかっている場合は、やり過ぎかもしれません。おそらくこれは必要ですが、まれな機能です。まれにしか使用されない「不平」オプションがあると想像してみてください。しかし、それは重要です。切り取ることができません。そのような場合、そのようなメソッドに手動でラベルを付ける方法を学びました。



どのメソッドが使用されているか（白い背景にある）、どのメソッドが使用されていない可能性があるか（赤い背景にある）を示すインターフェイスを作成しました。ここでは、必要なメソッドをマークすることもできます。

インターフェース画面

インターフェースは素晴らしいですが、最初に戻りましょう。これが私たちが解決していた問題です。それは、私たちのエンジニアがデッドコードを読んだという事実にありました。彼らはどこでそれを読みますか？ IDEで。彼の工芸品のファンに、ある種のWebインターフェイスでIDEの世界を離れて、そこで何かをするように強制するのはどういうことか想像してみてください。途中で同僚に会う必要があると判断しました。未使用のメソッドのデータベース全体をロードし、このメソッドが使用されているかどうかを表示するPhpStormのプラグインを



作成しました。さらに、メソッドをインターフェースで使用されているものとしてマークすることができます。これはすべてサーバーに送られ、残りのコードベース寄稿者が利用できるようになります。



これで、Legacyでの作業の主要部分は終わりです。実行していないことに早く気づき、それにすばやく応答し、未使用のコードを手動で検索する時間を無駄にしません。



funcmap拡張機能はGitHubで入手できます。誰かのお役に立てれば幸いです。

代替案

外から見ると、バドゥーの私たちは自分たちで何をすべきかわからないように見えるかもしれません。市場に出ているものを見てみませんか？



これは公正な質問です。私たちは見ました-そしてその時点で市場には何もありませんでした。私たちがソリューションを積極的に実装し始めたとき、同時に、霧のイギリスに住むジョー・ワトキンスという男が同様のアイデアを実装し、Tombs拡張機能を作成したことを発見しました。



すでに独自の解決策があるため、あまり慎重に調査しませんでしたが、それでもいくつかの問題が見つかりました。

• サンプリングの欠如。上で、なぜそれが必要なのかを説明しました。
• . , APCu ( ), .
• CLI. , , CLI-, .
• . Tombs, , , , , , . funcmap («» , ): , . Tombs , , FPM CLI. - , .

まず、特に開発が非常に活発な場合に、短期間に実装される機能をどのように削除するかを事前に検討してください。私たちの場合、これらはA / Bテストでした。事前に考えていない場合は、がれきを片付ける必要があります。



第二に：あなたの顧客を一目で知る。それらが内部であるか外部であるかは関係ありません-あなたはそれらを知っている必要があります。ある時点で、あなたは彼らに言う必要があります。番号"。



3番目： APIをクリーンアップします。これにより、システム全体が簡素化されます。



そして第4に、デッドコードの検索も含め、すべてを自動化できます。それが私たちがしたことです。