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

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私の最後の3つの仕事では、コードメンテナーでした。3つのすべてのケースで、プロジェクトのコードの大部分が既に書かれた後、私は雇われました。 私は独学のプログラマーです。初めてのプロの仕事を始める前に、私は自分のベルトの下で十数個のプロジェクトを開始し、成功して出荷しました。 新しいコードの作成と既存のコードの保守は、まったく異なる2つの仕事です。航空技術者と航空機整備士を比較するようなものです。 特に、飛行機を何らかの方法で論理的または保守しやすいように設計することを試みなかったエンジニアによって設計された飛行機で作業する航空機整備士である場合、それは残念です。 プロジェクトが最初に開始されたとき、私は周りにいるように感じ始めています。あなたは何らかの形でコンピュータサイエンス分野の人々の残りを超越した特別な人々の一人でなければなりません。その位置にいるには何が必要ですか？ この質問には本当に簡単な答えはないように感じますが、誰かが私に洞察を与えることができますか？新しいプロジェクトの1階に行ったことはありますか？そこに着くのに何が必要でしたか？

13 education  refactoring  training  maintenance  industry 

私のコードでやりたいことの1つは、管理しやすい部分にリファクタリングすることです。しかし、ソフトウェアの構築に関しては、私が最終的に使用するビルド自動化ソフトウェア（最近はGNU MakeまたはSCons）が完全に混乱することになります。入力ファイルは、簡単なリファクタリングに逆らう長いスクリプトのように見えます。何らかの方法でそれらをリファクタリングできるようにしたいのですが、「関数」の概念は、プログラミング言語でのビルド自動化ソフトウェアとまったく同じように動作しないため、管理しやすい記述が難しいと感じていますやや複雑なプロジェクトのMakefileまたはSConscriptファイル。 ビルド自動化ソフトウェアの管理可能な入力ファイルを作成することについて、何かアドバイスはありますか？ソフトウェアに依存しないアドバイスが最適ですが、特定のビルド自動化ツール、特にMakeやSConsについてのアドバイスも役立ちます。これは私がプロジェクトで使用しているものだからです。 編集： Thorbjørnが指摘したように、コンテキストと使用例をいくつか追加する必要があります。私は化学工学の博士号を取得しており、計算科学の研究を行っています。（私はSciComp.SEのpro modです。訪問する人のためです。）私のプロジェクトは通常、いくつかの重いスクリプト言語（Python、Python、C ++、Fortran） 、Perl）を使用してプロトタイプを作成し、場合によっては、プロトタイプ作成または技術的な目的でドメイン固有の言語を使用します。 およそ250行の範囲で、以下に2つの例を追加しました。私にとっての問題は、一般的にモジュール性の欠如です。これらのプロジェクトの一部はモジュラーユニットに編成できます。これらのラインに沿ってビルドの一部を抽象化し、私と将来のメンテナーが追跡しやすくするのは良いことです。各スクリプトを複数のファイルに分割することは、頭の中でいじくり回してきた1つのソリューションです。 2番目の例は特に重要です。なぜなら、すぐに多数のファイルが必要になるからです。 以下は、265行Makefileが実際のプロジェクトから取得し、できる限り整理したものです。 #!/usr/bin/make #Directory containing DAEPACK library folder daepack_root = . library = $(daepack_root)/lib wrappers = $(daepack_root)/Wrappers/DSL48S c_headers = parser.h problemSizes.h f77_headers=problemSizes.f commonParam.f f90_headers=problemSizes.f commonParam.f90 includes = -I. -Iinclude -I/usr/include/glib-2.0 \ -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 \ -I/usr/include/libgdome -I/usr/include/gtest/ #Fortran 77 environment variables f77=gfortran …

13 refactoring  builds 

おそらく何らかのツール（おそらくEclipseプラグイン）を使用して、2人の開発者が最初に話すことなく、同じコードを同時にリファクタリングする状況を防止したいと思います。手伝ってくれますか？ 4大陸に450万行のコードと20を超える開発者チームがあります。 理想的には、前述の2番目の開発者が、他の誰かが同じコードの部分で作業していることに気付き、何かを変更する前に最初の開発者と話をしたいと思います。 あなたは解決策を知っていますか？

13 refactoring 

最近、リファクタリング全般の処理方法に関する議論に参加しました（それ自体が興味深いトピックです）。最終的に、次の質問が提起されました。 他の誰かが同じコードの機能に取り組んでいる間に誰かがコードの一部をリファクタリングしたために発生したマージ競合をどのように処理しますか？ 基本的に、効率的な方法でこれに対処する方法がわかりません。これに関して従うべきベストプラクティスはありますか？レガシーコードが大量にあるシステムでこれを処理する方法に違いはありますか？

13 version-control  refactoring  legacy 

特定のレベルの複雑さに達すると、大規模なプロジェクトに絶えず圧倒されます。プロジェクトの特定のポイントに達すると、進行が遅くなり、絶えずステップをたどり、あらゆる種類の混乱を整理します。 私のこの弱さのために、リファクタリングが本当に上手になりました。そして、私は常にオブジェクトをより小さく管理しやすいものに分解しようとしています。この弱点のために、物事を適切に設計することにあまりにも注意を払うことになりました。 問題を小さな問題に分解できれば、スムーズに達成できると思います。頭に浮かぶ戦略の1つは、テスト駆動開発です。他に何ができますか？

13 object-oriented  programming-practices  refactoring  development-methodologies  problem-solving 

例 データベースからデータをロードし、HTMLマークアップを表示し、ルーター/コントローラー/アクションとして機能する「すべて」を行うモノリシックコードに出会いました。データベースコードを独自のファイルに移動するSRPを適用し始め、物事の命名を改善しましたが、すべてが見栄えが良かったのですが、なぜこれを行っているのか疑問に思い始めました。 リファクタリングする理由 目的は何ですか？役に立たない？利点は何ですか？モノリシックファイルはほとんどそのままにしておきましたが、作業を行う必要がある領域に関連する小さな部分のみをリファクタリングしたことに注意してください。 元のコード： 具体的な例を挙げると、このコードスニペットに出会いました。既知の製品IDまたはユーザーが選択したバージョンIDのいずれかで製品仕様を読み込みます。 if ($verid) $sql1 = "SELECT * FROM product_spec WHERE id = " . clean_input($verid); else $sql1 = "SELECT * FROM product_spec WHERE product_id = " . clean_input($productid) ; $result1 = query($sql1); $row1 = fetch_array($result1); /* html markup follows */ リファクタリング： この特定のコード部分を変更する必要がある作業を行っているため、リポジトリパターンを使用するように変更し、オブジェクト指向のMySQL機能を使用するようにアップグレードしました。 //some implementation details …

12 php  refactoring  solid  single-responsibility 

これは、純粋に技術的な質問というよりも、命名法（技術文書）です。私は、アプリケーションでの依存性注入の拡大を中心に、リファクタリングの提案を書いています（そして、それを自分に割り当てます）。Beanの自動配線にSpringを使用していますがMyClass obj = new MyClass(...)、を使用してBeanをインスタンス化するインスタンスがまだあります。私の提案では、エレガントな命名法を使用し、適切な用語でDIの反対のデザインパターンを参照したいと思います。 「密結合」は、DIの反意語として適切な用語ですか？

12 terminology  refactoring  dependency-injection 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 私は2年以上、C ++で趣味のプロジェクトに取り組んでいます。モジュール/関数を作成するたびに、多くのことを考えてコーディングします。今、問題を見て、 do { --> write the code in module 'X' and test it --> ... forget for sometime ... --> revisit the same piece of code (due to some requirement) --> feel that "This isn't written nicely; could have been better" } while(true); ここ'X'に任意のモジュールがあります（小/大/中）。これは、コーディング中にどれだけの労力を費やしても発生します。そのため、ほとんどの場合、動作するコードを見ることは控えています。:) これは多くの人に共通の気持ちですか？この言語特有の現象ですか？（C ++では、同じことを異なる方法で書くことができるため）。 現実の製品コードでこのリファクタリングの感覚が得られたら、どうすればいいですか？作業中のコードを変更しても賞賛は得られませんが、失敗するとトラブルが発生する可能性があります。

12 c++  self-improvement  refactoring  coding 

最近、きれいなコード開発に関するWebサイトを読んでいます（英語ではないため、ここにはリンクを入れません）。 このサイトで宣伝されている原則の1つは、オープンクローズド原則です。各ソフトウェアコンポーネントは、拡張用にオープンにし、変更用にクローズする必要があります。たとえば、クラスを実装してテストした場合、バグを修正するか、新しい機能を追加する（たとえば、既存のメソッドに影響を与えない新しいメソッド）ためにクラスを変更するだけです。既存の機能と実装は変更しないでください。 通常、インターフェイスIと対応する実装クラスを定義することにより、この原則を適用しますA。クラスAが安定（実装およびテスト）になったとき、通常はあまり変更しません（おそらく、まったく変更しません）。 コードに大きな変更を必要とする新しい要件（パフォーマンス、インターフェイスのまったく新しい実装など）が到着した場合、新しい実装を作成し、成熟していない限りB使用Aし続けBます。B成熟したときに必要なのは、Iインスタンス化の方法を変更することだけです。 新しい要件がインターフェースの変更も示唆している場合、新しいインターフェースI'と新しい実装を定義しますA'。ですからI、A凍結しており、残る実装限りとして生産システムのためI'およびA'それらを交換するのに十分安定していません。 そのため、これらの観察を考慮して、Webページが複雑なリファクタリングの使用を提案していることに少し驚いていました。 オープン/クローズド原則の実施と、ベストプラクティスとしての複雑なリファクタリングの使用の提案との間に矛盾や矛盾はありませんか？または、ここでのアイデアは、クラスの開発中に複雑なリファクタリングを使用できるということですAが、そのクラスが正常にテストされたら、凍結する必要がありますか？

12 programming-practices  refactoring  open-close 

タイトルはそれをすべて言います。私の会社は、完全にプレーンCで記述されたマイクロコントローラーデバイス用のレガシーファームウェアプロジェクトを再利用しています。 明らかに間違っており、変更が必要な部分があります。C＃/ TDDのバックグラウンドから来たので、機能を変更しないことを保証するためのテストなしでランダムにリファクタリングするというアイデアは好きではありません。また、バグを見つけるのが難しいことは、わずかな変更（多くの場合、回帰テストを使用した場合に修正されると思います）によって導入されたことがわかりました。これらの間違いを避けるために、多くの注意を払う必要があります。コードの周りの多くのグローバルを追跡するのは難しいです。 要約する： リファクタリングする前に、既存の密結合コードに単体テストをどのように追加しますか？ どのツールをお勧めしますか？（それほど重要ではありませんが、知っておくといいです） 私はこのコードの作成には直接関与していません（私の責任はさまざまな方法でデバイスと対話するアプリです）が、使用できる可能性がある場合、良いプログラミングの原則が残されていると悪いでしょう。

12 c  unit-testing  refactoring  legacy 

私は4人の開発者のプロジェクトチームに所属しています。単一の作業項目で発生する余分な作業を処理する方法については、長い間議論を重ねてきました。 この余分な作業は通常、タスクにわずかに関連するものですが、アイテムの目標を達成するために必ずしも必要なわけではありません（意見かもしれません）。例には以下が含まれますが、これらに限定されません。 ワークアイテムによって変更されたコードのリファクタリング アイテムによって変更されたコードに隣接するコードのリファクタリング チケット周辺のより大きなコード領域を再構築します。たとえば、アイテムで単一の関数を変更した場合、クラス全体を再実行してこの変更により適切に対応できるようになることに気付きます。 変更したフォームのUIを改善する この余分な作業が小さい場合は問題ありません。問題は、この追加作業により、元の特徴点の推定を超えてアイテムが大幅に拡張されることです。5ポイントのアイテムは実際には13ポイントかかる場合があります。あるケースでは、振り返ってみると80ポイント以上であった13ポイントのアイテムがありました。 これをどのように処理するかについての議論では、2つの方法が考えられます。 同じ作業項目で余分な作業を受け入れ、誤推定としてそれを書き留めることができます。これに関する議論は次のとおりです。 この種のことを考慮して、スプリントの最後に「パディング」を計画しています。 常にコードを見つけたときよりも良い形にしてください。中途半端な作業をチェックインしないでください。 リファクタリングを後で行う場合、スケジュールを立てることが難しく、完了しない可能性があります。 あなたはすでにコードの奥深くにいるので、あなたは今この仕事を処理するのに最高の精神的な「状況」にいます。後で戻ってきたときにそのコンテキストを失うよりも、今それを邪魔にならないようにして効率的にする方が良いでしょう。 現在の作業項目に線を引き、追加の作業は別のチケットになると言います。引数は次のとおりです。 個別のチケットがあると、新しい見積もりが可能になるため、実際のポイント数について自分自身に嘘をついたり、見積もりの​​すべてがひどいことを認めたりする必要はありません。 スプリントの「パディング」は、チケット要件を完了するための直接的な障壁である予期しない技術的な課題のためのものです。これは、「便利な」だけの副次的なアイテムを対象としたものではありません。 リファクタリングをスケジュールする場合は、バックログの先頭に配置してください。 それが出てきたときにいくぶん恣意的であるように思われるので、私たちが推定においてこのことを適切に説明する方法はありません。コードレビューアは、「これらのUIコントロール（実際にはこの作業項目で変更しなかったもの）は少し混乱します。それも修正できますか？」これは1時間のようですが、「このコントロールが他のコントロールと同じ基本クラスから継承するようになった場合は、この（数百行の）コードをすべてベースに移動して、これらすべてを再配線しないでください。 、カスケード変更など？」そして、それは一週間かかります。 これは無関係な作業をチケットに追加することで「犯罪現場を汚染」し、元の特徴点推定を無意味にします。 場合によっては、余分な作業がチェックインを延期し、開発者間のブロッキングを引き起こします。 追加のものが2 FP未満の場合は同じチケットに入れられ、それ以上の場合は新しいチケットにするなど、一部の人はカットオフを決定する必要があると今言っています。 私たちはアジャイルを使用して数ヶ月しか経っていないので、これをどのように処理するかについて、この辺りの経験豊富なアジャイル退役軍人の意見は何ですか？

12 agile  refactoring  estimation  sprint 

あなたが見つけたよりも良い状態にコード/キャンプサイトを残すことについてのこの記事が本当に好きです -コードの清潔さを維持するための現実の現実的なアプローチのようです。 また、機能を単独で開発する方法として機能ブランチが本当に好きなので、気に入らない場合は簡単にマージできないなどです。 ただし、機能ブランチで作業しているときにifいコードを見つけた場合、修正する必要がありますか？ それを修正するには多くの欠点があるように感じます： ブランチをマージして戻すと、diffが乱雑になり、変数名の変更や関数の抽出が乱雑になります 機能が放棄された場合、クリーンアップコミットをチェリーピック（近くのコードが変更されて乱雑なマージが行われた方法に応じて機能する場合と機能しない場合があります）、再実行、または単に放棄する必要があります。 反対に、ファイルにいるときに実行しないと、ブランチをマージする数日後に実行するのを忘れることになります。 私はこれが意見に基づいていると警告されました（タイトルに含まれている事実から外れていると思いますshould）が、答えがあると感じています（確かに人々は両方のアプローチを使用しているので答えが必要です）。また、についての質問development methodologiesは話題になっており、ある程度の意見が必要だと思います。

11 refactoring  code-quality  branching 

私は単一責任原則（SRP）に準拠し、コードの繰り返しを省略しようとします。しかし、少なくとも意味のある名前付きメソッドへの抽出に抵抗する呼び出しのコードブロックにすぎないコードの繰り返しがある場所がしばしばあります。 DoAction1(); DoAction2(); if (value) DoAction3(); DoAction4(); そのようなコードをメソッドに抽出する最良の方法とその命名方法は何ですか？

11 refactoring  readability  single-responsibility  code-reuse 

私は「スパゲッティコード」プロジェクトに取り組んでおり、バグを修正して新しい機能を実装している間、コードをユニットテスト可能にするためにリファクタリングも行っています。 コードはしばしば非常に密結合または複雑であるため、小さなバグを修正すると多くのクラスが書き直されます。そこで、リファクタリングを停止するコードのどこかに線を引くことにしました。これを明確にするために、次のような状況を説明するコメントをコードにいくつか落とします。 class RefactoredClass { private SingletonClass xyz; // I know SingletonClass is a Singleton, so I would not need to pass it here. // However, I would like to get rid of it in the future, so it is passed as a // parameter here to make this change …

11 refactoring  comments 

PHPオブジェクト、パターン、およびプラクティスを読んでいます。著者は大学での授業をモデル化しようとしています。目標は、レッスンタイプ（講義またはセミナー）と、レッスンが時間制レッスンか固定価格レッスンかに応じて、レッスンの料金を出力することです。したがって、出力は次のようになります Lesson charge 20. Charge type: hourly rate. Lesson type: seminar. Lesson charge 30. Charge type: fixed rate. Lesson type: lecture. 入力が次の場合： $lessons[] = new Lesson('hourly rate', 4, 'seminar'); $lessons[] = new Lesson('fixed rate', null, 'lecture'); 私はこれを書いた： class Lesson { private $chargeType; private $duration; private $lessonType; public function __construct($chargeType, $duration, …

11 php  object-oriented  refactoring