タグ付けされた質問 「legacy-code」

元々のレガシーコードは、作成者または以前のプログラム/システムバージョンから「継承」されたコードを意味していました。Michael Feathersが「レガシーコードを効果的に使用する」本を出版して以来、テストのないコードがレガシーコードであるという新しい定義が生まれました。

20
失敗に向かうプロジェクトで開発者としてどのように振る舞うべきですか?
私は5人のメンバーからなるチームの開発者であり、私たちのプロジェクトは災害に向かっていると信じています。理由をすぐに説明しますが、私の質問は次のとおりです。 締め切りは1.5か月で、私たちが何をしようとも、このプロジェクトは失敗するでしょう。私はただプロジェクトを終了して時間を無駄にするのをやめるべきだと思うが、政治的に私たちのマネージャーがそうすることは不可能だと思う。 この場合、どうすればよいですか?余分な努力をする必要がありますか、それとも簡単に取る必要がありますか?そして、私はマネージャーに何を言うべきですか? このプロジェクトが失敗に向かう理由: 期限が近づいているため、必要不可欠な機能の多くは終了していません アプリケーションが不安定で使用が非常に難しい システムは非常に複雑で、コードを理解するのが非常に難しく、変更するのは非常に難しい-データモデルは複雑なリレーショナルデータベース(100以上のテーブル)によって駆動されている 不明確なリーダーシップ。マネージャーは、大きな変更を伴う新しい情報に対応します 自動テストやユニットテストはほとんどありません 他のシステムに大きく依存していますが、統合テストはまだありません 実際、私たちは実際にこのプロジェクトを(混乱と共に)数か月前から同じマネージャーの別の開発チームから1〜2か月前に継承しました。

9
従来のコードベースでの時間コストの見積もり
最近、非常に古いモノリシックアプリケーションをマイクロサービスベースのアーキテクチャに移行するプロジェクトに取り組み始めました。 レガシコードベースは非常に乱雑(「スパゲッティコード」)であり、見かけ上単純な関数(例:「multiplyValueByTen」と呼ばれる)はしばしば「3つの異なるスキーマにまたがる10個のテーブルを含む数千行の検証コード」として現れます。 今、私の上司は、新しいアーキテクチャで機能Xを作成するのにどれくらいの時間がかかるかを(正しく)尋ねています。しかし、現実的な見積もりを思い付くのは困難です。多くの場合、上記の理由によりタスクを非常に過小評価しており、時間内に終わらないので困惑しています。 賢明なことは、実際にコードに入り、すべてのブランチと他の関数の呼び出しに注意して、時間コストを推定するように見えるかもしれません。しかし、古いコードを文書化することと、実際に新しいバージョンを書き留めることの間には、ごくわずかな違いがあります。 このようなシナリオにどのようにアプローチすればよいですか? レガシーコードのリファクタリングの仕組みを完全に理解していますが、私の質問は「リファクタリング/リライトの方法」ではありません。しかし、「パートXのリファクタリング/リライトにどれくらい時間がかかるか」に対する現実的な答えを与えることについては。

10
完全なリファクタリングの時間がないときに、レガシーコードのテストを書くことは理にかなっていますか?
私は通常、「Legacy Cod eで効果的に作業する」という本のアドバイスに従うようにしています。依存関係を壊し、コードの一部を@VisibleForTesting public staticメソッドと新しいクラスに移動して、コード(または少なくともその一部)をテスト可能にします。そして、新しい関数を変更または追加するときに何も壊さないことを確認するテストを作成します。 同僚は、私はこれをすべきではないと言っています。彼の推論: 元のコードはそもそも適切に動作しない可能性があります。また、開発者もテストを理解して変更する必要があるため、テストを作成すると将来の修正や変更が難しくなります。 何らかのロジック(〜12行、2〜3 if / elseブロックなど)を備えたGUIコードの場合、テストは簡単ではないので、テストを行う価値はありません。 同様の悪いパターンは、コードベースの他の部分にも存在する可能性があります(私はまだ見ていませんが、かなり新しいです)。1つの大きなリファクタリングですべてを簡単にクリーンアップできます。ロジックを抽出すると、この将来の可能性が損なわれる可能性があります。 完全なリファクタリングの時間がない場合、テスト可能な部分を抽出してテストを書くことを避けるべきですか?これに不利な点はありますか?

8
従来のコードベースの品質基準の低下に反対する方法 [閉まっている]
ここには、想像できない悪いコードを含む大規模なレガシーコードベースがあります。 現在、いくつかの品質基準を定義し、それらを完全に新しいコードベースだけでなく、レガシーコードに触れる場合でも満たすことを望んでいます。 そして、すでに数千件の違反があるSonar(コード分析ツール)でそれらを実施しています。 ここで、レガシーのこれらの違反を減らすための議論が行われました。レガシーだからです。 議論は読みやすさの規則についてです。ネストされたifs / for ..の数など。 さて、レガシーコードのコーディング品質の低下に反対するにはどうすればいいですか?

4
「レガシーコード」というネガティブ用語の由来は何ですか
誰もがソフトウェア開発のレガシーコードについて語っていますが、過去10年間に、コードベースを悪いものとして表現するために使用される用語を聞いたことがあります。 プログラマにも同様に強力な意味合いを持つこの用語はどこから生まれたのでしょうか? この用語を開拓したソフトウェア開発に関する本が必ずあるはずです。「レガシーコード」という用語の起源を特定したいと思います。

2
歴史的に成長したソフトウェアに名前付きのアンチパターンはありますか?[閉まっている]
複数の開発者がシステムに新しい機能を追加しただけで、アーキテクチャ全体を実際に監視したり、リファクタリングを実行したりしない、歴史的に成長したソフトウェアシステムを説明するアンチパターンはありますか? これは、管理者/顧客が絶えず新しい機能を要求し、誰も何もリファクタリングせず、他の開発者が以前に行ったことに追加するだけの場合に起こると思います。 開発者がソフトウェアシステムに圧倒されており、現在どのように機能するかを実際に理解していないため、コードをリファクタリングして変更するのではなく、最後にコードを追加/接着するだけの場合もあります。 そのため、時間の経過とともに、システムの保守がますます難しくなっています。 (これらの種類のアンチパターンの写真は、プログラミング全体に誰もがこれをより明確にするためにありますか?全体的なデザインを考えずに機能を追加するだけで構築された車のように。後方に移動しながらトレーラーを牽引し、エンジニアが車両の前面に牽引バーを溶接するだけです。作業は完了しました。しかし、カウルはもう開きません。)

8
膨大な数の失敗したテストに対処する方法は?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私はJavaで書かれた古いプロジェクトの開発に取り組んでいます。LOCは1,000万を超え、さらに悪いことに、4000を超える機能テストがあります。 Hudsonによってスケジュールされたテストは、大きなコード変更のたびに狂ったように失敗しています。テストの失敗の検証-製品またはテストに問題がある場合、数か月かかります。何をテストしているかわからないため、古いテストを削除することはできません! 私たちにできることは?そのような量のレガシーテストをどのように進めるのですか?

6
レガシーコードを扱うことは、プログラマーとして進化するのに役立ちますか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私はJava開発者であり、1年以上の経験があり、中級以上の開発者ではありませんが、ジュニアのどこかにいるようです。最近、私は既存の銀行業務アプリケーションコードを4か月間研究し、必要に応じて変更を導入するという長期プロジェクトを提供されました。あまり経験のないプログラマーとして、私は開発する方法を探していて、そのようなプロジェクトが何をもたらすのだろうかと思っています。 大きくておそらくあまり良くない書かれたアプリケーションを扱うことは初心者にとって良い習慣だと思いますか?

5
過剰なメソッドのオーバーロードを避ける方法は?
アプリケーションのソースコードには非常に多くの場所があり、1つのクラスには同じ名前で異なるパラメーターを持つ多くのメソッドがあります。これらのメソッドには、常に「前の」メソッドのすべてのパラメーターと1つ以上のパラメーターがあります。 それは長い進化(レガシーコード)とこの考え方の結果です(私は信じています): 「Aを実行するメソッドMがあります。A+ Bを実行する必要があります。わかりました。新しいパラメータをMに追加し、そのための新しいメソッドを作成し、Mから新しいメソッドにコードを移動します。 1つの以上のパラメータで、あそこA + Bを行うと、新しいパラメータのデフォルト値をMから新しいメソッドを呼び出します。」 以下に例を示します(Javaに似た言語): class DocumentHome { (...) public Document createDocument(String name) { // just calls another method with default value of its parameter return createDocument(name, -1); } public Document createDocument(String name, int minPagesCount) { // just calls another method with default value of its parameter …

5
リファクタリングするコードのテストを書くのはなぜですか?
私は巨大なレガシーコードクラスをリファクタリングしています。リファクタリング(私は推測する)はこれを支持します: レガシークラスのテストを書く クラスから一体をリファクタリングする 問題:クラスをリファクタリングしたら、ステップ1のテストを変更する必要があります。たとえば、以前は従来のメソッドにあったものが、代わりに別のクラスになる場合があります。1つの方法でしたが、現在はいくつかの方法である場合があります。レガシークラスの全体像が何か新しいものに抹消される可能性があるため、ステップ1で記述するテストはほとんど無効になります。本質的に、ステップ3を追加します。テストを大量に書き換えます。 リファクタリングの前にテストを書く目的は何ですか?それは自分自身のためにより多くの作品を作成する学術的な運動のように聞こえます。現在、このメソッドのテストを書いていますが、物事をテストする方法と、従来のメソッドがどのように機能するかについて詳しく学んでいます。レガシーコード自体を読むだけでこれを学ぶことができますが、テストを書くことは、その中に鼻をこすりつけることと、別のテストでこの一時的な知識を文書化することにほとんど似ています。したがって、この方法では、コードが何をしているのかを学ぶ以外にほとんど選択肢がありません。私はここで一時的なことを言いました。なぜなら、コードを完全にリファクタリングし、ドキュメントとテストのすべてがかなりの部分で無効になるためです。ただし、私の知識は残り、リファクタリングの新鮮さを保つことができます。 それがリファクタリングの前にテストを書く本当の理由ですか?コードをよりよく理解するのに役立ちますか?別の理由があります! 説明してください! 注意: この投稿があります:完全なリファクタリングの時間がないときにレガシーコードのテストを書くことは理にかなっていますか?しかし、「リファクタリングの前にテストを書く」と言いますが、「なぜ」とは言いません。

5
何年もの間、彼らのチームが製品革新に欠け、プロジェクト管理方法論を使用せず、悪いソフトウェア開発プラクティスを維持していた場合、開発者として何をすべきか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 何年も変更されておらず、最終的に製品とチームの障害につながる現在のソフトウェア開発プロセスに対処する方法を知りたいと思っています。はい、おそらくこれを解決するより簡単な方法は仕事を変えることですが、この経済では言うよりも簡単です。ただし、特定の例があり、同じ状況で複数回見たり、経験したことがあり、これらの問題に対処する最善の解決策が会社を辞めることだと思う場合は、回答をサポートしてください。重要なのは、特にこの問題に関する複数の専門家が最終的なルートがルートAであることを示す場合、この質問には本当に答えがあるということです。 私は、多くの開発者が同じような状況にあったことを知っています。これは、企業が市場で第1位から最後に、あるいは市場から外れてしまう主な理由の1つです。この投稿の回答が、同様の障害に直面している他の開発者の助けになることを願っています。小規模または大規模な開発チームでは、通常これが発生します。 一部の開発者は気にせず、フローを採​​用することを決め、多くのコードをそのまま残し、開発プロセスをそのままにすることを好むようです。 他の人は変化に飽きて辞任し、別の会社に移動します。 他の人は話をすることを恐れて静かに過ごすことを好むようです。 時には非常に少数の開発者またはたった1人の開発者が製品の改善について意見を表明し、クライアント、ユーザー、およびチームのコーディングのベストプラクティスとその利点に従うことの重要性をチームに伝えます。これらのタイプの開発者は通常、会社が提供するメリットが非常に少ないソフトウェア会社や製品に多くの可能性があるなどの理由により、チームに留まることを決定します。 私たちのチームの製品は、製品の傘を持っているため、会社が収益を得る場所のほんの一部です(この会社はソフトウェア/ハードウェア会社ではないため、少なくとも今のところ、雇用を創出する継続的な特許訴訟はありません)不安定)。ここ数年、他の開発者の経験からこれまでに学んだことと、私の経験では、開発チームを本当に知るには、数日でも数週間ではなく、数か月かかるということです。チームがあなたを雇いたい、またはあなたを必要とする場合、面接プロセス中。彼らはすべてを素晴らしい音にし、あなたが聞きたいことをあなたに伝えるかもしれません。ただし、そのチームで作業を開始し、コードの内部を掘り始めて、完全なSDLCプロセスに移行するときの現実は異なります。これは、開発者として、あなたが仕事に就いたことの現実を見始めたときです。この現実により、ある会社から別の会社に移動したいと思うのは難しくなります。なぜなら、あなたが移動する会社が良いか悪いかを知るのは難しいからです。はい、Glassdoorのレビューなどを読むことができますが、HRからではなく、実際のオンラインレビューの数はどれくらいですか? マネージャーは最初から常に変化に抵抗しており、以前の開発者は何年も同じことをしてきたことを考慮して、以下に概説する問題に取り組む最良の方法は何でしょうか? 長年にわたる製品革新の欠如:製品には多くの可能性があり、会社に良い収益をもたらしますが、製品は20年前に作られたように見えます。一部のユーザーは、製品が使いやすくも直感的でもないと不満を述べ、他の人は、Gmailのようなアプリに使用され、同様の機能がないために製品を使用するときにイライラすることを述べています。ここでの主な問題は、開発者として製品に変更を加えて、製品の主要な要素を数ピクセル離れたところに移動しようとすると(ユーザーフレンドリまたは直感的に)、マネージャーがパニックして、元の場所に戻します。ユーザーの生産性を向上させる機能を追加しようとすると、「ユーザーはプロセスを行うのに慣れているなどの理由で」削除するように求められます。あなたは、変化、改善、革新に対する抵抗のポイントを得たと思います(開発者としてあなたが利益の強い議論を提供したとしても、マネージャーは変化に対して開かれていません)。同社はこの分野でいくつかの競合他社を抱えていますが(そのうちのいくつかの製品ははるかに競争力があります)、何とかして現在の顧客を何年も維持しています。 プロジェクト管理の調整の欠如:この結果、一部のプロジェクトがバグで遅れて配信され、一部のクライアントから苦情が寄せられたり(クライアントからもバグが報告されたり)、プロジェクトの配信前に予算が早すぎたりするなど。いくつかのプロジェクト調整のヒントとアイデアが、プロジェクトと実行するタスクの進捗を追跡するために定期的に使用されています。 悪いソフトウェア開発プラクティス:コードの臭いは、すべてではないにしてもほとんどのファイルに見られ、ドキュメント、コードの冗長性、フロントエンド層とバックエンドが同じファイルに混在している、古い開発ツール、実際のテスト環境もテストツールもありません(コピーアンドペーストのみ)開発環境から本番環境へのファイルを作成してから、手動でテストして問題が発生していないことを確認してリリースします)。チームがコード開発とソース管理に2つのIDEのみを使用しているため、チームが知らないところで開発とテストに使用する開発ツールのほとんどは、開発環境でのみ使用できます。他の開発者は最新のフレームワークを使用して現在の問題を改善しようとしましたが、マネージャーは「あなたが去ったら、そのコードを維持するのは誰ですか?、そのままにしておきましょう」という理由でそれを好まない去り、別の会社に移った。 要約すると、他の会社の多くの開発者にも同様の状況が起こると確信していますが、状況が異なるため、開発者は(仕事の都合、仕事の柔軟性、会社の利益、またはより良い機会が届いていないという理由だけで)。私が知っている完璧な会社はありませんが、開発者としてあなたがどのように行動し、物事をポジティブに保ち、最終的に製品の改善とソフトウェア開発プロセスの改善のための変更を促進するためにこれらの問題に対処しますか?長年の開発経験またはほんの数年)?これは投稿が長いことは知っていますが、より有用なフィードバックを得る可能性を高めるために、詳細を追加することを好みました。 フィードバックと時間をありがとうございました

11
クラシックASPにこだわった場合、どうすれば面白くすることができますか?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 4年前に閉鎖されました。 以前は非常に小さなアウトソーシング会社(4人のプログラマーと上司)で働いていましたが、ストレスと頻繁な長いシフトが状況を耐え難いものにしたとき、私はもっとリラックスしたスケジュールでより良い有料の仕事に切り替えました自由時間。 ただし、問題は、ほとんどの場合、すべてがAS400システムにすべてを保存するカスタムメイドのC ++キューシステムとインターフェイスするクラシックASPでコーディングされていることです。私の上司はこれに向けて最初の努力をした開発者の1人であり、昨日のツールで今日のビジネスニーズを開発することの難しさが増しているにもかかわらず、当然他の言語/テクノロジーへの切り替えを承認しません。 近い将来、Classic ASPを使ったコーディングにかなりこだわっており、以前は.NETやJavaを使っていたので、少なくとも面白くする方法を見つけるのに苦労しています。後方に...何かアドバイスは?

6
機能要件の欠如は俊敏ですか?
今日、誰もが機敏になりたいと思っています。私が一緒に働いたすべてのチームで、アジャイルの形は異なっていました。いくつかのことは一般的です-毎日のスタンドアップや計画などですが、他の部分は大幅に異なります。 私の現在のチームには、気になることが1つあります。それは機能要件の欠如です。書面による期待が存在しないだけでなく、タスクでは、何を実行する必要があるかが漠然と定義されています。 プロジェクトの目標は、新しいテクノロジーを使用して古いシステムを書き換えることです。古いシステムにも適切なドキュメントはありません。確かに最新のものは存在しません。事業主の要件の説明は、以前と同じように新しい実装で実行しましょう。それは合理的に思えますが、そうではありません。古いシステムは一種のスパゲッティコードであり、そこからビジネス要件を抽出するにはコストがかかります。状況は計画に悪影響を及ぼしているようです。確かに、新しい実装では間違いやバグが発生しやすい(詳細は省略)。 したがって、私は考えています-古いシステムを書き換える場合にビジネス要件がないことは本当に俊敏ですか?

3
レガシーコード(わかりません)の単体テストを作成するにはどうすればよいですか?
進む この質問をする前に、SEに関する多くの関連する質問を含め、多くのことを読みました。 (ソフトウェアエンジニアリングSE)目的がわからないコードのテストを書く (ソフトウェアエンジニアリングSE)ユニットテスト初心者チームはユニットテストが必要 (ソフトウェアエンジニアリングSE)レガシーコードを自動テストで改造するためのベストプラクティス (ソフトウェアエンジニアリングSE)大規模なレガシーシステムを単体テストする方法 (ブログ投稿)単体テスト環境をモックアップする方法 しかし、助けを求めて読んだ後、かゆみはまだ引っかかれていないと感じざるを得ません。 TL; DR 実行、シミュレーション、読み取り、または簡単に理解できないレガシーコードの単体テストを作成するにはどうすればよいですか?おそらく意図したとおりに機能するコンポーネントに役立つ回帰テストは何ですか? 全体像 私は大学院に移行しているので、再び夏の帰国研修生です。私の仕事には次の要件が含まれます。 特定の製品について、ソフトウェアチームが既存のプロジェクトとの互換性を失うことなくIDEおよびJUnitバージョンをアップグレードできるかどうかを評価します。 既存のJavaコード(主にJavaではない)の一部のコンポーネントの単体テストを開発します。ユニットテストとTDDは、使用する必要がある非常に貴重なツールであることをソフトウェアチームに納得させたいと思います。(現在、0%のコードカバレッジがあります。) どういうわけか、重要なシステムのカウボーイコーディングの時代を終わらせてください。 ソースコードのコピーを入手した後、この製品の機能と動作を理解できるように、ビルドして実行しようとしました。できませんでした。私は上司に自分のやり方を尋ね、実際に機能するビルドスクリプトを含む、それをビルドできる新しいスタンドアロンマシンを発行されました。彼らの予想通り、製品コードは設計された組み込みシステムでのみ実行されるため、それも機能しませんでした。しかし、彼らはこの目的のためにシミュレーターを持っているので、彼らはシミュレーターを手に入れ、このマシンにそれを置いてくれました。シミュレータも機能しませんでした。代わりに、私は最終的に特定の画面のGUIのプリントアウトを受け取りました。また、700,000以上のJava LOC内のどこにもコードコメントがないため、把握がさらに困難になります。さらに、彼らのプロジェクトが新しいIDEと互換性があるかどうかを評価する問題がありました。特に、彼らのコードは、彼らが使用しているまさにそのIDEバージョンに適切にロードされませんでした。 私の在庫は次のようになっています: NetBeans 8、9、10、11 JUnit 4、5 特定の製品のソースコード(700,000以上のJava LOCを含む) 実質的にコードコメントはありません(場合によっては署名) 既存のテストはありません GUIウィンドウの物理的な写真 画像内のコンポーネントについて説明していないソフトウェア設計ドキュメント(109ページ) 少なくとも理論的には実行可能なテストを書くのに十分です。そこで、このコンポーネントについて基本的な単体テストを試しました。しかし、モデル、マネージャー、DB接続など、依存関係として持つオブジェクトを初期化できませんでした。基本的な単体テスト以外にJUnitの経験はあまりないので、次のセクションに進んでください。 私の読書から学んだこと モッキング:単体テストを作成する場合、本番環境での依存関係のために、モック変数を用意する必要がありますsetUp。 ここの誰もがマイケルフェザーズの著書「レガシーコードを効果的に使用する」を寛大に提案しています。 回帰テストは、おそらく開始するのに適しています。統合テストを試すのに十分な兵器がないと思います。回帰テストは、ソフトウェアチームにすぐに満足感を与えるでしょう。ただし、私は彼らの既知のバグにアクセスできません。しかし、私はたぶん尋ねることができました。 そして今、私がまだ疑問として持っている不確実性を明確にする試み。基本的に、私はこれらのテストを作成する方法の一部を理解していません。(おそらく)上司からこれ以上のガイダンスを受け取らないと想定すると、このコンポーネントの機能を理解するだけでなく、どのテストが回帰テストとして実際に役立つかを判断するのは私の球場です。 このようなプロジェクトに携わってきた専門家として、このような状況で単体テストを作成する方法について何かアドバイスはありますか?

4
小さなクラスにリファクタリングする前に大きなクラスを分析する最良の方法は?
序文 大規模なスパゲッティコードクラスをリファクタリングする方法を探しているのではありません。そのトピックは他の質問で取り上げられています。 質問 4000行を超え、2000行を超える単一の巨大な更新メソッドを持つ別の同僚が作成したクラスファイルを理解するための手法を探しています。 結局、私はこのクラスのユニットテストを構築し、DRYと単一責任原則に従う多くの小さなクラスにリファクタリングしたいと考えています。 このタスクをどのように管理およびアプローチできますか?最終的には、クラス内で発生するイベントの図を描き、次に抽象化機能に進むことができるようになりたいのですが、クラスの責任と依存関係が何であるかをトップダウンで把握するのに苦労しています。 編集:人々が入力パラメーターに関連するトピックをすでにカバーしている回答では、この情報は初心者向けです。 この場合、クラスのメインメソッドには入力パラメーターがなく、停止するように指示されるまでwhileループが実行されます。コンストラクターもパラメーターを取りません。 これにより、クラス、その要件、および依存関係の混乱が増します。クラスは、静的メソッド、シングルトンを介して他のクラスへの参照を取得し、すでに参照しているクラスを介して到達します。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.