タグ付けされた質問 「refactoring」

アプリケーションに新しい機能を追加することを目的とする小さなプロジェクトを考えると、導入された変更は、特定の領域でこれらを更新することを含む既存のコードに影響を与えます。実装中に、更新されたこれらのコードの一部にリファクタリングの候補があることがわかりました。 これは、影響を受けるコンポーネントのリグレッションテストを必要とするリファクタリングの適切な時間ですか（したがって、元々プロジェクトの一部ではないスコープを導入している可能性があります）？または、機能を延期し、機能を完成させ、おそらくリファクタリングのための別個のプロジェクトを用意する必要があります（ただし、ビジネスユーザーは、コードの保守性を重視しない限り、機能を追加しないプロジェクトを完全に後援できないため、少しためらっています...）？

11 testing  refactoring  decisions  maintainability  scope 

リファクタリングの努力または継続的な開発の一環として、特定のメソッドまたはクラス全体が何らかの意味で廃止される可能性があります。Javaは@Deprecated注釈をサポートして、問題の機能を処理するより良い方法があることを示します。これは、APIの一部を削除した場合の影響がわからないかもしれないパブリックAPIで特に役立つと思います。非パブリックAPIおよびリビジョン管理システムを使用するプロジェクトの場合（削除は何らかの意味で元に戻すことができます）、廃止された要素を削除するのではなく、廃止するのが適切なのはいつですか？

11 java  programming-practices  refactoring 

私のチームは、1回限りのWebフォームをたくさん作成しています。これらのフォームのほとんどは、単に電子メールを送信するだけであり、いくつかは単純なデータベース書き込みを行います。 現在、各フォームはVisual Studio Team Foundation Serverの独自の個別のソリューションに存在しています。つまり、約100の異なるフォームプロジェクトがあるため、一貫性を維持することが難しくなります。各フォームはフィールドが異なるという点でユニークですが、それらはすべてほぼ同じことを行います。 私はこれらを何らかの形で凝縮したいと考えており、実際にいくつかのガイダンスを使用することができます。 すべてのフォームプロジェクトを含む1つのソリューションファイルを作成する必要がありますか？配管コードはそれほど多くありませんが、電子メールのフォーマットなどを支援するヘルパークラスをいくつか作成できます。プロジェクト間でCSS、JavaScript、コントロール、画像を共有できると非常に便利です。 私たちがマイクロソフトのショップであることを考えると、この特定のシナリオでMVCのようなものをWebformsに移行することで具体的なメリットはありますか？私は全体としてMVCの概念で販売されていますが、そのフォームがすべて電子メールを送信する場合、15フィールドのデータ収集フォームをより効率的にまとめるのに役立ちますか？これについて考えさせられたフォームには、ユーザーの応答に基づいてフィールドを表示および非表示にするためのロジックが組み込まれており、MVCとjQueryを使用するのは効率的ではなかったようです。

11 design  refactoring 

2年ほど前に書いたソフトウェアがいくつかあり、それに追加する機能が必要です。私など、それはひどい混乱にだことに気づき、私は周りのすべてを移動する衝動を持って、きちんとアップしましたIましたが、読んで再起動していないソフトウェアについての記事でジョエルを、その前方に最良の方法はいただきましたか！？

11 refactoring  maintenance 

クラスが単一責任の原則に違反しているかどうかを確認するために人々が使用する実用的なテクニックは何ですか？ クラスには変更する理由が1つだけあるべきだと知っていますが、その文は実際にそれを実装する実用的な方法に少し欠けています。 私が見つけた唯一の方法は、「それは…………それ自体……」という文を使うことです。ここで、最初のスペースはクラス名で、後はメソッド（責任）名です。 ただし、責任が本当にSRPに違反しているかどうかを判断するのが難しい場合があります。 SRPを確認する方法は他にありますか？ 注意： 問題は、SRPの意味ではなく、SRPを確認して実装するための実際的な方法論または一連の手順です。 更新 SRPに明らかに違反するサンプルクラスを追加しました。単一の責任の原則にどのように取り組むかを説明するための例として、人々がそれを使用できれば素晴らしいと思います。 例はここからです。

11 design  design-patterns  object-oriented  refactoring  single-responsibility 

私は最近、多くのことを読んだり考えたりしており、Web開発戦略を再考する必要があるかもしれないという結論に達しました。私は多くのオンザフライプログラミングを行っており、2年間でPHP Webアプリケーションに取り組んできました。小さなツールとして始まったかもしれないものが、かなり大きなプロジェクトになりました。しかし、私と私の前任者からの大量のレガシーコードがあり、当時は意味があったかもしれないコードスニペットですが、今は、実際の形でのこのコードの有用性に疑問を投げかけています。さらに、ユニットテストやテスト駆動開発のようなものは、ごく最近まで私の範囲にはありませんでした。 では、Webアプリケーションのリファクタリングにはどのように取り組みますか？私が探すべきものは何で、その順番は？ブラウザゲームと機能するウェブアプリはどうですか？ではアプローチに違いはありますか？

11 web-applications  refactoring 

2つのクラスDogと、Cat両方がAnimalプロトコルに準拠している（Swiftプログラミング言語に関しては、Java / C＃のインターフェースになる）と考えてください。 犬と猫の混合リストを表示する画面があります。Interactor舞台裏のロジックを処理するクラスがあります。 ここで、ユーザーが猫を削除するときに確認アラートを表示します。ただし、犬はアラートなしですぐに削除する必要があります。条件付きのメソッドは次のようになります。 func tryToDeleteModel(model: Animal) { if let model = model as? Cat { tellSceneToShowConfirmationAlert() } else if let model = model as? Dog { deleteModel(model: model) } } このコードはどのようにリファクタリングできますか？それは明らかににおいがする

10 architecture  refactoring  software  architectural-patterns  polymorphism 

私はプロジェクトの唯一の開発者です。これは、他のソフトウェアプロジェクトと同様に、将来誰かに奪われる可能性があります。 機能Aを実装するためにパターンXを使用したとしましょう。機能を開発して完成させた後、今学んだパターンYを使用して同じ機能を実装できることに気付きました。しかし、機能Aはうまく機能しており、XからYへのリファクタリングは時間がかかり、ほとんどメリットがありません。 次に、機能Bを実装します。これはAに似ていますが、今回はこの機会にパターンYで遊んでみたいと思います。機能Aを実行するときよりも、最終結果に満足しています。ただし、コードでは2つ使用していますXとYの異なるパターン。 ただし、機能AIを構築するときに機能Bと同じパターンを使用するのに十分なスキルがなかったという事実を除いて、異なるパターンを使用する実際の理由はありません。 この質問は、特定の問題に適切なパターンを選択することに関するものではないことに注意してください。同様の問題を解決するためにコードベースに共存する約2つのパターンは、リファクタリングするのに十分な時間を与えると1つに減らすことができます。 そのコードは臭いですか？ このようにソースコードを保持することの欠点は何ですか？ 1つのパターンのみを使用する必要がありますか？つまり、Bを記述するときに、AをリファクタリングしてYを使用するか、Xを使用し続けるか。 ソースで、類似した機能に2つの異なるパターンがある理由は本質的に理由がないことをどのように伝えることができますか？ 次の開発者が私のコードをどう思うかについてあまり心配していませんか？

10 design-patterns  refactoring  documentation 

プロジェクトのサイズが十分に大きいので、頭の中ですべての側面を維持することはできません。その中でいくつかのクラスと関数を扱っており、データを渡しています。 時間の経過とともにエラーが発生し続けることに気づきました。別の関数にデータを渡すときに、データの正確な形式を忘れてしまったためです（たとえば、ある関数が文字列の配列を受け入れて出力し、別の関数は後で記述します）。辞書などに保持されている文字列を受け入れるため、操作している文字列を配列に入れてから辞書に入れるように変換する必要があります）。 どこがどこでどこが壊れているのかを常に把握する必要がないように、私は各関数とクラスを「分離されたエンティティ」として扱うようになりました。場合によっては、データが間違った形式で指定されている場合は、データを再キャストします。 これにより、渡すデータがすべての関数に「適合」することを確認するために費やす時間が大幅に短縮されました。クラスと関数自体が、入力に問題がある場合に警告を発し（場合によってはそれを修正することもあり）、デバッガーを使用してコード全体を処理し、問題が発生した場所を特定する必要があります。 一方、これによりコード全体も増加しました。 私の質問は、このコードスタイルがこの問題の解決に適切かどうかです。 もちろん、最善の解決策は、プロジェクトを完全にリファクタリングし、データがすべての機能に対して均一な構造を持っていることを確認することです。 。 （参考：私はまだ初心者なので、この質問が素朴だった場合は失礼します。私のプロジェクトはPythonで行われています。）

10 python  coding-style  data-structures  refactoring  code-quality 

おそらく多くの人と同じように、設計の問題が頭痛の種になっていることがよくあります。たとえば、問題に直感的に適合し、望ましい利点があるデザインパターン/アプローチがあります。多くの場合、何らかの回避策がないとパターン/アプローチを実装するのが困難になる警告があり、パターン/アプローチの利点が無効になります。多くのパターン/アプローチを繰り返し処理してしまう可能性があります。実際には、簡単な解決策がない実際の状況では、ほぼすべてのパターンに非常に大きな注意事項があるためです。 例： 最近遭遇した実際のものに大まかに基づいた架空の例を紹介します。継承階層が過去のコードのスケーラビリティを妨げていたため、継承ではなくコンポジションを使用したいとしましょう。私はコードをリファクタリングするかもしれませんが、スーパークラス/ベースクラスがサブクラスの機能を単に呼び出す必要があるにもかかわらず、それを回避しようとするいくつかのコンテキストがあることがわかりました。 次善のアプローチは、半分のデリゲート/オブザーバーパターンと半分の構成パターンを実装して、スーパークラスが動作を委任できるようにするか、サブクラスがスーパークラスのイベントを監視できるようにすることです。その場合、クラスを拡張する方法が不明確であるため、クラスの拡張性と保守性が低下します。また、既存のリスナー/デリゲートを拡張するのも難しいです。また、スーパークラスを拡張する方法を確認するために実装を知る必要があるため、情報は十分に隠されていません（コメントを非常に広範囲に使用しない限り）。 したがって、この後は、オブザーバーまたはデリゲートを完全に使用して、アプローチを過度に混同することに伴う欠点を回避することを選択する場合があります。ただし、これには独自の問題があります。たとえば、事実上すべての行動にオブザーバー/デリゲートが必要になるまで、行動の量を増やすためにオブザーバーまたはデリゲートが必要になることに気づく場合があります。1つのオプションは、すべての動作に対して1つの大きなリスナー/デリゲートを持つことですが、実装するクラスは多くの空のメソッドなどで終了します。 それから私は別のアプローチを試すかもしれませんが、それと同じくらい多くの問題があります。それから次のもの、そして次のものなど。 この反復プロセスは、各アプローチが他のアプローチと同じくらい多くの問題を抱えているように見え、一種の設計決定麻痺につながる場合、非常に難しくなります。また、使用する設計パターンやアプローチに関係なく、コードが同じように問題を抱えてしまうことを受け入れるのも困難です。このような状況になった場合、問題自体を再検討する必要があるということですか。この状況に遭遇したとき、他の人は何をしますか？ 編集： 私が明確にしたい質問のいくつかの解釈があるようです： OOPは実際にはOOPに固有のものではないことが判明したため、OOPについて質問から完全に除外しました。さらに、OOPについて渡した私のコメントの一部を誤解するのは簡単です。 反復的なアプローチでさまざまなパターンを試す必要があると主張したり、パターンが機能しなくなった場合は破棄したりする必要があると主張する人もいます。これは私が最初に参照するつもりだったプロセスです。これは例からは明らかだと思いましたが、もっと明確にすることができたので、そのために質問を編集しました。

10 design  design-patterns  object-oriented  refactoring  clean-code 

私は最近、コマンドとクエリメソッドの両方であるメソッドをリファクタリングしていました。 それを1つのコマンドメソッドと1つのクエリメソッドに分離した後、コマンドを呼び出してクエリから値を取得するコード内の複数の場所があり、これはDRYの原則に違反しているようです。 しかし、その一般的なコードをメソッドにラップすると、そのメソッドはコマンドとクエリの両方になります。これは受け入れられますか？

10 language-agnostic  refactoring  dry  cqrs 

私は現在、大規模なコードベースの一部をリファクタリングしており、ユニットテストはまったくありません。私は力ずくでコードをリファクタリングしようとしました。つまり、コードが何をしていてどのような変更が意味を変えないかを推測しようとしましたが、成功しませんでした。コードベースのすべての機能をランダムに破壊しました。 リファクタリングには、レガシーC＃コードをより機能的なスタイルに移行すること（レガシーコードはLINQを含む.NET Framework 3以降の機能を使用しません）、コードのメリットがあるジェネリックの追加などが含まれることに注意してください。 費用がいくらかかかるので、正式な方法は使用できません。 一方、少なくとも「リファクタリングされたレガシーコードにはユニットテストが付属する」というルールは、いくらコストがかかっても、厳密に従うべきだと思います。問題は、500 LOCプライベートメソッドのごく一部をリファクタリングするときに、単体テストを追加することが難しいように見えることです。 特定のコードに関連する単体テストを知るのに役立つものは何ですか？コードの静的分析が何らかの形で役立つと思いますが、次の目的で使用できるツールと手法は何ですか。 どのユニットテストを作成すればよいかを正確に把握し、 そして/または私が行った変更が元のコードに影響を及ぼし、今とは異なる方法で実行されているかどうかを知っていますか？

10 unit-testing  refactoring  legacy  formal-methods 

Martin Fowlerのリファクタリングを読んでいます。それは一般的に優れていますが、ファウラーの推奨の1つが少し問題を引き起こしているようです。 Fowlerは、一時変数をクエリに置き換えることを推奨しているため、これの代わりに： double getPrice() { final int basePrice = _quantity * _itemPrice; final double discountFactor; if (basePrice > 1000) discountFactor = 0.95; else discountFactor = 0.98; return basePrice * discountFactor; } あなたはヘルパーメソッドに引き出します： double basePrice() { return _quantity * _itemPrice; } double getPrice() { final double discountFactor; if (basePrice() > …

10 coding-style  refactoring  variables 

私のコードに次のような関数がある場合： class Employee{ public string calculateTax(string name, int salary) { switch (name) { case "Chris": doSomething($salary); case "David": doSomethingDifferent($salary); case "Scott": doOtherThing($salary); } } 通常、これをリファクタリングして、ファクトリクラスと戦略パターンを使用してPloymorphismを使用します。 public string calculateTax(string name) { InameHandler nameHandler = NameHandlerFactory::getHandler(name); nameHandler->calculateTax($salary); } TDDを使用している場合は、calculateTax()リファクタリングの前にオリジナルで機能するテストをいくつか用意します。 例： calculateTax_givenChrisSalaryBelowThreshold_Expect111(){} calculateTax_givenChrisSalaryAboveThreshold_Expect111(){} calculateTax_givenDavidSalaryBelowThreshold_Expect222(){} calculateTax_givenDavidSalaryAboveThreshold_Expect222(){} calculateTax_givenScottSalaryBelowThreshold_Expect333(){} calculateTax_givenScottSalaryAboveThreshold_Expect333(){} リファクタリング後、FactoryクラスNameHandlerFactoryと少なくとも3つのの実装ができInameHandlerます。 テストをリファクタリングするにはどうすればよいですか？の単体テストを削除して、実装ごとにTestクラスを作成する必要claculateTax()がEmployeeTestsありますInameHandlerか？ Factoryクラスもテストする必要がありますか？

10 design  design-patterns  unit-testing  tdd  refactoring 

新しいプロジェクトを始めるときは、コードの再利用について常に考えています。 コードをどの程度再利用可能にする必要がありますか？ これをアプリケーションの範囲に制限する必要がありますか、それともプロジェクトの外部で再利用できるようにする必要がありますか？ ときどき、コードの再利用性が単純な設計の邪魔になるように感じることがあります。コードの再利用についてのあなた自身の理解とアプローチを共有してください。

10 refactoring  code-reuse