最大主義のないレガシーコードについて：何をすべきか

コードの一部を修正するタスクが与えられたと想像してください。 私の頭の中には多くの考えがあります。 誰が書いたの？ いつ？ それとも彼は遺産ですか？ ドキュメントはどこにありますか？ 「レガシー」を徹底的に、あらゆる側面から対処してみましょう。 タリンのCodeborne社の開発者であるAndrey Solntsev @asolntsev （ http://asolntsev.github.io/ ）は、この問題で私たちを助けてくれます。 始めましょう。



-アンドレイ、マイケルフェザーズの作品、たとえば「レガシーコードを効果的に使用する」に精通していますか？ この本は、テストの重要性に焦点を当て、レガシーコードと非レガシーコードの重要な違いの1つであるテストの可用性を強調しています。 この意見に同意しますか？



私は絶対に同意します！ さらに言います。ユニットテストは必要ですが、十分な条件ではありません。 また、単体テストを使用すると、Hercules自身がすくい上げないように積み重ねることができます。

本物のジェダイ・マスタブは何ですか：

1. TDD-つまり、コードの前にテストします 。
   
   
2. クリーンコード（およびクリーンテスト）。
   
   

ロバートC.マーティンのクリーンコードが大好きです。 これは私にとってデスクトップ聖書です。 全員に強くアドバイスします。 ところで、彼のブログも素晴らしいです。




-コードがすっきりしていることは明らかです。 TDDはそれと何の関係がありますか？ バグのないコードは良いコードと同じではありませんか？



TDDはテストに関するものだと誰もが思っています。つまり、退屈だということです。

ナンセンス！

TDDは開発に関するものです（テスト駆動開発）。 これは、レガシーではないようにコードを作成する方法です。 それをサポートすることができるように：デバッグ、修正、リファクタリング、修正。 現時点では、これが人類に知られている唯一の方法です。 他のすべては邪悪なものからのものであり、ごまかされないようにしてください。



-TDDは弱虫用であり、強力な開発者にとっては、良い頭脳を与えて事前にコードを考えるだけで十分であるという意見があります。 その後、バグはありません。



バグを見つけるためにTDDはまったく必要ありません。

テストは、コードの最初の使用です。 シャーロックホームズは次のように述べています。「まず、事実を収集し、それから理論を構築します。 そうでなければ、あなたは無意識のうちにあなたの理論と事実を両立させ始めます。」 あなたはこれがどのように起こるかにさえ気付かないでしょう！ そのため、コードを使用します。コードの前にテストを書くとき、それを使用する方が便利な方法、クラス、メソッドに名前を付ける方法を考えることを余儀なくされます。 渡すパラメーター。 そして、最初にコードを書くと、そのテストをジャグリングし始めます。 その結果、テストの割合が複雑になり、他のテストは修正が困難になり、一部は未作成のままになります。 そして、ここにレガシーコードが直接あります！



-テストについての議論を続けます、あなたの意見では、どのテストが正しく、どのような状況、例えば単体テストですか？



ユニットテストから始めましょう。 それらはすべてのプロジェクトで必要であり、オプションはありません。



もちろん、他の種類のテストも重要です：統合、UI、パフォーマンステスト。 これは、プロジェクトごとにすでに異なります。 重要なことは、単体テストよりも1桁小さいことです。 テストピラミッドについては、誰もが知っていると思います。



-そして、テストでのコードカバレッジはどうあるべきですか？ 70％で十分ですか？ プロジェクトの「診断」に行き過ぎないようにするには？



もちろん、最大限のカバレッジを得るために努力する必要があります。 30％または70％のカバレッジに関するこのすべての話は、誤解によるものです。 100％を目指して努力する必要があります（ただし、これは達成できない制限です）。



100％のカバレッジが不可能であることは誰もが知っていますが、誰もがその理由を理解しているわけではありません。 「重要なものだけをテストする必要がある」、「ゲッターをテストする必要がない」、「より重要なことを行う必要がある」ためです。



どのシステムでもコードが外部と通信するため、完全なカバレッジは不可能です。 画面上のピクセルの描画、デバイスの制御など-このコードでは単体テストは不可能です。自分の目で確認する必要があります。 私たちのプロフェッショナリズムは、この「外界とのコミュニケーション」の層をできるだけ薄く保ち、そこからすべての論理を取り除くことにあります。 そして、それをテストする必要があります。



大まかに言って、期限切れのローンを赤で強調表示する必要がある場合、「どの期限切れのローン」のロジックは、単体テストと「ハイライト」を使用した別個の方法で別々に実行する必要があります。 まあ、CSSまたは何でも。 また、TDDはこれらのレイヤーの分離を奨励しています。これはすばらしいことです。 これが彼の強さです！ また、テストは単なる副作用です。



-単体テストの作成にどれだけの時間を費やすべきか、プロジェクトのどの段階で重要な役割を果たすか？



ユニットテストは、すべての段階で常に重要な役割を果たします。 「ユニットテストの記述を開始する時」や「ユニットテストを記述できなくなる」段階はありません。



すべてを正しく行うと、単体テストの作成にかかる時間の質問に答えることはできません。 これは開発の一部です。 モルタルでレンガを広げるのにどれくらいの時間がかかるか、そしてどれだけの量を置くのか、誰も尋ねません。 これらはすべて必要な手順であり、それだけです。 あなたはそれらのうちの1つを投げることができません、さもなければあなたの壁は2日目にバラバラになります、そして、あなたはたくさんのレガシーレンガを手に入れるでしょう。



-テスト作成プロセスはどのようなものですか？



赤いテストを10分間書いて、10分間緑にして、10分間リファクタリングします。 もちろん、この時間を正確に測定する人はいません-時には5:30：0、時には180：5-60です。 関係ありません。 月と年のコードを同じ速度で、予測可能な速度で変更できることが重要です。 長い目で見れば一定の速度は、開始時の高い瞬間速度よりもはるかに重要です。



TDDがはっきりと元気に示されているこのビデオをお勧めします。「 少年がやった、少年がやった！ 「長さに驚かないでください。ユニットテストについては最初の30分しかありません。







-Andrey、TDDが非常に有用な場合、なぜそれほど使用されないのですか？



すべてがシンプルです。 TDDは規律です。 それはスポーツのようなものです。誰もがスポーツは便利ですが、怠zyであることを知っています。 最も正直な人は彼らが怠けていることを認め、残りは言い訳を見つけ、そして最も悪名高い人はスポーツがなぜ有害であるのかという説明を思いつき始めます。 TDDを使用しています。



面白い違いは、ソファに横たわっている人は自分をアスリートとは呼ばないということです。 ここではすべてが公平です。 また、コーダーはテストを作成せず、同時に開発者と呼ばれます。 信じられないよね？ しかし、それは常に同じ終わりです。 トレーニングを逃したアスリートはすぐに競争に負けます。 同様に、テストを介さずに記述されたコードはすぐにレガシーになります。 ここではすべてが公平です。



TDDは規律です。 TDDは知るのに十分ではなく、コードを変更するたびに毎日使用する必要があります。 最も猛烈なTDDファンでさえ、忘れて、見苦しい位置にいることに気付き、テストの前に公にコードを書いています。 ペアプログラミングは、対処するのに役立ちます。 これは、私が強くお勧めするもう1つの方法です。



TDDは、毎日証明しなければならない定理です。



-テストカバレッジに関する問題について話し合いました。 互換性などの他のレガシー問題に対処することが重要です。 さらに古いライブラリとの互換性のためにコードが変更されていないプロジェクトがあります。 自動車産業との類似性を引き出す場合、新しい設計で廃止されたコンポーネントやアセンブリを使用しようとする試みは致命的であり、プロジェクトのコードの平均レベルは時代の期待に応えなければならないと思いませんか？



ひとつお話しましょう。 兄はタルトゥ大学の化学研究所で働いていました。 代表団はヨーロッパのどこかから来ました。 彼らはすべてを見せられた：新しい施設、新しい機器、すべてのもの。 そして、彼らは角のどこかに古いソビエト部隊に注意を引きました。 出席者は目を丸くして、まあ、なぜ彼を捨てないのかと尋ねました。 答えは次のとおりです。「信じないで！ なぜなら彼は... WORKS！」



単一の答えはありません。 すべての依存関係は毎日更新され、必須の衛生として扱われます。 MavenまたはGradleにこれを自動的に行うように依頼することもできます。 そして、元のライブラリのフォークを作成し、古いバージョンで20年間座ることができます。 おそらく依存関係に依存します。 Seleniumに強く依存している場合、新しい機能を使用してから、頻繁に更新します。 新しいlog4j機能に依存しない場合、古いバージョンを使用しています。 すべてが機能します。



私が年をとるほど、アップデートを追いかけてはいけないという事実に傾くようになります。 新しいPlayフレームワークはStruts2より優れていませんでした。 MavenはAntよりも優れています（さらに悪いことです）。 TestNGは間違いなくJUnitよりも悪い（そして、結局のところ「新世代」という名前に！）。 Hibernate3はHibernate 2よりも困難でした。SpringブートはSpring MVCよりも困難です。 しかし、10年が経ちました！ 私は新しいJavaScriptライブラリについては黙っています。



したがって、グリースでコーティングされたすべてが新しいわけではありません。



-（前の質問に加えて）練習中に同様の状況に遭遇しましたか？ そのような状況からどのように抜け出しましたか？ どの戦略に従って、すべてを書き直しますか（グリーンフィールドという用語がよく使われます）、またはリファクタリングを行いますか？



もちろん、会った。

はい、それは組織の問題です。 後方互換性のないある種の依存関係を更新したい場合は、そのための時間を確保し、その瞬間に誰も緊急なものを持たないようにチームと調整し、リファクタリングする必要があります。 多くの人が泣き始めます：「私たちはこの時間を与えられていません。」 よくわかりませんが、更新する必要はないでしょうか？ それは重要だろう-彼らは時間を与えるだろう。



グリーンフィールドに関しては、私はかなり懐疑的です。

もちろん、すべてをゼロから書き直すことを夢見ていない兵士は悪いです。

しかし、私の人生では、システムがゼロから書き直されて改善されたのを見たことはありません。 通常、同じまたはさらに悪い結果になります。 コピーリストは大きな興奮から始まり、ある問題に遭遇し、別の問題に遭遇します。 彼はもう間に合わないことを理解しています...技術的な負債をある場所に、別の場所に残します-そして、半分はまだ書かれていませんが、新しいプロジェクトにはすでにレガシーコードがあります。



ゼロから何かを書き換えるには、より良い方法と方法を正確に理解する必要があります。 そして、なぜあなたの前任者は失敗しましたか。



-実績のある「ハイブリッド」オプションがあるかもしれませんか？



ハイブリッドオプションがあります。 最もレガシーなシステムの一部を最初から書き直すことができます 。 そして、古いバージョンもそのままにして、並行して動作するようにします。 そして、システムのすべての部分を1つずつ徐々に新しいバージョンに転送します。 はい、忍耐と時間がかかりますが、これが唯一の方法です。 不本意？ その後、まったく始めないでください。 ここで急いで場所ではありません。



-不良なレガシーコードと、最大の「オーバークロック」コードの定義をどのように区別しますか？ 将来のサポートを犠牲にしてパフォーマンスを追いかける価値はありますか？



オーバークロックされたコードは、動作を高速化するためのバイトを含む数十行の厄介な操作のようなものですか？ 実生活でのそのようなコードは、物語のカテゴリーに由来すると思います。 誰もがそれができるのは冷たいピーマンだけだと考えており、彼らも学びたいと思っています。 アプリケーションプログラミングでは、これはほとんど必要ありません。

まだ必要な場合は、誰もこのコードを「オーバークロック」し、読みやすくテストする必要はありません。 さあ、あなたはプロです。 最初に単体テストを記述してから、オーバークロックします。 単体テストを圧倒していませんか？ 分散するものは何もありません-鼻は成熟していません。







-レガシーコードはシステム全体の開発を遅くすると思いますか？



もちろんできます！ そして、それは遅くなります！

実際、これは通常、速度が低下する最も重要なことです。 その後の各変更はより困難であり、何かを壊すリスクがあります。



-あなたがそれを見た場合、プロジェクトの恐ろしくて遅い「モンスター」を取り除く必要性についてアドバイスをしてもらえますか？ これにどのように反応しましたか（そのような状況が発生した場合）？ 変更はプラスの効果をもたらしましたか（そのような状況が発生した場合）？



おそらくスカウトのルールについて聞いたことがあるでしょう。クリアリングはあなたの前よりも少しきれいにしておきます。 つまり、目的の行を変更するだけでなく、少し再現し、欠落しているテストを追加します。 したがって、プロジェクトは常に改善されます。



しかし、ここでは行き過ぎないことが重要です。 開拓地を少しきれいにし、振り返らずに森林全体を耕す必要はありません。 私はこれを何度も見ました（そしてそれをしました）：次のホットヘッドはすべてを書き直すことを決め、数時間/数日間ハードリファクタリングに行き、行き詰まり、drれ、結果としてそれを悪化させます。 最良の場合、変更をロールバックし、わずかな時間の損失で停止します。



レガシーコードを修復することは確かに非常に有用な演習です。 分析的思考、リファクタリング、優れたコードの理解に関する優れたスキル。 演習として-アドバイスします。



しかし。

レガシーコードを修復することは、ヒドラの頭を切り刻むことと同じです。 3つの新しいものが成長します。 そして、最初のものは完全に切り落とされなかったことがわかり、彼女はあなたを噛んだだけでなく、何か粘着性のある緑色がこぼれ出て、周りをすべて塗りつけました。 それからマネージャーが来て言った：「一体何に触れたのか、うまくいったのか？」



したがって、プロジェクト内の何か-幸運、健康、気分を改善することを真剣に望んで、レガシーコードを修正する場合。 どこかにファイルがありますが、概して何も変わりません。 これは、症状ではなく病気で治療する必要がある場合です。 にきびを絞るのではなく、通りに出て走りましょう。 問題が実際に何であるかを理解してください。 なぜあなたのチームで悪いコードが書かれているのですか？ 人々は急いでいますか？ アーキテクチャを理解していないのですか？ 互いに対立していますか？ 交渉方法がわからない？ 賢い大人と一緒に実際のプロジェクトでこれに出会った。 そして、ここでは、変数の名前を変更するのではなく、処理する必要があります。



-コードの美しさはレガシーステータスの指標ではないという意見はありますか？



コードの「美しさ」は悪です！ コードを精神的にも「美しい」と決して呼ばないでください。 最も洗練されたgovnokodは、「美しく」したいという欲求から得られます。 コードは、読みやすく、予測可能で、簡潔にできますが、まったく美しくありません！ 「美しいコード」は、文学エッセイの「良いヒーロー」のようなものです。 より正確な言葉遣いを見つける努力をする-同時に他の多くの質問に答えてください。



-コードの設計に関する標準合意の違反はレガシーであると言うことはできますか？



標準の規則は便利ですが、それらを過大評価しないでください。 コードの規則は、コード自体よりもさらに速くレガシーになります。 誰もそれらを読むことはありません。 白鳥、ザリガニ、パイクには標準の長さのロープがありました。



そして、彼らのためにあなたの力を無駄にしないでください。 すべてのプロジェクト参加者のIDEを一度セットアップして、それ自体が必要に応じてコードをフォーマットするようにし、それ以上は考えないようにします。



-レガシーのフレームワークで、テスト、パフォーマンス、プロジェクトの依存関係、コードの美しさの問題について議論し、開発のトピックに触れました。 レガシーコードとその発生理由についてのあなたの意見は、時間の経過とともに変化しませんでしたか？



もちろん変わりました。 最初は、他の皆と同じように、私はインド人と愚かな同僚が悪いコードを書くと思っていました。 または「ジュニア」。 しかし、それはそれほど単純ではありません。



私はあまりにも単純な説明が好きではありません。 「あのバカ」にすべてを責めるのは簡単すぎる。 そして、レガシーコードは、最も知的な人々、そして最高のプロジェクトに登場します。



-そしてあなたは？



そうそう。 そうそう！

ここでは、レガシーコードについて非常に賢くブロードキャストしています。私自身は、オープンソースプロジェクトSelenideを持っています。これはレガシーコードでまばたきしません。 いいえ、うまく機能し、ユーザーは満足していますが、時間の経過とともに変更することはより困難です。 チケットを作るのは本当に難しいので、数年前からぶら下がっているチケットがあります。 1つの場所で変更-別の場所で中断します。 はい、統合テストがあります。そのおかげで、何かを壊すことを恐れていません。 しかし、コードの変更が機能しないという意味では、彼らからの助けはありません。



気がついたら、重要な問題は、このプロジェクトでは最初に単体テストを作成しなかったことです。 このライブラリ自体がテストの作成を目的としている場合、なぜテストするように見えましたか？ 既にテストされています。 しかし、それは判明しました-ミハリーチ、そこにあります！ レガシーコードを回避するには、単体テストが必要です。



まあ、私はこれを行います：6ヶ月または1年に一度、私は座って犬と一緒にいくつかのモジュールを地獄に書き直します。 趣味なので、そこから来ています。 しかし、それが仕事であり、お金で表現された場合、書き直す価値があるでしょうか？ ああ、わからない...



「レガシーコードを知覚する色合いは何だと思いますか？」 どのような場合に正当化されますか？



簡単なレシピがあります。 ラムダと括弧から少し休み、クライアントの代わりに自分を想像してください。 それは素晴らしい脳をきれいにします。



クライアントとして、あなたはあなたの車を車のサービスに連れて行き、そこで何がノックしているのかを尋ねます。

そして、メカニックはあなたに言った：「私はノッキングしていたものを変えたが、漏れやすい燃料ポンプも持っている。それを変えるだろうか？」これは良いメカニックだ。 悪いメカニックはすぐにポンプを変更します。 優れたメカニックが問題を報告し、オプションをペイントしました。今すぐ交換できます-費用がかかります。 変更することはできませんが、冬はまだそこに着きますが、すべてのホースが飛ぶでしょう-それは3倍高価になります。 そして、クライアントとしてのあなた自身が決定します。 人は言うだろう：なぜ二度歩く、すべてを変える！ 別の人は言う：「今はお金はありませんが、私はまだ冬のタイヤが必要です。 春まで待ちましょう。」



最悪のメカニックが何をするか知っていますか？ 黙ってください。 要求されたものだけを行います。



親愛なるプログラマー、私たちはどのように振る舞いますか？

すぐにすべてをリファクタリングしようとする同じホットヘッド-彼らは誰が好きですか？ 悪いメカニックのようです。 そして、すべてをそのままにしておくことを決定する「成熟した」もの？ 悲しいかな、最悪。 優れたメカニックはレガシーコードで何をすべきでしょうか？ どのくらいの頻度でそれを行いますか？ 考えてみてください。



-Andrei、TDD、単体テスト-これはすべて良いことですが、読者の99％にとって、これはさまざまな理由で耐えられないことを理解しています。 そして最後に、レガシーコードの処理方法に関する簡単なレシピを提供できますか？



あなたはレシピが欲しいが、私がレシピを与えるとき-証明された、信頼できる、あなたはこれに時間がないと言う。 そして、レガシーコードについて不平を言ってください。 あなたは私に何を期待しますか、あなたは赤い丸薬を飲みました、そしてあなたはすでにマトリックスにいますか？ 丸薬はありません。



人は人のようです。 彼らは急ぐのが好きですが、それはいつもそうです...人類はシンプルなレシピが大好きです...一般的に、彼らは前者を思い出させます...マイクロサービスの質問はそれらを台無しにしました...



一般的に、レガシーコードの魔法のような処分はありません。 しかし、あなたはそこに保持し、幸運、良い気分！



-率直で前向きな会話をありがとう。 読者は、単純ではありませんが、レガシーとの戦いにおける決定を発見することを期待しましょう。 最近の記事の 1つ は、テストの重要性を直接確認することです。 個人的に、あなたは私を納得させました。



ご招待ありがとうございます。

そして、私はこの状況を利用して、すべての読者にタリンの私たちを訪問するよう勧めます。 美しい中世都市、優れたクラフトビール、そしてIT関係者向けの素晴らしいイベントがあり、誰でも無料で参加できます： devclub.eu



ご清聴ありがとうございました！

---

Joker 2016プログラムには 、技術的で筋金入りのより興味深いレポートがあります。 レガシーを使用する場合、次のレポートに注意する必要があります。

• Andres Almiray、Griffon：新機能と今後の機能
• Baruch Sadogursky：Gradleに対するMawen-自動化の夜明け
• Dmitry Alexandrov：JBatch、または最大のデータとはかけ離れた

また、Vyacheslav Lapinによる未公開のレポート、「大規模なレガシーエンタープライズプロジェクトをJava 8に変換した方法-トリック、トリック、および「水中の神」」。