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

リファクタリングは、既存のコード本体を再構築し、外部の動作を変更せずに内部構造を変更するための統制のとれた手法です。

6
TDDの使用時に機能または機能を削除する方法
TDDに関するテキストでは、リファクタリングのステップ中に「重複の削除」または「読みやすさの向上」についてよく読みます。しかし、未使用の関数を削除する理由は何ですか? たとえばC、メソッドa()とを持つクラスがあるとしましょうb()。今私はそれにf()追いやられる方法を持つことが良いと思うC。実際、定義/記述された単体テストを除くf()すべての呼び出しを置き換えます。これはもう必要ありません-テストを除いて。b()b() 削除してb()、それを使用したすべてのテストを削除するだけでいいですか?その部分は「読みやすさの改善」ですか?

3
TDDとリファクタリングの難しさ(または-なぜこれが本来よりも痛いのか?)
TDDアプローチを使用することを自分で学びたいと思っていたので、しばらくの間、やりたいプロジェクトがありました。大規模なプロジェクトではなかったので、TDDの良い候補になると思いました。しかし、何かがおかしくなったように感じます。例を挙げましょう: 高レベルでは、私のプロジェクトはMicrosoft OneNoteのアドインであり、プロジェクトをより簡単に追跡および管理できます。また、いつか自分のカスタムストレージとバックエンドを構築することにした場合に備えて、このためのビジネスロジックをOneNoteから可能な限り切り離したままにしておきたいと考えました。 最初に、基本的な平易な言葉の受け入れテストから始めて、最初の機能で何をしたいかを概説しました。これは次のようなものです(簡潔にするために説明を省略しています)。 ユーザーがプロジェクトの作成をクリックします プロジェクトのタイトルにユーザーが入力する プロジェクトが正しく作成されたことを確認します UIのものといくつかの中間計画をスキップして、最初のユニットテストに行きます。 [TestMethod] public void CreateProject_BasicParameters_ProjectIsValid() { var testController = new Controller(); Project newProject = testController(A.Dummy<String>()); Assert.IsNotNull(newProject); } ここまでは順調ですね。赤、緑、リファクタリングなど。今では実際に保存する必要があります。ここでいくつかの手順を省略して、これで終わります。 [TestMethod] public void CreateProject_BasicParameters_ProjectMatchesExpected() { var fakeDataStore = A.Fake<IDataStore>(); var testController = new Controller(fakeDataStore); String expectedTitle = fixture.Create<String>("Title"); Project newProject = testController(expectedTitle); Assert.AreEqual(expectedTitle, newProject.Title); } …

8
開発時に同僚に対処するため、アドバイスが必要です[非公開]
ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 8年前に閉鎖されました。 この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 8年前に移行され ました。 現在のプロジェクトアーキテクチャを開発し、独自に開発を開始しました(次のようなものに到達しますrevision 40)。 シンプルな地下鉄ルーティングフレームワークを開発しており、私の設計は非常によくできているようです- いくつかのメインモデル、対応するビュー、メインロジック、データ構造が「あるべき」ようにモデル化され、レンダリングから完全に分離され、アルゴリズム部分も実装されましたメインモデルとは別に、少数の交差点がありました。 私は、その設計をスケーラブルで、カスタマイズ可能で、実装が容易で、主に「ブラックボックスの相互作用」に基づいて相互作用し、非常に素晴らしいと呼びます。 さて、何が行われたか: 対応するインターフェースの実装を開始し、便利なライブラリを移植し、アプリケーションの一部の実装スタブを作成しました。 コーディングスタイルとそのコーディングスタイルの使用例(自分の記述コード)を説明したドキュメントがありました。 コード(スマートポインターでラップ)などC++を含む、多かれ少なかれ最新の開発手法の使用を強制しましたno-delete。 具体的なインターフェイス実装の目的と、その使用方法を文書化しました。 単体テスト(ほとんどの場合、「実際の」コードがあまり多くないため統合テスト)と、すべてのコア抽象化のための一連のモック。 私は12日間休みました。 現在何がありますか(プロジェクトはチームの他の4人のメンバーによって開発されました): すべてのプロジェクトの上に3種類のコーディングスタイル(私は推測する、それらの2つが同じスタイルを使用することに同意した:)、同じことが私たちの抽象化の命名にも適用される(例えばCommonPathData.h、SubwaySchemeStructures.h)基本的にはいくつかのデータ構造を宣言し、ヘッダーです。 最近実装された部品のドキュメントの絶対的な不足。 私が最近呼び出すことができるものsingle-purpose-abstractionは、少なくとも2つの異なるタイプのイベントを処理し、他の部分と密接に結合しています。 使用されるインターフェイスの半分には、メンバー変数が含まれるようになりました(sic!)。 ほぼすべての場所での生のポインターの使用。 " (Rev.57) They are unnecessary for this project"のため、ユニットテストは無効です。 ... (おそらくすべてではない)。 コミット履歴は、私の設計が過剰であると解釈され、人々がそれを個人用自転車と再実装されたホイールと組み合わせ始め、コードチャンクの統合に問題があったことを示しています。 さて、プロジェクトはまだやらなければならないことのほんの一部をしているだけで、深刻な統合の問題があります。メモリリークがあると思います。 この場合にできることはありますか? 私はすべての努力が利益をもたらさなかったことに気づきましたが、締め切りはもうすぐであり、私たちは何かをしなければなりません。誰かが同様の状況にありましたか? 基本的には、プロジェクトの良い(まあ、できる限りのことをすべてやった)ことは良いことになると思いましたが、間違っていることは理解しています。

4
インスタンス変数が多すぎるとコードが重複しますか?
パターンのリファクタリングによると: クラスが多くのことをしようとすると、多くの場合、インスタンス変数が多すぎます。クラスのインスタンス変数が多すぎる場合、複製されたコードはそれほど遅れることはありません。 インスタンス変数が多すぎるとコードが重複しますか?

6
他の人がコードベースにすばやくコミットしている間に、どのようにコードベースをリファクタリングできますか?
私は最終的にはオープンソースになるプライベートプロジェクトに参加しています。私たちには、アプリを構築するための技術に十分な才能がある少数のチームメンバーがいますが、クリーンで美しい、最も重要な長期保守可能なコードを書くことができる専任の開発者はいません。 コードベースのリファクタリングを開始しましたが、定期的に連絡を取り合っていない別の国にいるチームの誰かがこのまったく別のものを更新する可能性があるため、少し扱いに​​くいです。 解決策の1つは、迅速に通信するか、より良いPMプラクティスを採用することですが、まだそれほど大きくはありません。コードをクリーンアップして、彼が更新したものにうまくマージしたいだけです。ブランチを使用することは適切な計画でしょうか?ベストエフォートマージですか?他に何か?

7
80%を超える変更を行う場合、クラスファイルの著者名を変更する必要がありますか?
自動化されたUIテストのために、既存のJavaテストクラスのセットをリファクタリングしています。クラスファイルを大幅に変更するか、完全に変更することがあります。これにより、クラス全体を書き換えるとき、コメントセクションの著者名を自分のものに変更する必要があると思いますか? 私は貪欲ですか?それとも、私の名前を見て疑問がある場合に私に尋ねることは有用でしょうか?

6
自己文書化コードvs Javadocs?
最近、私が現在扱っているコードベースの部分のリファクタリングに取り組んでいます-自分自身をよりよく理解するためだけでなく、コードに取り組んでいる他の人にとってそれをより簡単にするために。 私は、自己文書化コードは素晴らしいと考える側に傾く傾向があります。私はちょうどそれがきれいだと思うし、コードがそれ自体のために話すなら、まあ... それは素晴らしいです。 一方、javadocsなどのドキュメントがあります。私もこれが好きですが、ここのコメントが時代遅れになるという特定のリスクがあります(もちろん一般的なコメントも同様です)。ただし、それらが最新の場合、複雑なアルゴリズムを理解するなど、非常に役立ちます。 これのベストプラクティスは何ですか?自己文書化コードとjavadocsの間のどこに線を引きますか?

3
モノリスからマイクロサービスに移行するときに外部キーの制約を処理する方法は?
私のチームは、モノリシックASP.NETアプリケーションから.NET CoreおよびKubernetesに移行しています。コードの変更は予想通りに進行しているように見えますが、私のチームが多くの不一致に遭遇しているのはデータベースの周辺です。 現在、ビジネス全体のすべてのデータを格納するかなり大きなSQL Serverデータベースがあります。私は、コードを分割するのと同様の方法でデータベースを分割することを提案しています-1つの(論理)データベースのカタログデータ、別のデータベースの在庫データ、別の注文など-そして各マイクロサービスはそのデータベースのゲートキーパーになるでしょう。 ここでの意味は、マイクロサービスの境界を越える外部キーを削除する必要があり、境界を越えて到達するprocsおよびビューは禁止されることです。すべてのデータモデルは同じ物理データベースに存在する場合と存在しない場合がありますが、存在する場合でも、相互に直接対話することはできません。注文は引き続きIDでカタログアイテムを参照しますが、データベースレベルでデータの整合性が厳密に強制されることはなく、そのデータはSQLではなくコードで結合する必要があります。 これらの損失は、マイクロサービスへの移行と、それに伴うスケーラビリティのメリットを得るための必要なトレードオフと考えています。縫い目を賢く選択し、それらの周りに展開する限り、問題ありません。他のチームメンバーは、すべてが同じモノリシックデータベースにとどまる必要があるため、すべてがACIDであり、参照整合性をどこにでも保持できることを固く主張しています。 これは私の質問に私をもたらします。まず、外部キーの制約と参加に対する私の姿勢はもっともらしいですか?もしそうなら、誰かが私が同僚に提供できる信頼できる読み物を知っていますか?彼らの立場はほとんど宗教的であり、彼らはマーティン・ファウラー自身が彼らが間違っていると告げる以外に何かに左右されることはないようです。

7
コードのリファクタリング時間を正当化する方法は?
70k LOCを超える非常に大きなプロジェクトがある。 このプロジェクトでは、コアフレームワークやその他の部分でもコードリファクタリングが必要です。プロジェクトの開始時にリファクタリングの時間が設定されていませんでした。しかし、時間の経過とともに40人以上の開発者が共同でプロジェクトを去りました。私の観点からは不可欠です。 適切なソフトウェア開発の原則を主張し、擁護する上であなたの重要なポイントは何ですか?

3
要件を待機している間の、影響の少ないリファクタリングと粗雑なコードのコードクリーニング
ずさんな方法で製品の既存のコードベースを継承しました。基本的な設計は非常に不十分であり、残念ながら完全なリファクタリングなしではほとんど何もできません(高結合、低凝集、コードのof延する複製、技術設計文書なし、単体テストではなく統合テスト)。この製品には、歴史、リスクに対する許容度が最小限の重要な「現金牛」クライアントへの高い露出、ギリシャ人を赤面させる技術的負債、非常に大きなコードベースと複雑さ、そしてチームによるバグへの戦い疲れた敗北主義アプローチがあります私。 古いチームは別の部門に船をジャンプして、別のプロジェクトを台無しにする機会を得た。プロジェクト管理の失敗とは対照的に、技術的な無能なプロジェクトの失敗を経験することは非常にまれですが、これは確かにそれらのケースの1つです。 今のところ、私は一人でいますが、私には多くの時間、意思決定の自由、将来の方向性、そして私を助けるためにゼロからチームを構築する能力があります。 私の質問は、機能要件の収集段階で自由時間があるときに、このようなプロジェクトでの影響の少ないリファクタリングについて意見を集めることです。何千ものコンパイラ警告があり、それらのほとんどは未使用のインポート、未読のローカル変数、型チェックの不在、および安全でないキャストです。コードの書式設定は非常に読みにくく、ずさんなため、コーダーはパーキンソン病にかかっており、特定の行でスペースバーを押した回数を制御できませんでした。通常、さらにデータベースとファイルリソースが開かれ、安全に閉じられることはありません。無意味なメソッド引数、同じことを行う重複メソッドなど。 次の機能の要件を待っている間、私は、影響が少ない低リスクのものを掃除しながら、時間を無駄にしているのか、正しいことをしているのかと考えました。新しい機能が以前に時間を費やしたコードを削除することを意味する場合はどうなりますか?私はアジャイルのアプローチを開始するつもりであり、これがアジャイル開発中に絶えずリファクタリングするのは許容可能であり、普通であることを理解しています。 これを行うことによるプラスまたはマイナスの影響を考えてください。

8
他の誰かがリファクタリングの問題を抱えていますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 かなりの量のコードを書いた後、可能な限り最善の方法でそれをしていないような不安を感じ、最終的にリファクタリングを続け、プロジェクトにあまりにも多くの時間を費やしているようです。時々やった。これは他の誰にも起こりますか、これにどのように対処しますか?

6
列挙型はコードの匂いではありませんか?
ジレンマ オブジェクト指向の実践に関するベストプラクティスの本をたくさん読んでいますが、読んだ本のほとんどすべてに、enumはコードの匂いだと言う部分がありました。列挙型が有効な場合に説明する部分を見逃したと思います。 そのように、私を探していますガイドラインおよび/またはユースケースの列挙型がありませ有効な構文コードのにおいと、実際に。 ソース: 「警告経験則として、列挙型はコードの匂いであり、多態性クラスにリファクタリングする必要があります。[8]」Seemann、Mark 、. 342 [8] Martin Fowler et al。、Refactoring:Improving the Design of Existing Code(New York:Addison-Wesley、1999)、82。 環境 私のジレンマの原因は取引APIです。このメソッドを介して送信することにより、Tickデータのストリームを提供します。 void TickPrice(TickType tickType, double value) どこ enum TickType { BuyPrice, BuyQuantity, LastPrice, LastQuantity, ... } 変更を壊すことがこのAPIの生き方であるため、このAPIのラッパーを作成しようとしました。ラッパーで最後に受信した各ティックタイプの値を追跡したいので、ダニタイプのディクショナリを使用してそれを行いました。 Dictionary<TickType,double> LastValues 私には、キーとして使用される場合、これは列挙型の適切な使用のように思えました。しかし、私はこのコレクションに基づいて意思決定を行う場所があり、switchステートメントを排除する方法を考えることができないため、工場を使用できますが、その工場にはまだどこかにswitchステートメント。私はただ物事を動かしているように見えましたが、まだ匂いがします。 列挙型のDO N'Tを見つけるのは簡単ですが、DOはそれほど簡単ではありません。人々が自分の専門知識、長所と短所を共有できるなら、私はそれを感謝します。 考え直し 一部の決定とアクションはこれらに基づいておりTickType、enum / switchステートメントを削除する方法を考えることはできないようです。私が考えることができる最もクリーンなソリューションは、ファクトリを使用し、に基づいて実装を返すことTickTypeです。それでも、インターフェイスの実装を返すswitchステートメントがあります。 以下は、間違った列挙型を使用しているのではないかと疑っているサンプルクラスの1つです。 public class ExecutionSimulator { …

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 …

1
3つのルールで3回目まで待つ理由は?
ウィキペディアの記事「ルールオブスリー」に出会いました 3つのルールは、コードの複製された部分を新しいプロシージャに置き換える必要があるかどうかを判断するための、コードリファクタリングの経験則です。コードは1回コピーできますが、同じコードを3回使用すると、新しいプロシージャに抽出する必要があると記載されています。ルールは、リファクタリングでマーティン・ファウラーによって導入され、ドン・ロバーツに起因します。 これは単なる経験則であることは知っていますが、2回目の複製後にのみリファクタリングすることが推奨されるのはなぜですか?最初の複製を作成するときに、リファクタリングにマイナス面はありますか?

9
コンストラクターまたはセッターメソッドを使用しますか?
私はActionクラスを持っているUIコードで作業しています、このようなもの- public class MyAction extends Action { public MyAction() { setText("My Action Text"); setToolTip("My Action Tool tip"); setImage("Some Image"); } } このActionクラスが作成されたとき、Actionクラスはカスタマイズできないと想定されていました(ある意味で、そのテキスト、ツールチップ、またはイメージはコードのどこでも変更されません)。現在、コード内の特定の場所でアクションテキストを変更する必要があります。そのため、ハードコーディングされたアクションテキストをコンストラクターから削除し、引数として受け入れるように同僚に提案しました。以下のこのコードのようなもの- public class MyAction extends Action { public MyAction(String actionText) { setText(actionText); setTooltip("My Action tool tip"); setImage("My Image"); } } ただし、setText()メソッドは基本クラスに属しているため、アクションインスタンスが作成された場所にアクションテキストを渡すために柔軟に使用できると考えています。そうすれば、既存のMyActionクラスを変更する必要はありません。したがって、彼のコードは次のようになります。 MyAction action = new MyAction(); //this creates action …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.