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

私はBDDから始めて、これが私の話です。 Feature: Months and days to days In order to see months and days as days As a date conversion fan I need a webpage where users can enter days and months and convert them to days. 疑問があります... 何かをコーディングする前にシナリオを書くべきでしょうか、それとも最初にシナリオを書いてからコードを書いたり、シナリオをもう一度書いてからコードを書いたりするべきでしょうか... 以前にシナリオを作成する必要がある場合、私のステップを承認しても製品コードはまだ完了しませんか？ いつコードをリファクタリングする必要がありますか？機能が完了した後、または各シナリオの実装後？

9 programming-practices  tdd  refactoring  development-methodologies  bdd 

議論：リファクタリング作業を含むすべての開発には追跡の問題を伴うべきですか？（この場合、Jira） 共通点：私たちの主な目標は品質です。機能する製品、すべてのリリースは、何よりも重要です。私たちのコードベースは古く、自動テストが欠けています。私たちはこれに取り組んでいますが、それは長期的なプロジェクトであり、暫定的なプロセスが必要です。 ポジション1：リファクタリング作業はJiraで追跡する必要があります。変更と明らかに関係がない場合は、別の問題を提起する必要があります。そうしないと、レビューとテストが省略され、私たちの主な目標にリスクが生じます。PCIコンプライアンス（ビジネスの近い将来の目標）ではこのレベルの追跡が必要であるという議論が行われました。私はそれがどんなレベルの確実性でも真実か偽りであると言う立場にはありません。 ポジション2：コードの品質は非常に重要です。それが良くなればなるほど（ある程度、私たちがどこにも近くないほど）、機能する製品をリリースし続ける可能性が高くなります。どんなに小さくても、リファクタリングの方法で障害となるものはすべて、私たちの主な目標に対するリスクです。多くの場合、IDEが自動的に機能します。そのため、とにかく問題が発生することはほとんどありません。 次のケースが行われました： 開発者がカードに「リファクタリング」と関連するリビジョン番号を書き込んだ場合、それは両方の立場を満たしますか？正直なところ、これは皆を等しく不幸にしてしまうような気がします。それでも、リファクタリングの実行にはある程度の抵抗はありますが、十分な追跡機能はありません。 イテレーションのリファクタリング作業を網羅する、すべてを網羅するJiraの問題についてはどうですか？はい、これにより開発者の抵抗層が削除されますが、Jiraの問題があることによる追跡の利点も削除されると思います。QAは何をテストすべきかを明確に理解する方法を教えてください。これは政治的な解決策のようであり、軽量だが最終的には無意味なプロセスを追加することで誰もが落ち着くようにしています。 議論の双方が最終的に同じことを望んでいることを考えると、誰もが本当に幸せになる解決策があるはずだと私には思えます。私たちはこの質問をする最初の人ではあり得なかったので、同様の状況で他の人はどのような経験をしましたか？

9 refactoring  issue-tracking  quality 

問題が発生した場合、特に性質が複雑な場合は、時間をかけて問題を解決するためのアプローチについて考えます。これにもかかわらず、よくあることは、ソリューションをプログラミングしているときに、見逃した問題の詳細について考え始め、それに応じてコードを調整することです。 結果は、リファクタリングする必要があるコードの混乱です。 私は「リファクタリング」をしたいのですが、簡単に聞こえますが、それを実行するのは本当に大変です。見逃した細部が小さい場合、すでに書いた内容を消去して本来の方法で書くのではなく、デザインに小さな更新を加えたくなります。 それは明白な答えのある質問のように聞こえますが、「あなたが行くにつれてリファクタリング」をよりよくするために使用するテクニックはありますか？これは良い原則であることは知っていますが、何度も何度も失敗します。

9 algorithms  refactoring 

複雑な単体テスト機能がある場合： def do_everything(): # turn twizzles # push buttons # move mountain そして、それをいくつかの小さな単位にリファクタリングします： def do_everything(): turn_twizzles() push_buttons() move_mountain() def turn_twizzles(): # turn twizzles def push_buttons(): # push buttons def move_mountain(): # move mountain これらの小さなユニット用の追加の単体テストを書くのに時間を無駄にしていますか？

8 unit-testing  refactoring 

APIを開発する必要があります。APIの機能は、サーバーによって公開されているサービスを呼び出すリクエストです。 最初、APIは次のように機能しました。 class Server: def firstRequest(self, arg1, arg2): # block of code A async = Async() async.callFirstRequest(arg1, arg2) # block of code B def secondRequest(self, argA, argB, argC): # block of code A (identical to that of firstRequest) async = Async() async.callSecondRequest(argA, argB, argC) # block of code B (identical …

8 design  design-patterns  object-oriented  python  refactoring 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 私は数年間、大規模なRuby on Railsアプリケーションに取り組んできました。それは貧しい状態で受け継がれましたが、生産バグのほとんどは時間とともに解決されました。支払い処理コードなど、変更されていないセクションがあります。このコードはほとんどの部分で機能しますが、支払い処理業者によって請求が拒否された場合は常に、ユーザーに役立つメッセージではなく500エラーが表示されます。保守を容易にするためにコードをリファクタリングしたいと思います。それがどのように機能するかの簡単な概要を提供します。 次のスニペットからすべてのエラー処理コードを削除しました。 迷路はコントローラーで始まります： def submit_credit_card ... @credit_card = CreditCard.new(params[:credit_card].merge(:user => @user)) @credit_card.save ... @submission.do_initial_charge(@user) ... end 次に、Submissionモデルで： def do_initial_charge(user) ... self.initial_charge = self.charges.create(:charge_type => ChargeType.find(1), :user => user) self.initial_charge.process! self.initial_charge.settled? end ではChargeモデル： aasm column: 'state' do ... event :process do transitions :from => [:created, :failed], …

8 testing  refactoring  clean-code  complexity  budget 

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

8 design  refactoring  planning  legacy-code 

私のグループは、植物の成長をシミュレートするためのRパッケージを開発しています（GitHubレポジトリを参照）。Rパッケージは.CallCとのインターフェースに使用します。 スタンドアロンCライブラリを作成する価値があると判断しました。2つの主な理由は、1）使い慣れたCデバッグツールを使用すること、および2）開発者/ユーザーコミュニティの大部分がコンパイル済み言語に精通していることです（ほとんどのクラスのモデルはCまたはFortranで書かれています）。ただし、Rパッケージはこのコミュニティの外部の多くの人がアクセスできるため、その機能を維持したいと考えています。 Cライブラリの依存関係を持つRパッケージについて説明しているいくつかの関連する質問（https://stackoverflow.com/q/12328156/199217など）を確認しましたが、既存のRパッケージのデカップリングを特に扱う質問は見つかりませんでした。 提案されたアプローチ （私たちがこれまでに思いついたこと...ストローマン） 既存の機能のテストを作成する Cライブラリをsrc/フォルダー内に保持する R固有のCコード（SEXPRライブラリの読み込みなど）を、先頭に「Rラッパー」ファイルを配置して配置します。R_* Cで構成ファイルを読み取るための個別の関数を作成する Rの機能を置き換える「メイン」のC関数を作成する Rラッパーファイルを無視するCライブラリのmakefileを書き込む Cライブラリが独立してRパッケージと同等に機能したら、C関数を別のリポジトリに移動することを検討できます。これはRパッケージの依存関係になります。 質問： この取り組みは見当違いですか？ 潜在的な落とし穴を見落としていますか？ RライブラリとCライブラリの両方を並行して開発するより良い方法はありますか？ Rパッケージから分離されたCライブラリの例はありますか？ RとCで同等の関数を比較するためのテストをどのように書けばよいでしょうか？

8 design  testing  c  refactoring  r 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 現在、基本的にUIのみを構築するメソッドをリファクタリングする方法について頭を悩ませています。 この方法は、1500行を超えるコード（LOC）であり、カウントされます。それは成長しました、これにどのように取り組むかという計画はありませんでした。あなたは可能性がある、このおなじみのを見つけます。 とにかく、これは基本的に、次のような少し大きな1つの大きなメソッドです。 . . . # null checks null_checks_bx = Box(True) null_checks_ck = CheckBox() null_checks_ck.set_text('Null checks throwing exceptions of type:') if 'doNullChecks' in options: null_checks_ck.set_active(options['doNullChecks']) else: null_checks_ck.set_active(True) # dict to sorted list: extract values from dict by list comprehension exceptions = sorted([exception.get_full_name() for exception in JavaTypes.exception_types]) …

8 python  refactoring  maintainability  methods  modules 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 私は大規模なソフトウェア会社で働き始め、100万行を超えるコードのプロジェクトに割り当てられました。これはクライアント（社内プロジェクトではなく）に販売されるプログラムスイートの一部であり、必要に応じてソースコードを購入できます（ただし、それに関連する追加料金が発生することはまれです）。彼らは何年にもわたってソフトウェア設計を行っており、現在の製品は近い将来に継続することを目的としています。 驚いたことに、何百万行ものコードがドキュメントにほぼ完全に欠けています。さらに、コードの一部の領域は非常に厄介であり、理解しやすくなるようにリファクタリングを使用できる場合があります（たとえば、プログラミング言語の改善が10年ほど前に行われ、コードの大部分が大幅に増加します）バグが発生しにくいことは言うまでもありません）。これを修正するための努力はなさそうで、私が取り組んでいる部分が抵抗に遭遇したためにそうするようにとの私の申し出は、明確な答えを得ることはできませんでした。 これらのプラクティスは、ソフトウェア業界の大企業で一般的ですか？それとも、リファクタリングやドキュメントが不足しているという点で私の会社はユニークですか？ 補遺：いくつかのコメントに基づいて、私が探しているものを明確にしたいと思います。私の会社には技術的な負債があることを理解していますが、これは悪いことです。これが原因で私の会社が悪化しているかどうかを判断するのではなく、このドキュメントの欠如とリファクタリングへの抵抗が、私が持つプログラミングの世界での現実であるかどうかを知りたいだけです。私がそれで働き続けるならば対処するために。

8 documentation  refactoring  management  business  development-environment 

私は現在、レガシーシステムの重要なメソッドをリファクタリングしている最中です。作業を始めるまでテストはほとんどありませんでした。リファクタリング後に正しい作業ができるように、かなりの数のテストを追加しました。 今、私は最も重要な部分に遭遇しました：インジケーターを計算するアルゴリズム。それは何かのようなものです indicator = (OneNumberFromA + AnotherNumberFromB) / elapsedTime; ユニットテストでこの関数の正しい動作をテストするにはどうすればよいですか？ 関数には、プログラムが到達するいくつかのわずかに異なるアルゴリズムもありますが、すべての場合において、これelapsedTimeは結果に不可欠です。

8 design  unit-testing  refactoring 

環境： 最近、XSD.exeによって生成されたクラスファイルを処理する必要がありました。ばかばかしく冗長なクラス/変数名（someRidiculouslyLongPrefixThenMaybeOneThingUniqueAtTheEnd一見するとと比較するのは難しいと思いますsomeRidiculouslyLongPrefixThenMaybeOneOtherThingChanged）と注釈がいたるところにあり、長さが3500行でした。結論として、一体何が起こっているのかを理解するのに私は年齢を重ねました。私はそれを読んで、自分の名前を何かの隣に置くことは決してないと思ったので... 質問： 1）生成されたコードをいじる（つまり、クリーンにする）ことは悪い習慣ですか。 2）生成されたクラスを自分の素敵でクリーンなクラスにマップするマッパーを作成することをお勧めします（これで、とても楽しく作業できます）。 編集： すべてのコメントをありがとう。 実際に何か面白いことをするつもりだった場合（つまり、トランスポートオブジェクト以外のドメインオブジェクトがあった場合）、それらを「よりクリーンな」クラスにマップすると思います。それらのうちの一種の機能。この場合、クラスは事実上DTOであるため、おそらく名前が対応する要素と一致することは理にかなっています。述べたように、私はそれに触れる必要はありません-処理のためにデータを別のレイヤーに渡す前に、アクセサー/ミューテーターを呼び出すだけです。 今のところ、私はそれらを一人にしておくと思います。

8 refactoring  clean-code 

したがって、私は組み込みソフトウェア開発を行う会社で働いており、他のグループはさまざまな製品のソフトウェアのコア開発に焦点を合わせており、工場にある私の部門（別の地理的な場所にある）もソフトウェア開発に対処する必要があります、しかしすべての製品にまたがるので、製品のソフトウェアの問題が原因でラインがダウンした場合にも迅速に修正できます。 つまり、私たちはジェネラリストであり、他のグループは各製品に特化しています。 地理的に分散していると、コア開発に参加するのが少し難しくなります（まあ、それはそれほど難しいことではないのですが、リモートで協力するということになると、意図しない文化的/政治的な障壁があるかもしれません） ）。 だから、私たちは現在、火を消しているだけで、ややアイドル/サブ活用されているので（新しい部門であるか、それが理由かもしれません）、領域を検出することは、私たちにとって良い役割であると考えましたコードのリファクタリングと再設計の機会、および保守性とモジュール性の管理に関連する可能性のある他のすべての実装。他のグループは、時間がないため積極的な期限があり、コードの品質を損なうため、これに焦点を合わせていません（ソフトウェアプロジェクトの永遠の物語） 私のグループ/部門がこの役割を持つ管理職や他のグループによって公式に認識されることを望んでいるということです、そして私はこの問題のために私たちのグループの良い定義/アイデンティティを思いつくのに苦労しています。 だから私の質問は：この役割はすでに存在するものですか？または私はこのようなものを最初に作成したのですか？ 編集：つまり、すべてのリファクタリング作業を自分で行うのではなく、リファクタリングイニシアチブを推進するグループです。オープンソースコミュニティーとオープンソース製品のように、今考えてみると、

8 architecture  refactoring  maintainability  organization 

これには専門用語があったことは知っています。それが何だったか思い出せない。 タイトルを明確にする必要がある場合、ここに私が意味します。これが古いコードの場合： Result foobar(Param1,Param2,Param3) { code that does abc code that does xyz code that does asdf more code that does something } そしてそれは次のように変更されます： SomeResult do_xyz(SomeParams) { code that does xyz } Result foobar() { code that does abc do_xyz(args); code that does asdf more code that does something }

8 terminology  refactoring  maintenance  technique