期限に達した後、廃止されたコードがコンパイルされないようにする[終了]

私のチームでは、大きなモノリシックプロジェクト（クラス全体、メソッドなど）で多くの古いものを削除しています。

そのクリーニングタスクの間に、私はいつもよりも一種の注釈やライブラリの凝ったものがあるのか​​と思っていました@Deprecated。これにより@FancyDeprecated、特定の日付が過ぎた後に古い未使用コードをクリーンアップしていない場合、プロジェクトのビルドが成功しなくなります。

インターネットで検索してみましたが、以下に説明する機能を持つものは見つかりませんでした。

• 特定の日付の前に削除する予定のコードに配置するための注釈または類似のもの
• その日付の前にコードがコンパイルされ、すべてが正常に動作します
• その日以降、コードはコンパイルされず、問題について警告するメッセージが表示されます

私はユニコーンを探していると思います...どのプログラム言語にも同様の技術はありますか？

計画として、BIは、「デッドライン」で失敗し始めるコードの単体テストでマジックを作成する可能性を考えています。これについてどう思う？より良いアイデアはありますか？

コンパイルが本当に禁止されている場合、これは便利な機能ではないと思います。2018年1月6日、前日コンパイルされたコードの大部分がコンパイルされない場合、チームはその注釈をすばやく削除し、コードをクリーンアップするかどうかを決定します。

ただし、次のようなカスタムアノテーションをコードに追加できます。

@Deprecated_after_2018_07_31

それらの注釈をスキャンする小さなツールを作成します。（リフレクションを使用したくない場合は、grepの単純な1つのライナーでできます）。Java以外の言語では、「grepping」に適した標準化されたコメント、またはプリプロセッサ定義を使用できます。

次に、特定の日付の直前または直後にそのツールを実行し、それでもその注釈が見つかった場合は、それらのコード部分を緊急にクリーンアップするようチームに通知します。

これは、時限爆弾として知られる機能を構成します。タイムボムを作成しないでください。

コードは、関係なく、あなたはそれを構造化し、文書化する方法も、う、それは一定の年齢を超えて住んでいる場合は病気の理解に近い神話のブラックボックスに変わりありません。将来の誰かが最後に必要とするものは、最悪の場合に、明らかな救済策なしに、完全に驚きによってそれらをキャッチするさらに別の奇妙な失敗モードです。このような問題を意図的に生成する理由はまったくありません。

このように考えてください。コードベースを整理し、陳腐化を気にかけ、それをフォローするのに十分な知識がある場合は、コード内に通知するメカニズムは必要ありません。そうでない場合は、コードベースの他の側面についても最新ではない可能性があり、おそらくタイムリーかつ正確にアラームに応答することができないでしょう。言い換えれば、時限爆弾は誰にとっても良い目的にはなりません。断ってよ！

C＃ObsoleteAttributeでは、次の方法で使用します。

• バージョン1では、機能を出荷します。メソッド、クラス、何でも。
• バージョン2では、元の機能を置き換えることを目的とした、より優れた機能を出荷します。廃止された属性を機能に設定し、「警告」に設定し、「この機能は非推奨です。代わりに、より良い機能を使用してください。などでリリースされるこのライブラリのバージョン3で」日付、この機能の使用はエラーになります。」これで、この機能のユーザーは引き続き使用できますが、新しい機能を使用するためにコードを更新する時間ができます。
• バージョン3では、属性を警告ではなくエラーに更新し、メッセージを更新して「この機能は非推奨です。代わりに優れた機能を使用してください。などでリリースされるこのライブラリのバージョン4では、日付、この機能はスローされます。」前の警告に注意しなかったユーザーには、問題を修正する方法を伝える有用なメッセージが表示されますが、コードはコンパイルされないため、修正する必要があります。
• バージョン4では、致命的な例外をスローするように機能を変更し、次のバージョンで機能が完全に削除されることを示すメッセージを変更します。
• バージョン5では、この機能を完全に削除し、ユーザーが不平を言ったら、まあ、公正な警告の3つのリリースサイクルを与えました。

ここでの考え方は、影響を受けるユーザーに可能な限り簡単に重大な変更を加え、少なくとも1つのバージョンのライブラリーで引き続き機能を使用できるようにすることです。

「非推奨」の意味を誤解しています。非推奨の意味：

使用可能ではあるが、一般的には置き換えられているため、時代遅れであり、回避するのが最善であると見なされている。

_{オックスフォード辞書}

定義上、非推奨の機能は引き続きコンパイルされます。

特定の日に機能を削除しようとしています。それはいいです。その方法は、その日に削除することです。

それまでは、非推奨、廃止、またはプログラミング言語で呼ばれているものとしてマークしてください。メッセージに、削除する日付とそれを置き換えるものを含めます。これにより、他の開発者が新しい使用法を避け、可能な限り古い使用法を置き換える必要があることを示す警告が生成されます。それらの開発者はそれを遵守するか無視しますが、それが削除された場合、誰かがその結果に対処する必要があります。（状況に応じて、それはあなたかもしれませんし、それを使用している開発者かもしれません。）

すでにリリースされているソフトウェアのバージョンをサポートするために、古いバージョンのコードをビルドおよびデバッグする機能を保持する必要があることを忘れないでください。特定の日付以降にビルドを妨害すると、将来的に正当な保守およびサポート作業を行うことを妨げるリスクも生じます。

また、コンパイルの1〜2年前にマシンのクロックを戻すことは簡単な回避策のようです。

「非推奨」は、将来何かがなくなるという警告であることに注意してください。人々がそのAPIを使用できないように強制する場合は、関連するコードを削除するだけです。何らかのメカニズムによってコードが使用できなくなった場合、コードベースにコードを残しても意味がありません。コードを削除すると、探しているコンパイル時のチェックが得られ、簡単な回避策はありません。

編集：質問で「古い未使用コード」を参照しているようです。コードが実際に使用されていない場合、それを廃止する意味はありません。削除するだけです。

私は以前にそのような機能を見たことがありません-特定の日付後に効力を発する注釈。

@Deprecatedしかし、十分なものとすることができます。CIで警告をキャッチし、存在する場合はビルドの受け入れを拒否します。これにより、コンパイラからビルドパイプラインに責任が移りますが、追加の手順を追加することでビルドパイプラインを（半）簡単に変更できるという利点があります。

この答えはあなたの問題を完全には解決しないことに注意してください（たとえば、開発者のマシンでのローカルビルドは、警告はありますが成功します）。

カレンダーまたはToDoリストを探しています。

別の方法として、カスタムコンパイラの警告またはコンパイラメッセージを使用することもできます（コードベースに警告があったとしてもほとんどない場合）。警告が多すぎる場合は、追加の労力（約15分？）を費やす必要があり、ビルドレポートでコンパイラの警告を取得する必要があります。これは、各ビルドで継続的な統合によって提供されます。

コードを修正する必要があるというリマインダーは適切で必要です。時々、これらのリマインダーには厳密な現実世界の期限があるため、タイマーに入れることも必要になる場合があります。

目標は、問題が存在し、特定の時間枠で修正する必要があることを人々に継続的に思い出させることです-特定の時間にビルドを中断するだけの機能ではなく、その機能自体が必要な問題です特定の時間枠で修正されます。

これについて考える1つの方法は、あなたが時間/日付で意味するものですか？コンピューターは、これらの概念が何であるかを知りません。何らかの方法でプログラムする必要があります。「エポックからの秒数」というUNIX形式で時間を表すことは非常に一般的であり、OS呼び出しを介してプログラムに特定の値を供給することは一般的です。ただし、この使用方法がどれほど一般的であっても、「実際の」時間ではなく、単なる論理的な表現であることに留意することが重要です。

他の人が指摘しているように、このメカニズムを使用して「デッドライン」を作成した場合、別の時間にフィードしてその「デッドライン」を破ることは簡単です。同じことは、NTPサーバーに問い合わせるなど、より複雑なメカニズムにも当てはまります（独自の証明書、認証局、または暗号ライブラリにパッチを適用できるため、「安全な」接続でも）。最初は、そのような個人はあなたのメカニズムを回避することに責任があると思われるかもしれませんが、それは自動で正当な理由で行われる場合があります。たとえば、再現可能なビルドを使用することをお勧めします。これを支援するツールを使用すると、このような非決定的なシステムコールを自動的にリセット/インターセプトできます。libfaketimeはまさにそれを行い、すべてのファイルのタイムスタンプをに設定し1970-01-01 00:00:01、Qemuの記録/再生機能はすべてのハードウェアの相互作用などを偽装します。

これはグッドハートの法則に似ています。プログラムの動作を論理時間に依存させると、論理時間は「実際の」時間の適切な尺度ではなくなります。言い換えれば、人々は一般的にシステムクロックを台無しにしませんが、理由を与えれば彼らはそうします。

時間の論理的な表現は他にもあります。それらの1つはソフトウェアのバージョン（アプリまたは依存関係）です。これは、たとえばUNIX時間よりも「期限」の方が望ましい表現です。なぜなら、それは関心のあるもの（機能セット/ APIの変更）に固有であり、したがって、直交する懸念を踏みにじる可能性が低いためです（たとえば、UNIX時間をいじる締め切りを回避すると、ログファイル、cronジョブ、キャッシュなどが破損する可能性があります。

他の人が言ったように、ライブラリを制御してこの変更を「プッシュ」したい場合は、機能を非推奨にする新しいバージョンをプッシュして（警告を発生させ、消費者が使用方法を見つけて更新するのを助ける）、その後、完全に機能します。必要に応じて、これらを次々に公開できます。（再び）バージョンは単なる時間の論理的な表現であり、「実際の」時間に関連する必要はありません。ここでセマンティックバージョニングが役立つ場合があります。

代替モデルは、変更を「プル」することです。これは「プランB」のようなものです。消費アプリケーションにテストを追加し、この依存関係のバージョンが少なくとも新しい値であることを確認します。いつものように、赤/緑/リファクタリングにより、コードベースを介してこの変更を伝播します。これは、機能が「悪い」または「間違っている」のではなく、「このユースケースに合わない」場合に適しています。

「プル」アプローチの重要な問題は、依存関係のバージョンが「機能」の「ユニット」としてカウントされるかどうかであり、したがってテストに値するかどうかです。または、それが単なる「プライベート」な実装の詳細であるかどうか。これは、実際のユニット（機能）テストの一部としてのみ実行する必要があります。依存関係のバージョン間の区別が実際にアプリケーションの機能としてカウントされる場合は、テストを実行します（たとえば、Pythonバージョンが3.x以上であることを確認します）。そうでない場合は、しないでくださいテストを追加します（脆弱で、情報量が少なく、制限が厳しすぎるため）。ライブラリを制御する場合は、「プッシュ」ルートを使用します。ライブラリを制御しない場合は、提供されているバージョンを使用してください。テストに合格した場合、自分で制限する価値はありません。彼らが合格しなければ、それがまさにあなたの「期限」です！

依存関係の機能の特定の使用（たとえば、コードの残りの部分でうまく機能しない特定の関数の呼び出し）を思いとどまらせたい場合、特に依存関係を制御しない場合は、別のアプローチがあります。コーディング標準を禁止してくださいこれらの機能の使用を/ discourageし、それらのチェックをリンターに追加します。

これらはそれぞれ異なる状況に適用されます。

これはパッケージまたはライブラリレベルで管理します。パッケージを制御し、その可視性を制御します。可視性を自由に撤回できます。私はこれを大企業で内部的に見てきましたが、パッケージがオープンソースまたは無料で使用できる場合でも、パッケージの所有権を尊重する文化でのみ意味があります。

クライアントチームは単に何も変更したくないため、これは常に面倒です。特定のクライアントと協力して移行の期限に同意し、サポートを提供する可能性があるため、ホワイトリストのみのラウンドが必要になることがよくあります。

1つの要件は、ビルドに時間の概念を導入することです。C、C ++、またはCのようなプリプロセッサを使用する他の言語/ビルドシステム¹では、ビルド時にプリプロセッサの定義を介してタイムスタンプを導入できますCPPFLAGS=-DTIMESTAMP()=$(date '+%s')。これは、メイクファイルで発生する可能性があります。

コードでは、そのトークンを比較し、時間が経過するとエラーを引き起こします。関数マクロを使用すると、誰かが定義しなかった場合をキャッチすることに注意してくださいTIMESTAMP。

#if TIMESTAMP() == 0 || TIMESTAMP() > 1520616626
#   error "The time for this feature has run out, sorry"
#endif

または、問題が発生したときに問題のコードを単に「定義」することもできます。誰も使用しない限り、プログラムをコンパイルできます。たとえば、apiを定義するヘッダー「api.h」がありold()、一定時間後の呼び出しは許可されていません。

//...
void new1();
void new2();
#if TIMESTAMP() < 1520616626
   void old();
#endif
//...

同様の構成体は、おそらくold()ソースファイルからの関数本体を削除します。

もちろん、これは絶対確実ではありません。TIMESTAMP他の場所で言及された金曜日の夜の緊急ビルドの場合、単純に古いものを定義できます。しかし、それはかなり有利だと思います。

これは明らかに、ライブラリが再コンパイルされたときにのみ機能します。その後、廃止されたコードは単にライブラリにもう存在しなくなります。ただし、クライアントコードが廃止されたバイナリにリンクすることを妨げることはありません。

Visual Studioでは、特定の日付の後にエラーをスローするビルド前スクリプトを設定できます。これにより、コンパイルが妨げられます。2018年3月12日以降にエラーをスローするスクリプトを次に示します（ここから取得）。

@ECHO OFF

SET CutOffDate=2018-03-12

REM These indexes assume %DATE% is in format:
REM   Abr MM/DD/YYYY - ex. Sun 01/25/2015
SET TodayYear=%DATE:~10,4%
SET TodayMonth=%DATE:~4,2%
SET TodayDay=%DATE:~7,2%

REM Construct today's date to be in the same format as the CutOffDate.
REM Since the format is a comparable string, it will evaluate date orders.
IF %TodayYear%-%TodayMonth%-%TodayDay% GTR %CutOffDate% (
    ECHO Today is after the cut-off date.
    REM throw an error to prevent compilation
    EXIT /B 2
) ELSE (
    ECHO Today is on or before the cut-off date.
)

このスクリプトを使用する前に、このページの他の回答を必ず読んでください。

私はあなたがやろうとしていることの目的を理解しています。しかし、他の人が言及したように、ビルドシステム/コンパイラはおそらくこれを実施するのに適切な場所ではありません。このポリシーを実施するためのより自然な層は、SCMまたは環境変数のいずれかであることをお勧めします。

後者を行う場合、基本的に、廃止予定の実行をマークする機能フラグを追加します。非推奨のクラスを作成するか、非推奨のメソッドを呼び出すたびに、機能フラグを確認してください。単一の静的関数assertPreDeprecated()を定義し、これをすべての非推奨コードパスに追加するだけです。設定されている場合、アサート呼び出しを無視します。例外がスローされない場合。日付が過ぎたら、ランタイム環境で機能フラグを設定解除します。コードへの非推奨の残留呼び出しは、ランタイムログに表示されます。

SCMベースのソリューションの場合、gitとgit-flowを使用していると仮定します。（そうでない場合、ロジックは他のVCSに簡単に適応できます）。新しいブランチを作成しますpostDeprecated。そのブランチでは、廃止されたコードをすべて削除し、コンパイルされるまで参照の削除作業を開始します。通常の変更は引き続きmasterブランチに加えられます。廃止されていない関連コードの変更をmaster再びマージしpostDeprecatedて、統合の問題を最小限に抑えます。

廃止予定日が終了したら、preDeprecatedから新しいブランチを作成しますmaster。次ににマージpostDeprecatedしmasterます。リリースがmasterブランチから外れると仮定すると、日付の後、非推奨のブランチを使用する必要があります。緊急事態が発生した場合、または時間内に結果を提供できない場合は、いつでもロールバックしてpreDeprecated、そのブランチで必要な変更を加えることができます。