通常、このコードは、かなり長い間市場に出回っている製品のリリースに従事している食品会社の主力ソリューション内で見つけることができます。
古いコードの問題が1つの記事に収まらないことをすぐに言わなければならないので、私は苦痛をいくつかの部分に分けました。 今日は、「古いコード」の違いを説明します。 次の記事では、コードの記述、プロジェクトの管理、ビジネスとのコミュニケーションの経験に基づいて、その対処方法についていくつかの考えを書きます。
健康と経済
通常、古いコードは100％実行可能です。 または、正直なところ、95％。 痛みは、システムに変更を加える必要がある場合、特に変更がフローティングバグの出現につながる場合に始まります。これは通常、対処にほとんどの時間を必要とします。
クラシックでは、手遅れになる前に定期的にそのようなシステムをリファクタリングすることをお勧めします。 ただし、ここには経済的要因が含まれており、以下で説明します。
古いコードの変更は、技術的にだけでなく、簡単ではありません。 古い生産コードは、ビジネスで数百万ドルを稼ぐことができるソリューション（非常に頻繁にフラグシップ）を構築しました。 したがって、このようなコードを使用する場合、チームに経済的な制限が課されるほど技術的ではありません。
変更は多数のユーザーに影響し、製品の安定性に悪影響を及ぼす可能性があります。 製品が主力製品であり、会社に多額の資金をもたらす場合、安定性の侵害は会社にきちんとしたコストをかける可能性があります。 この場合、システム管理者の息子についてのジョークは、可能な限り正確に状況を説明します。「それでは、神のために、何も触れないで、何も変えないでください！」
明らかに、このような保守的な雰囲気では、変更は少なくとも非常に望ましくなく、多くの利害関係者との慎重な調整なしでは不可能である可能性が高いです。 また、ビジネスのニーズによって変更が決定される場合（通常、これらは新しい機能または現在の機能を改善しようとするものです）、「リファクタリング」または「すべてを再度書き直す」よりも、変更を正当化する方がはるかに簡単です。
リファクタリングをビジネスに正当化する方法は、別の記事のトピックです。 つまり、次の3つの要因が収束する必要があります。
- 企業は製品に大きな変更を加える必要があるはずです。
- 企業は、既存のシステムに変更を加えることは長くて費用がかかるか、不可能であることを認識しなければなりません。
- リファクタリング/リライトの必要性をビジネスに正しく「販売」しなければならない有能な開発マネージャーが必要です。
ご覧のとおり、3つの要因のうち、2.5年はビジネスのニーズに応じて変化し、追加のリスクを負います。 残念ながら、これらの要因は、レガシーコードを使用して作業することで開発者/管理者がどれだけ苦労するかにはほとんど依存しません。
知識の達人
ところで、非常に多くの場合、古くてひどいレガシーコードにさえ変更を加えることは、迅速かつ多かれ少なかれ効率的に行われます。
通常、これはエキスパートの達人がコードを操作するときに起こり、ロジックのすべての複雑さを念頭に置いて、現在の実装にプラスチシンの別の塊を非常に迅速に追加できます。
この場合、すべてがはるかに複雑になります。一方で、ビジネス要件は時間どおりに満たされ、「完全に」完了します。 一方、最も経験豊富で高度なプログラマーでさえ、巨大なシステムのすべての機能を頭の中で保持することはできず、変更を加えると（コードの完全に異なる端で何かがいつの間にか落ちる）。 これは、複数のコマンドが同じコード（それぞれ独自の方法）を使用している場合に特に頻繁に現れます。
言うまでもなく、他の誰かがこのコードを操作しようとすると、莫大な人件費が発生します。 著者の達人は「RAM内」のコードに関する知識を保持し、（幸運なら）松葉杖の詰まりの歴史を覚えていますが、新しいプログラマーは、何世紀も前の苔で生い茂った松葉杖の複雑さを歩き回って、最初からレガシーデバイスを理解しなければなりません。
さて、バスファクターを忘れてはなりません。 「同じ」プログラマーが退職すると、コードは徐々にカボチャに変わり始めます。 ところで、著者が去った後のそのようなコードの作業時間は彼のスキルに正比例し、数年に達する可能性があります。 しかし、残念ながら、「作業」は「開発」を意味するものではなく、そのようなコードを変更することは単に不可能であるか、システム全体を破壊します。
複雑なロジック
ここではすべてがシンプルです-コードを使用して長年にわたって、さまざまな徹底度を持つさまざまな人々によって多くの変更が加えられたため、誰も元のロジックを覚えていませんが、おそらく前の段落の同じ教祖はすべてがどのように機能するかを知っています（それも完全ではありません）。 これはすべて、文書の欠如と単体テスト（理想的には）も文書と見なすことができるために悪化します。
古いドキュメントと単体テスト
この段落（以前のすべての段落と同様）は、一般的な規則ではありません。 私は何十年もの間、テストで完全にカバーされ、優れたドキュメントを備えたコンポーネントを見てきました。 しかし、そのような要素はブラジルの祖母の美人コンテストの参加者により似ています-それらは少数であり、他のものは同等ですが、それらは非常にまれですが、それらが何歳であるかを見ると完全に不可能です。
コードが文書化されておらず、ユニットテストが記述されていない理由は、別の大きな話です。 しかし、もちろん、主な理由は時間の不足です。 特に意識的なチームは、ソフトウェアを書く段階でドキュメントを書くことさえあります（特に意識的なPMはこの時期を計画しています）。 しかし、私たちの変化する世界とビジネスからの要求の流れでは、そのようなドキュメントのサポートは困難なタスクに変わり、貴重な開発時間のかなりの費用が必要になります。 コードに加えて、変更ごとに、テキストのいくつかの段落を作成または修正する必要があると想像してください！
その結果、遅かれ早かれ、ドキュメントは「昨年のようでしたが、すべてが変わった」レベルでフリーズします。 残念ながら、ドキュメンテーションのパラドックスは、それが本当に必要なところです-最も複雑で、混乱し、一見して非論理的でさえ、その執筆とサポートは不当な時間と労力を要し、通常延期されます。
ユニットテストでもほぼ同じことが起こります。 私は正直に認めます：ほぼ完全なカバレッジでユニットテストを記述および維持しようとするすべての試みの記憶の中で、メインコードが記述される前にテストのインフラストラクチャとテスト自体が記述されたとき、正直なTDDスキームのみが統合されました。 システムの作成後にテストを作成しようとすると、通常は失敗するか、最小限のカバレッジ（通常はテストが最も簡単なコード）に制限されていました。
一方、テストにはドキュメントと同じサポートが必要ですが、適切なレベルのテストでカバーされているプロジェクトは本質的にはるかに一般的です。 おそらく、テストを書くことはプログラマーによってコードを書くと認識されますが、「ドキュメントを書くことはテクニカルライター向けです」。
次は？
この投稿が有用というよりも概要であることが判明したことを理解しています。 この省略を修正するために、次の「問題」では、コードの早期老化を回避する方法と、古い時代でもコードがきれいで美しく維持され、 Jane Fondaのように見えるようにする方法についての考えを共有します。
テーマの続き： コードのメンテナンス。 リファクタリングをビジネスに販売する方法