レガシーコードを扱うことは、プログラマーとして進化するのに役立ちますか？
私はJava開発者で、1年以上の経験があり、ジュニアより上のどこかにいるのですが、まだ中間レベルの開発者ではありません。最近、長期プロジェクトが提供されましたこれは、既存の銀行業務アプリケーションコードを4か月間調査し、必要に応じて変更を導入することです。あまり経験のないプログラマーとして、私は開発方法を探しています。そのようなプロジェクトが何をもたらすか疑問に思います。
大きくてあまりよく書かれていないアプリケーションを扱うことは、初心者にとって良い習慣だと思いますか？
既存のコードのトラブルシューティングは、プログラマーとして開発するための優れた方法です。コードが悪い場合、あなたは彼らが犯した間違いの影響を学び、そしてあなたが設計をしているときにおそらくそれらのいくつかを避けるでしょう。コードに問題がなければ、保守可能なアプリケーションの作成方法について学びます。
また、実際のビジネスアプリケーションの複雑さに対処する方法についても学びます。これは銀行部門なので、連邦規制や内部会計管理など、今まで考えたこともないようなことについて学びます。これらは、金融の世界で何か他のものを設計するように求められたときに知っておくと良いことです。そして、金融プログラミングは仕事をするのに非常に有利なセクターになる可能性があるので、銀行の経験を積むことはあなたにとって非常に良いかもしれません。
何かが15年前に書かれたからといって、使いたくない言語で書かれているからといって、それが必ずしも悪いわけではないことを学ぶかもしれません。結局のところ、それは今までずっと成功してきました。
ほとんどのレガシーアプリと同様に、アプリケーションにユニットテストがない場合、変更が他に影響を及ぼさないことを本当に確認する必要がある場合、そのテストを追加する方法と、そのテストを追加する理由について管理を販売する方法を学ぶことができます。良い考えです。
私はそれは素晴らしい練習だと思います 初心者 誰でも。他の経験から学ぶことは非常に効果的です。
本当の課題は、間違いを見つけることではなく、他の開発者の頭の中に入り、whyコードがそのように記述されているかを理解することです。ずさんなことが原因である場合もあれば、まったく正当な理由があったためである場合もあります。開発者は少なくともあなたと同じくらい優秀だったと思いますが、より多くのドメイン知識を持っているかもしれません。
これは、開発者のキャリアのどの時点でも、良い習慣です。既存のソフトウェアを確認して分析し、それを改善する方法を見つけることができれば、自分が貴重な開発者であることを実証できます。他の人がソフトウェアを設計および開発した方法を学ぶだけでなく、その過程で何をすべきかnotを学ぶことができます。これは、それ自体が貴重な知識です。
挑戦する準備ができている場合は、このプロジェクトに真正面から取り組み、より良いものにしてください。
レガシーは何でも意味しますが、あなたの「あまりよく書かれていない」コメントに基づいて、レガシーは「悪い」または少なくとも「時代遅れ」のテクノロジーとパターンを意味すると思います。レガシーコードが適切な場合は、そのコードのすべての行を理解して学習しないでください。
私はあなたのキャリアをそらし、今日までこのスレッドの価値のないシンクホールに行き詰まるような仕事やプロジェクトに対する十分な明確な警告はないと思います。
スポーツのアナロジーアラート：NFLのラインバッカーは、最悪または最高のチームとプレーすることで、より多くを学び、より価値があると思いますか？私の回答：彼らは最高のチームでプレーした方がより価値があるだけでなく、おそらくベストプラクティスと知識を身につけ、キャリアの終わりのプラクティスと態度を身につけることを避けました。
実際にビジネスで機能し、多くの開発者の給与を支払う恐ろしいアンチパターンコードがたくさんあります。十分なコードが「正しい」方法で実行されたことを確認していない開発者は、アンチパターンコードを問題の正当な解決策と誤解する可能性があることを提案します。ソリューションはうまくいくとビジネスは言うかもしれませんが、それはあなたがあなたの履歴書にあなたが望むものでも、他の開発者に自慢するものでもありません。これはまた、あなたの個人的な成長の道があなたのエンジニアリング仲間の尊敬を得ることと、あなたが働いている会社の収入を一時的に増やすことだけではない場合にのみ関係します（悪いように聞こえますが、結局、最高のエンジニアリングは絶対に最も多くのお金をIMOにします） 。
残念ながら、技術的な負債が明らかになるまでには、多くのコードと時間がかかります。そして、その技術的負債は通常、手遅れであるときに正確に認識されます。以前にテクノロジーの負債や反パターンを阻止しようとした人は誰でも、余分な費用を認識したり、スケーラビリティーへの理解が欠如したりしたために辞任された可能性があります。技術者の借金を直ちに公開することは、エンジニアとしての私たちの義務です。経験豊富なエンジニアのいないプロジェクトは、ある時点でレンガの壁にぶつかる危険にさらされています。ほとんどの企業は、「ある程度のポイント」を後で修正するための十分な時間と見なしています。これは、将来の開発者にとっての仕事の選択を非常に複雑な問題にします。また、開発者と企業の間のまったく異なる目標や考え方、ギャップを埋めるのがいかに複雑であるかも指摘しています。
不必要なコストと時間を「除外」することがビジネスの目標である一方で、実際の科学的作業と設計の考慮事項を「含める」ことがエンジニアの目標です。エンジニアは、最終レベルが実際に完了するまでの労力と時間のレベルを知らないことが多いため、ソフトウェア開発は、アジャイル、スクラム、かんばんなどのキャラクターが主役を演じる優れたドラマのように行われます。
1つの注意点は、「破損」しないように十分な適切なコードが見つかるまで、不良コードに近づかないことです。上級開発者が複雑な問題の簡単な解決策を作成するという言葉が大好きです。同様に、中級レベルのジュニア開発者は、単純な問題と複雑な問題の複雑なソリューションを作成します。
もう1つの注意点は、理解を深めるために、さまざまな時点で良いコードと悪いコードに取り組む必要があるということです。どちらも実行していない場合は、それを試して、より良いシステムに出会ったときにすべてを習得しないように準備してください。これはおそらく、ほとんどの開発者にとってより一般的な軌道です。
非常に複雑な「秘密のソース」の山を登っているような気分なので、今年は偏っています。私が今まで見た中で最悪のパターンのいくつかを解読する能力を高めますが、それは非常に「カスタム」で「1回限り」であり、私の闘いが私の市場性や将来の使用可能なスキルセットを向上させるとは信じていません。
私の正気を保つために、私は着実にペースを上げて進み、すべての障害物をコースの標準として受け入れています。このレガシーホールを掘り下げることを含む上司と一緒に私の年間目標を検討したところ、私はそれが犠牲的な上昇であるかもしれないと考えています。私は悪いレビューと遅いと感じてプロセスを生き残ることができました。これは、どのような仕事をするべきか疑問に思っている人たちへの現実的で予断を許さない警告です。
免責事項：この投稿は私の意見よりもはるかに長く存続するので、一粒の塩でそれを取りなさい。明日はレガシーコードが好きかもしれません！ （疑わしい）。
それは絶対に役立ちますが、注意する必要があります。
レガシーコードから学ぶことを確認する必要があります。何が良くて何が悪いかどうやって分かりますか？たぶん、さまざまなパターン/方法の長所と短所を認識できるかもしれませんが、ジュニアデベロッパーが始めたばかりの場合は、認識できない可能性があります。
そして、その最初の仕事に長すぎると、十分なスキルを習得したり構築したりできず、そこで行き詰まる可能性があります。
これは、この文脈での「レガシー」の定義方法に大きく依存します。 CとC++の例を挙げましょう。多くのC++プログラマーは、C++アプリケーションでC文字列を使用することを悪い習慣と呼んでいます。他の人は、ミキシングを要求しない一方で、古いので、Cコードのビットを使用することはまったく無意味であると主張しています。レガシーコード。さらに進んで、C++ Xより前（「X」を適切な数に置き換える）の標準イディオム、つまり構文、つまり「レガシー」スタイルを使用しないようにしています。
C++ストリームと文字列のパフォーマンスの問題、およびいくつかのSTLの特殊性は別として、非常に愛されているプリプロセッサディレクティブ#include <string.h>の内部を確認することは非常に良い方法です。実装へのパスをたどり、/usr/include/string.hにあるunix/linuxマシンで自分を見つけた場合（そして、たとえば gnu.org からlibc実装ソースを取得）、strcmp.cまたはstrlen.cまたはstrtok.c、「なんと美しい世界」が段階的に聞こえるのかと思います。
ただし、この散文には警告があります。つまり、非推奨のクラスとメソッドです。 Javaでは、最近の環境からはまだ多くのレガシーのものにアクセスできますが、正しく思い出せば、すべてではありません。IBセクターでは、私の経験から、まあ、すべてのソフトウェアではありません優秀なプログラマーによって書かれています。多くの卒業生は、アナリスト/開発者の立場から始める前に、実際のプログラミングにほとんど触れていませんでした。しかし、このステートメントを一般化しないでください。JavaとC＃は高スループット、低レイテンシの環境の中核です。私はそれらに同意しませんが、これは幸いにも彼らのビジネスです。彼らが本当のHFTに移行していれば、彼らは押し寄せました。しかし、この文から簡単に推測できるのは、Javaコードは非常に最適化可能であるという仮定（および多くの場合、事実）です。そして、必要に応じて、最適化でExcelを実行できる場合、これを修正するだけでなく、あなたは開発者としてかけがえのない存在になるでしょう。あなたがどれだけ貢献しているかを理解する方法によって、それは非常に満足しています。またはそれ。