レガシーコードを扱うことは、プログラマーとして進化するのに役立ちますか？[閉まっている]

私はJava開発者であり、1年以上の経験があり、中級以上の開発者ではありませんが、ジュニアのどこかにいるようです。最近、私は既存の銀行業務アプリケーションコードを4か月間研究し、必要に応じて変更を導入するという長期プロジェクトを提供されました。あまり経験のないプログラマーとして、私は開発する方法を探していて、そのようなプロジェクトが何をもたらすのだろうかと思っています。

大きくておそらくあまり良くない書かれたアプリケーションを扱うことは初心者にとって良い習慣だと思いますか？

既存のコードのトラブルシューティングは、プログラマーとして開発するための優れた方法です。コードが悪い場合、あなたは彼らが犯した間違いの影響を学び、おそらくあなたが設計をしているときにそれらのいくつかを避けるでしょう。コードが適切であれば、保守可能なアプリケーションを作成する方法について何かを学びます。

また、実際のビジネスアプリケーションの複雑さに対処する方法も学びます。これは銀行部門であるため、連邦規制や内部会計管理など、考えもしなかったようなことについて学習します。これらは、金融業界で他の何かを設計するように求められたときに知っておくと良いことです。また、金融プログラミングは非常に有利なセクターになる可能性があるため、銀行の経験を積むことは非常に有益です。

何かを15年前に書いたからといって、あなたが使いたくない言語で書かれているからといって、それが必ずしも悪いわけではないことさえ知っているかもしれません。結局のところ、すべて正常に実行されています。

ほとんどのレガシーアプリと同様に、アプリケーションに単体テストがない場合、変更が他の何かに影響しないことを本当に確認する必要がある場合、そのテストを追加する方法と、そのテストを追加する理由を管理する方法を学ぶことができます良いアイデア。

初心者にとっては素晴らしい練習だと思います。他の経験から学ぶことは非常に効果的です。

本当の課題は、間違いを見つけることではなく、他の開発者の頭に入り込んで、whyそのように書かれたコードを理解しようとすることです。時々それは彼らがずさんだったからであり、時にはそれは彼らが非常に正当な理由を持っていたためです。開発者は少なくともあなたと同じくらい良かったが、より多くのドメイン知識があるかもしれないと仮定します。

これは、開発者にとって、キャリアのどの時点でも良い習慣です。既存のソフトウェアをレビューおよび分析し、それを改善する方法を見つけることができれば、あなたは価値のある開発者であることを実証できます。他の人がソフトウェアをどのように設計および開発したかを学ぶだけでなく、やるべきでないことを学びます。

あなたが挑戦に立ち向かうなら、このプロジェクトに真正面から取り組み、改善してください。

それは絶対に役立ちますが、注意する必要があります。

レガシーコードから学習する必要があります。何が良いのか、何が悪いのかをどうやって知るのですか？たぶん、さまざまなパターン/メソッドの長所と短所を認識することができますが、あなたが始めたばかりのジュニア開発者だった場合、あなたはできないかもしれません。

そして、その最初の仕事にあまりにも長く留まると、あなたは十分なスキルを学んだり、構築したりせず、そこで行き詰まってしまうかもしれません。

レガシーは何でも意味しますが、「あまりよく書かれていない」コメントに基づいて、レガシーは「悪い」または少なくとも「最新ではない」テクノロジーとパターンを意味すると仮定します。レガシーコードが適切な場合は、そのコードのすべての行をbackしんで学習しないでください。

あなたのキャリアを転換し、今日までこのスレッドの価値のない流し穴に立ち往生させるような種類の仕事やプロジェクトに対して十分な警告があるとは思わない。

スポーツの類推アラート：NFLのラインバッカーは、最悪の記録または最高のチームでプレーすることで、より多くのことを学び、より貴重になると思いますか？私の答え：彼らは最高のチームでプレーしたことでより価値があるだけでなく、おそらくベストプラクティスや知識を習得し、キャリア終了のプラクティスや態度を取り上げることを避けました。

実際にビジネスのために働き、多くの開発者の給与を支払うひどいアンチパターンコードがそこにたくさんあります。「正しい」方法で十分なコードが実行されていない開発者は、アンチパターンコードを問題の正当な解決策と間違える可能性があることを提案します。企業はソリューションは機能していると言うかもしれませんが、履歴書に書きたいものでも、他の開発者に自慢するものでもありません。これは、個人の成長経路にエンジニアリングピアの尊敬を得ること、そしてあなたが働いている会社の収入を一時的に増やすことだけが含まれている場合にのみ関係します（悪いことに聞こえますが、最終的に、最高のエンジニアリングがIMOを最大限に稼ぎます） 。

残念ながら、技術的な負債が明らかになるまでに多くのコードと時間がかかります。そして、その技術の負債は通常、手遅れになったときに正確に認識されます。技術的な負債やアンチパターンを以前に止めようとした人は誰でも、余分な費用が認識されたり、スケーラビリティなどの理解が不足しているために脇に追いやられていたかもしれません。技術的負債をすぐに明らかにすることは、エンジニアとしての私たちの義務です。経験豊富なエンジニアのいないプロジェクトは、ある時点でレンガの壁にぶつかる危険にさらされています。実際には、才能のある開発者を含むすべてのプロジェクトです。ほとんどの企業は、「ある時点」を後で修正するのに十分な時間だと考えています。これにより、新進気鋭の開発者の仕事の選択が非常に複雑になります。また、開発者とビジネスの間のまったく異なる目標と考え方、およびギャップを埋めるのがどれほど複雑であるかも指摘しています。

エンジニアの目標は、実際の科学的作業と設計の考慮事項を「含める」ことであり、ビジネスの目標は、不要なコストと時間を「除外」することです。エンジニアが最終状態が実際に行われるまでの労力と時間のレベルを知らないことがよくあるため、ソフトウェア開発は、アジャイル、スクラム、かんばんなどのキャラクターが主役を演じる優れたドラマのように展開します。

1つは、「破損」しないように十分な良いコードが見つかるまで、悪いコードから離れることです。上級開発者が複雑な問題に対するシンプルなソリューションを作成するという言葉が大好きです。賢明なように、中級レベルのジュニア開発者は、単純および複雑な問題に対する複雑なソリューションを作成します。

別のポイントは、理解を深めるために、さまざまなポイントで良いコードと悪いコードに取り組む必要があるということです。どちらも行っていない場合は、より良いシステムに出会ったときにそれを学び、すべてを解く準備をしてください。これはおそらくほとんどの開発者にとってより一般的な軌道だと思います。

私は非常に複雑な「秘密のソース」の山に登っているような気がしているので、今年は偏っています。これまでに見た最悪のパターンのいくつかを解読する能力を高めますが、それは「カスタム」と「オフ」であるため、私の闘争が私の将来の市場性や使用可能なスキルセットを向上させるとは思いません。

私の正気を保つために、私は着実にペースを取りながら、コースの標準としてすべての道路ブロックを受け入れています。このレガシーホールからの掘り出しを含む、私の上司との私の年間目標を見直したところで、私はそれが犠牲的な上昇であるかもしれないと思っています。悪いレビューと知覚された遅さでプロセスを生き残ることができました。これは、どのような仕事をするのか疑問に思っている人にとっては現実的で予見できない警告です。

免責事項：この投稿は私の意見よりもはるかに長生きするため、一粒の塩を使用してください。明日はレガシーコードが好きかもしれません！（疑わしい）。

このコンテキストで「レガシー」をどのように定義するかに大きく依存します。CとC ++の例を挙げましょう。多くのC ++プログラマーは、C ++アプリケーションでC文字列を使用することを悪い習慣と呼んでいます。他の人はミキシングを必要としません。レガシーコード。さらに進んで、C ++ X以前（ 'X'を適切な数字に置き換える）の標準的なイディオム、つまり「レガシー」スタイルの構文を使用することを避けます。

C ++ストリームと文字列のパフォーマンスの問題、およびいくつかのSTLの特性は別として、非常に愛されているプリプロセッサディレクティブの内容を確認することは素晴らしい習慣#include <string.h>です。実装へのパスをたどって、unix / linuxマシンで/usr/include/string.h（そしてgnu.orgなどからlibc実装ソースを入手して）読んで、strcmp.cまたはstrlen.cまたはを読んだ場合strtok.c、「なんて美しい世界」 「フェーズイン。

ただし、この散文には警告があります。つまり、非推奨のクラスとメソッドです。Javaでは、最近の環境からかなり多くのレガシーなものにアクセスできますが、すべてを思い出すのではなく、正しく思い出せば。IBセクターでは、私自身の経験から、すべてのソフトウェアが優秀なプログラマーによって作成されているわけではありません。多くの卒業生は、アナリスト/開発者の職に就く前に、実際のプログラミングをほとんど経験していませんでした。ただし、このステートメントを一般化しないでください。高スループット、低遅延環境の中核でJavaとC＃を採用している多くの人々を知っています。私は彼らに同意しませんが、幸いなことに、これは彼らのビジネスです。しかし、彼らが本物のHFTを行っていたら、彼らは遅れをとっていました。しかし、再び、この文から簡単に推測できるのは、Javaコードが高度に最適化可能であるという仮定（および多くの場合、事実）です。必要に応じて、これを修正するだけでなく、最適化に秀でることができれば、開発者として非常に貴重になります。あなたがどれだけ貢献したかを理解する方法はとても満足です。行きたいです。