レガシーは死ぬことはありません：レガシーコードを処理する方法

“レガシーコード”という用語が出てくると、通常は軽蔑の色合いで言われたり受け取られたりします。 “レガシーコードミーム”の予備的なGoogle検索は、髪を引き裂いたり、疲れたり、非常に失望したりする人々の何百もの画像マクロを表示します。

私は6ヶ月前にソフトウェア開発者として働き始めたとき、レガシーコードが何であったのか、それを扱う作業が何を伴うのか分かりませんでした。

ジュニア開発者としての私の四ヶ月の間に、私は二、三年前に私の同僚の一人によって構築されたアプリに検索フィルターモーダルを追加するよう 私は、標準スタックを含む別のクライアントのための非常に複雑なアプリ、TypeScript/React/Redux/Redux-Sagaに取り組んで、最後の4ヶ月の大部分を費やしました。 私はすでに多くのユニークな問題を解決し、バックエンドにクエリパラメータを渡すための簡単なモーダルを作るのに十分なコーディング能力に自信をあなたが推測しているかもしれないように、それはそれほど単純ではありませんでした。

しかし、なぜ？

レガシーコードとは何か、なぜ対処するのが難しいのか

レガシーコードとは、サポートされなくなった古い技術を使用している別の開発者やチームか 多くのプログラマは、”コードが書かれるとすぐにレガシーコードになる”と言います。 “通常の”コードとレガシーコードの機能的な違いは、単にあなたが作業するのに慣れているものと比較して異なる規則を持っているということです。私の場合、私が割り当てられたアプリはTypeScriptではなくFlowを利用していましたが、慣れていたほど強く型付けされていませんでした。 これにより、バックエンドからフェッチされていたデータの構造を理解することが少し難しくなりました。 型がないため、実行時にTypeErrorsに頻繁に遭遇することがありましたが、大規模な機能を作成しているときにデバッグするのは難しい場合があります。 これに加えて、アプリははるかに古いバージョンのReactを使用していましたが、モーダルの構築に使用したいコンポーネントライブラリの互換性のあるバージ

私は落ち着きと合理性の感覚でレガシーコードを処理する方法の核心に入る前に、私はレガシーコードがすべて悪いわけではなく、レガシープロジェクト それどころか、レガシーコードに取り組むことは、柔軟で忍耐強いことを私に教えてくれました、そして何よりも、経験は私に新しい文脈で新しい視点で問題を解決する機会を与えてくれました。

実際、それは私が前述のコードベースを使い始める前よりも優れた開発者になりました。

技術的なレベルでレガシーコードに対処する方法

Photo by Jeff Sheldon on Unsplash

可能な限りドキュメントとコードコメントを読む

完璧な世界では、すべてのコードベースには、プロジェクトの仕組みの簡潔な説明、元の著者の正確なロジックを説明するコードコメント、アプリケーション全体が完璧に理にかなっている堅牢なREADMEがあります。 しかし、これはまれです。 多くのReadmeは、プロジェクトが開発されるにつれて更新されず、人々はコメントを書くことを忘れたり、彼らのロジックが新しい開発者には明らかである

コードベース全体を見てください

迷っていて、どこから始めればよいかわからない場合は、次の質問をしてください。

• アプリの
• データはどのようにアプリを介して流れますか？
• あなたの機能はどのようにアプリに適合しますか？あなたは全体像の感覚を得ることができるとき、それは問題に対処するための最善の方法を把握する方が簡単です。

あなたは全体像の感覚を得ることができたとき、それは簡単です。 たぶん、あなたは新しいファイルを作成し、新しいコンポーネントを作成する必要があります。 たぶん、あなたはユーティリティ関数を書いてそれをテストする必要があります。 どのような場合でも、あなたの問題のより広い文脈を理解することは、解決策を作成するための良い最初のステップです。

アプリを手動でテストし、可能な限り単体テストでテストします

新しい機能を追加している間にアプリを一時的に壊すことは、開発者のレベ これは正常であり、特にあなたが仕事に慣れていない場合、なじみのないスタックを持つレガシーコードベースで作業する場合、またはその2つの組み合

これらの破損が長期的な問題になるのを防ぐ最善の方法は、単体テストと手動テストの両方でアプリを徹底的にテストすることです。 これらのテストを適切に配置し、どのようなカバレッジを得るかを正確に知ることで、あなたと将来の開発者に多くの時間を節約できます。 また、厳格なテストは、アプリをよりスケーラブルにし、また、あなたのテストがきれいに実行するたびにリッテドパミンラッシュを与えます。単体テストでは、JestやJasmineのようなテストフレームワークを使用できます。

手動テストの場合は、テストマトリックスを開発し、ドキュメントが将来の開発者にアクセス可能であることを確認する必要があります。 このマトリックスでは、一連のアクション、期待される動作、テスト時の実際の動作、および重要なその他の詳細を定義する必要があります。

今後のブログ記事では、両方のタイプのテストをワークフローに効率的に実装する方法について説明します。あなたのプロジェクトがあなたの職場の現在または元従業員によって書かれたと仮定すると、他の誰かがおそらくアプリで何が起こっているか あなたの誇りを飲み込み、他の誰かに尋ねることを学ぶことは、いくつかのための不快なステップですが、開発者として成長するために必要なものであなたの時間（そして彼らの時間）を効率的に利用するための良い方法は、情報に基づいた質問を定式化することです。

あなたの時間を効率的に使 コードベース全体を見て、理解のギャップを把握してみてください。 それは彼らがあなたの問題が何であるかのより良い感覚を得るのを助けるだけでなく、それはあなたが最初にあなた自身で問題を解決しようと

損失をいつ削減するかを知る

ドアに足を踏み入れるためにあまりにも多くの時間を費やしていて、上記の手順を試した後に機能を実 あまりにも簡単にあきらめてはいけませんが、また、あなたの締め切りが何であるか、あなたのプロジェクトマネージャーがあなたから期待しているものを心に留めておいてください。つまり、そのようにするには欠点があります。

• コードを書き直すとバグが発生する可能性がありますが、これは良い単体テストで多少回避できます。
• コードを書き換えると、隠された機能を削除することができますが、これは良い単体テストで回避することもできます。
• 時間に追われている場合、機能に加えて機能の外にコードを書くことは、実際には単にその周りを構築するよりも時間がかかるかもしれません。すべてのすべてで、あなたの最高の判断を使用してください。

すべての場合、あなたの最高の判断を使用してください。 どちらの選択にも長所と短所があり、それはすべてあなたの個々の状況とプロジェクトの予算に依存しています。

心理的なレベルでレガシーコードを扱う方法

写真：Simon Migaj On Unsplash

レガシーコードを扱う技術的側面を説明したので、私たちのソフトスキルを使ってレガシーコードを扱う方法について話しましょう。 結局のところ、開発者はロボットをコーディングするだけでなく、人々であり、創造性と原作者を必要とするプロジェクトの挑戦的な問題に対処することは、あなただけでなく、あなたの同僚にとっても感情的に課税される可能性があります。

謙虚で親切であること

これは私がもっと練習する必要があることを恥ずかしそうに認めてくれるものです。 私が最初にフィルターモーダルプロジェクトを割り当てられたとき、私はコードの元の著者が私から15フィート離れて座っていた間に、コードがどのようにjankyで魅力的ではないかについてかなり声を出していました。 私のコメントは冗談であることを意図していましたが、後知恵では、私は傲慢で傷ついていたことを認識し、私はもっと共感すべきであったことを認識しています。

レガシーコードが”オフ”に見えるようになる要因はたくさんありますが、これは著者を批判したり、最悪の事態を想定したりする前に考慮する必要があ).

元の著者は、彼らがやったようにコードを書くための彼らの理由を持っていたかもしれません。

時間の制約と技術の制約は、人が動作するが必ずしも最良の規則を持っていないコードを書くことを引き起こす可能性があります。 あなたが十分な時間、時代遅れのツール、およびマイルの長さのtodoリストとの状況で自分自身を描く場合は、おそらくどちらか最高のコードを書くことは

規則が変更されます。

古いOlio Appsプロジェクトでは、コードの規則では文字列を宣言するために一重引用符を使用しており、二つのスペースは一つのタブに等しいでした。 単一のファイルの中に複数の小さなReactコンポーネントがネストされていました。 現在の規約では、二重引用符と4つのスペースを使用し、各Reactコンポーネントは、どんなに小さくても、component.tsxファイルに存在します。 そして、数年後に、私はそれも変わると確信しています。

すべてのコードは最終的にレガシーになります

これは前のポイントに戻ります：あなたのコードは最終的にレガシーになります。 あなたが年功序列のはしごを上に移動すると、新しい開発者が雇われ、古いコードを維持する必要があります。 クリーンで完璧でドライなコードを書くこともできますが、規約や傾向が変わると、新しい開発者は他の人のレガシーコードを見るのと同じようにコードを見

小さな成功に誇りを持ってください

あなたの習慣的な慣習の外で働くことは容易ではありません。 母国語以外の言語を学んだことがある場合は、第二言語の単語や用語を忘れても、母国語で覚えていて、ギャップを越えて翻訳することはできません。 同じことが、現代の慣習と従来の慣習の間で変化することにも当てはまります。 時々それはちょうどあなたの軸受けを取り戻すために分を取る。

レガシーコードを正常にナビゲートすることができることで、あなたは適応可能であるためにあなたの能力を示しています,これは、あなたの現在の レガシーコードは、このスキルを練習するのに最適な遊び場です。

結論として：

この時間を使用して、独自のコード記述を強化します

レガシーコードベースで作業した経験があるので、ツールや規則の面で好きで好きではないものをより良い感覚でそれから離れてくるべきです。 これらは、あなたが将来のプロジェクトに続けていくことができ、他の人のコードを見直し、建設的な批判を提供し、指導を与えることであなたをより良くすることができます。

ユーザーと将来の開発者のためのアプリを開発する

優れたドキュメントやコードコメントの経験があるか、ドキュメントやコードコメントがないかにかかわらず、ドキュメントとコメントの両方が将来の開発者がプロジェクトをナビゲートするのに役立つ強力なツールであるかを見ることができます。 ドキュメントを維持し、有益なコードコメントを残すことは、そのギャップを埋めるための良い方法です。

あなたのコードもいつかレガシーになることを忘れないでください

私はすでにこれを数回言及しましたが、コードとロジックがどれほど乾いていても、あなたのコードもレガシーになることを繰り返すことが重要です。

最も重要なお持ち帰りは、柔軟で謙虚であることであり、あなたは間違いなく古いコードから新しいトリックを学ぶことができます。