私たちはプロジェクトに対処します
レガシーでどれだけ正確で、思慮深く、骨の折れる仕事が必要であるかを伝えるために、カードの家との類推を行います。
これは、レガシーコードの外観です。 この建物から少なくとも1枚のカードを取り外したり交換したりすると、家全体が圧倒され、その残骸が地面と平らになるリスクがあります。
レガシーはほぼ同じように動作します。 したがって、プロジェクトに近代化と「セカンドライフを吹き込む」というタスクを引き受けたプログラマーの仕事は、ある程度の宝飾品でなければなりません。 ほとんどのプログラマーは、技術的な負債を避け、一般に「話題から飛び出し」ます。 レガシー状態に陥ったプログラマーから聞いた最も一般的な引用のヒットパレードをコンパイルしました：
- 「シンプルな」サイトを作成しましたが、今では新しい「バン」を入手したいと考えています。レガシーがあるため、これをすべて書き換える必要があります...
- これがどのように機能するのか誰も知らない..
- モジュールを追加するには、サイト全体を確認する必要があります-この方法でのみ、何をどこから入手できるかがわかります...
- いずれにせよそこには行きません、すべてがすでに悪いです...
しかし、プログラミングの経験から、レガシー後の生活が存在することがわかります。 プログラミングに問題はありません。 対処する必要があるタスクのみがあります。 また、「継承コードを克服するために」アクションプランを作成する前に、プロジェクト全体の問題点を理解する必要があります。 実践の過程で、彼はプロジェクトの問題の6つの段階を特定しました。
- 技術文書はありません。 問題の最低しきい値。テストして、これがどのように機能するかについて予備的な推測を行うことができます。
- ビジネス文書なし。 すべてのドキュメント（技術とビジネスの両方）が欠落している場合、「私たちは歴史に行き詰まっているように見える」という感覚が思わず生じます。 実際、ビジネスであっても、どのように機能するかを覚えていないため、少なくともチームは期待される結果を理解していないことになります。
- これを設計した人はいません。 ドキュメントの欠如に加えて、プロジェクトがどのように機能するかを説明できる開発者がいない場合、既に揚げ臭いです。
- ユーザーが最終的に何を取得すべきかはわかりません。 バックエンドの質問の周辺でのみ発生する場合もありますが、何が前面に表示されるべきかまったくわからない場合、これはすでに「患者は生きているよりも死んでいる可能性が高い」という状態に近くなります。
- 各関数の200以上の使用法は、getAと呼ばれます 。 5番目の難易度：レガシーに移行すると、機能Aと200の使用が表示されますが、その理由は誰にもわかりません...
- 開発したい/開発できるプログラマはいません。 コメントはありません。
ビジネスを理解する
ビジネスはお金を数えます。 ビジネスは、既に機能しているものをやり直すためだけに追加の資金を費やすことを望みません。 企業はこのアイデアを決して買うことはありません。「私はそれが好きではないので、私は新しい方法でそれをします。」 したがって、常により多くを提供します。
多くの場合、開発者はビジネスを無駄なアイデアに追い込みます。 この機会に、別の「黄金の引用の基金」があります。
- 私たちは、コードの高品質な「ソーイング」のために新しいチームを採用しています。 つまり、既存のチームと並行してプロジェクトを行うスペシャリストのチームが必要です。 結果が異なるという事実ではなく、ビジネスにはすでに2つのプロジェクトが含まれている必要があります。
- 機能の追加を停止し、リファクタリングのみを行いました！ 正式にビジネスを宣言します。機能に関する絶対的なタブーは、ボンネットの下でのみ「順番に並べること」が可能です。 非公式には、大規模な改善やプロジェクトの改善はなく、それらをローカルで「修正」するだけだとおっしゃいました。
- WPには必要なものがすべて揃っています。データベースを移行するだけです。 これは初心者の「症状」です。 6月のお気に入りの歌：とてもシンプルなサイトで、1、2時間しか機能しません...
新しい収益性の高い機能のソースの下で提供される古いコードの復活に関してビジネスと交渉するには、新しいビジネスの展望を開くという観点から必要です。 ただし、交渉の前に、次の質問に答える必要があります。
- ビジネスは成長する準備ができていますか？ あなたは理解する必要があります：ビジネスは、金融水準を上げるための要求を持っているか、単にサービスがより有能に動作する必要がありますか。
- プロトタイプステージ？ 多くの場合、ビジネスは単純なプロトタイプを注文し、その助けを借りて、製品の関連時に市場を「調査」したいと考えています。 そして、彼がお金を稼ぎ始めた場合にのみ、ビジネスは機能をより高度で完全なプロジェクトに開発する準備ができています。
- 開発は完了し、現在はサポートのみですか？ すべてのタスクを理解することが重要です。
- 私たちの目には十分な火があり、消えないでしょうか？ プロジェクトはやる気を起こさせるのではなく、刺激を与えるべきです。 あなたのチームがレガシーの生まれ変わりに携わりたいと思うことは非常に重要です。そうしないと、人々は徐々に彼らにとってより興味深いプロジェクトに散らばっていきます。
- 建築家はいますか？ これが最も重要な質問です。適切なアーキテクチャを作成し、既に適切なコードを書き始めることができる人がいますか。 建築家がいない場合でも開始しようとしても意味がありません。 そうでなければ、一週間であなたは問題の遺産を作成した人になります。
アイデアをビジネスに販売するときは、「新規、作成、追加」メッセージに焦点を合わせてください。ビジネスは、シリーズの提案に非常によく反応します。 」
P-計画
技術的負債を迅速かつ効率的に処理するには、計画が必要です。
1. 寄生するタスクの定義。 なぜ寄生するのか？ よく起こります：機能を販売し、それによって部分的にリファクタリングを意味します。
2. 高レベルの要件の定義。 正しいドキュメントを作成するには、「高水準」の明確なビジネスリクエストを登録する必要があります。
3. システムのメインモジュールの定義、モジュールの面付け。 リファクタリングを開始する前に、システムの基本的なモジュールを理解する必要があります：どこで、どのように、何で、何で対話し、コードをセクションに区切ることができます。
4. 統合の定義。 特定のモジュールを作成する場合、隣接するレガシーにマウントする可能性について事前に検討する必要があります。
5. チームの定義。 リファクタリング分野の人は戦士ではありません。 チームは成功するための非常に重要な要素です。 熱意、チームの意欲、そして参加者間の優れた相互作用が必要なプロセスです。
6. どのようにテストしますか？ 高品質のプロジェクトを採用する場合は、先を見越して製品テストのオプションを検討する必要があります。
上記に加えて、望ましい最終結果を決定し、スケーリング計画を作成し、プロジェクトのボトルネックを登録することも重要です。 たとえば、コードスケーリングの場合、高負荷状態で問題が発生する可能性のある場所を理解することが重要です（データベース、重いクエリ、グリッド、または「落ちる」可能性のある他の中間リンク）。
プロジェクトの境界、古いコードがあった場所、新しいレベルの「傑作」がある場所を決定することも同様に重要です。 また、マイクロサービス（DDD）へのアプローチを検討する必要があります。そうでない場合は、さらに「ナノマジー」が必要になります。
忍者のレガシーテクニック
「準備作業」の後、技術的負債を節約するプロセスを促進する技術に取り組みます。 Legacyのすべての病気に対する万能のレシピと万能薬はありませんが、高負荷プロジェクトの作業の過程で、本当に「おいしい」コードを準備できる材料のリストを作成しました。
1. 車輪を再発明しないでください。 私にとって、これはコードを書くための主要なライフハックです。 すべてがあなたの前に発明されました。タンバリンや他の実験で踊ってレガシーコードの問題を解決することに頼らないでください。
2. コードは標準です。 単一の標準がなければ、各開発者は独自の方法で記述します。 「著者のスタイル」はカオスの一因となり、コードジャンクをさらに増加させます。
3. コードのレビュー。 コード標準が1つだけ存在するわけではありません。 また、チームがそれをチェックする責任があったことも必要です。 そうしないと、すべてが正常に戻ります。つまり、古いコードのレベルに戻ります。
4. 静的コードアナライザー、PHP混乱検出器など（数千冊の本の代わりに） 。 特に同じレビューコードを使用して、プロセスを高速化するには、これらおよびその他の自動技術が必要になります。
5. マイクロサービスを試します。 別に、モジュールまたはライブラリもあります。 なぜマイクロサービスなのか？ それらの利点は、ロジックを可能な限り分離し、特定のAPIに制限することです。 後者の利点は、「修正可能なコードのアダプタ」と比較して、APIがよりモノリシックなエンティティであることです。 ただし、APIには、追加のネットワークコストという形で1つの欠点があります。
6. データベースアーキテクチャ、データソース。 レガシーの最初のボトルネックと考えられるのはデータベースです。 しかし、誰もが彼が望むように設計し、SQLでさえ、焦点の合っていない欠陥を見つけることができます。 新しいデータベースを使用するためのヒントを次に示します。
- 何もねじ込みません、すべてを渇望します。 古い不正なデータ構造を新しいデータ形式に、より速く、より生産的に変更したい場合は、2つの方法があります。 1つは、新しいベースを配置し、古いベースを完全に削除することです。 2番目-ハードレガシーの場合、新しい形式を並行して導入します。 比Fig的に言えば、古い木の近くに新しいものを植えること。 なぜ2番目の方法が正当化され、より有望なのですか？ 新しいものはすべて効率的に機能し、展開または統合の段階で問題が発生した場合、コードを単純にロールバックでき、複雑なデータベース移行をすべてロールバックする必要はありません。
- 新しいデータベースが正しい構造で作成されます。 新しいリソースを作成するとき、新しい構造を記述する場所を制御することが重要です。 並行して、古い構造を完全に取り除くことは実用的ではないため、古い構造のサポートを作成する必要があります。 つまり、私たちは新しい素材を書き続け、同時に古いテンプレートをサポートします。これに新しいものすべてを翻訳し、古いテンプレートも古い方法で動作するようにします-新しい構造をサポートします。
- 録音全体を制御します。 データベースのサポートを保証するために、注目分野の詳細をお見逃しなく。
7. しかし、SQL？ アーキテクチャの観点からエンティティで操作できる場合-操作します。 明確で有限なものの概念は、不必要な重複した関係を作成しないようにするのに役立ちます。
8. デコレーター、アダプター、ピック...これらのパターンは、新しいコードを古いレガシーに統合するための主要なパターンの1つです。
9. 計画B、または統合のためのロールバック計画。 多くはそれを忘れるという間違いを犯します。 新しい素材を注ぐとき、「何かがうまくいかない」状況では不可欠です。 つまり、アーキテクチャの構築を開始するとすぐに、すでにこの段階で、バグの場合にどのようにロールバックするかを理解する必要があります。
10. テスト（ドック）なしの新しいコードは、1週間でレガシーになります。 コードがどれほど美しいものであっても、1週間でドキュメントがなければ、そのコードはわかりにくいため「レガシー」ステータスになります。
11. テスト。 単体テストが手頃な価格でない場合、煙テスト、機能テスト、統合テストを使用します。 「仕事を美しくするために」ソースを使用して単体テストをビジネスに販売することは、どれほど現実的ですか？ 私たちの現実では、これはパターンというよりむしろ希少性です。 何らかの理由で「ユニット」でうまくいかない場合は、スモークテスト、機能テスト、または統合テストを使用し、タスクを手動テスターなどに委任できることも忘れないでください。
エピローグの代わりに
このストーリーで最も重要なことは、6つの問題のあるステージ（単純なものから複雑なものへと順番にリストされている）の遺産を残さずに作業を行うことです。
- 技術文書なし
- ビジネス文書なし
- これを開発した人はいません
- ユーザーが何を受け取るべきかはわかりません。
- 200 +各関数の使用法であり、それらはgetA（）と呼ばれます
- これを開発したい、または開発できる人はいません。