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

「コードのにおい」とは何かを判断することは主観的であり、言語、開発者、および開発方法によって異なります。ある技法が「コードのにおい」であるかどうかを尋ねる前に、その技法を使用した場合、特定のプロジェクトにどのような影響があるかを自問してください。何かが「コードのにおい」であるかどうかを単に尋ねることは、あまりにも主観的です。

4
論理的に手続き型のソフトウェアをオブジェクト指向言語で記述する最もクリーンな方法
私は電気技師で、一体何をしているのかわかりません。私のコードの将来のメンテナーを保存してください。 最近、機能が論理的に「手続き型」である(C#の)いくつかの小さなプログラムに取り組んでいます。たとえば、その1つは、さまざまなデータベースから情報を収集し、その情報を使用して一種の要約ページを生成し、印刷してから終了するプログラムです。 これらすべてに必要なロジックは約2000行です。以前の開発者が行っていたように、私はそれらすべてを1つにmain()詰め込んで#regionsで「クリーンアップ」したくありません(シャダー)。 ここに私がすでに満足していないいくつかの試みがあります: DatabaseInfoGetter、SummaryPageGenerator、PrintUtilityなど、機能の粗いビットごとに静的ユーティリティを作成します。メイン関数を次のようにします。 int main() { var thisThing = DatabaseInfoGetter.GetThis(); var thatThing = DatabaseInfoGetter.GetThat(); var summary = SummaryPageGenerator.GeneratePage(thisThing, thatThing); PrintUtility.Print(summary); } 1つのプログラムでは、インターフェイスも使用しました int main() { /* pardon the psuedocode */ List<Function> toDoList = new List<Function>(); toDoList.Add(new DatabaseInfoGetter(serverUrl)); toDoList.Add(new SummaryPageGenerator()); toDoList.Add(new PrintUtility()); foreach (Function f in toDoList) f.Do(); } …

8
日付に基づいてUI(または他の)機能をオンまたはオフにしますか?
ASP.NET 2.0で書かれたひどいシステムがあり、いくつかの機能を追加する必要があります。問題は、特定の製品には特定の日付以降に開始されたビジネスでオンにする必要がある(および他のサービスがオフになっている)UI機能があり、既存のビジネスではページが同じように表示される必要があることです。 私は本能的に日付ベースのJavaScript UIスイッチのアイデアと、古いビジネスと新しいビジネスのWebコントロールの混合が「だらしない」(より良い言葉が欲しいため) )。 時間ベースのUI機能を持つ慣行は広く受け入れられている慣行ですか?そうでない場合、その行動方針を追求する既知のリスクは何ですか?

5
テスト可能なコードの作成と投機的一般性の回避
私は今朝いくつかのブログ投稿を読んでいて、これに出くわしました: Customerインターフェースを実装する唯一のクラスがCustomerImplである場合、実際には実行時に代用するものがないため、ポリモーフィズムと代替性はありません。それは偽の一般性です。 インターフェースを実装すると複雑さが増し、実装が1つしかない場合は、不必要な複雑さが加わると主張するかもしれません。必要以上に抽象的なコードを記述することは、「投機的一般性」と呼ばれるコードの匂いと見なされることがよくあります(投稿でも言及されています)。 しかし、TDDを使用している場合、インターフェイス実装または他のポリモーフィックオプションの形式であるかどうかにかかわらず、クラスを継承可能にし、そのメソッドを仮想にすることで、その投機的な一般性なしにテストダブルを作成することはできません。 それでは、このトレードオフをどのように調整するのでしょうか?テスト/ TDDを促進するために投機的に一般的であることは価値がありますか?テストdoubleを使用している場合、これらは2番目の実装としてカウントされ、一般性が推測されなくなりますか?具体的な協力者のモックを可能にする、よりヘビーなモックフレームワークを検討する必要があります(たとえば、C#の世界でのMolesとMoq)。または、具体的なクラスでテストし、デザインが自然にポリモーフィズムを必要とするときまで、「統合」テストと考えられるものを記述する必要がありますか? 私はこの問題に関する他の人々の見解を読んでみたいです-あなたの意見を事前に感謝します。

3
TDDモックコール検証-アンチパターンですか?
私は1年前からTDDを行っていますが、TDDにはかなり満足しています。テストスイートなど、すべてが大好きです。しかし、最近私は多くの模擬通話検証を行っていることに気づきました。たとえば、リポジトリが挿入されるサービスがあります-単体テストでは、リポジトリのモックを渡し、テストしているメソッド内で呼び出されていることを確認します。次に、返された結果が正しいかどうかを確認します(別のテストで)。私の単体テストは実装の詳細に非常に結びついているので、これは間違いなく間違いだと感じています。「振る舞い」をテストするべきだと聞いたことがありますが、多くの状況では... emm-不可能ですか?あなたが持っている場合voidたとえば、通常は副作用をテストします。つまり、これを実証できる単純なコード型を簡単に示すことができますが、私見では、私たちが作成する実際のプログラムにはあまり反映されていません。私が間違っているのは何ですか?この種のテストは一種のアンチパターンですか?これについてのあなたの意見をいただければ幸いです。TDDに関しては、まだ初心者です。

4
関数を呼び出すこの方法は悪い習慣ですか?
私は次のコードを持っています: public void moveCameraTo(Location location){ moveCameraTo(location.getLatitude(), location.getLongitude()); } public void moveCameraTo(double latitude, double longitude){ LatLng latLng = new LatLng(latitude, longitude); moveCameraTo(latLng); } public void moveCameraTo(LatLng latLng){ GoogleMap googleMap = getGoogleMap(); cameraUpdate = CameraUpdateFactory.newLatLngZoom(latLng, INITIAL_MAP_ZOOM_LEVEL); googleMap.moveCamera(cameraUpdate); } このようにすると、LatLngたとえば、別のクラスの内容を知る責任がなくなると思います。 また、関数を呼び出す前にデータを準備する必要はありません。 どう思いますか? このアプローチには名前がありますか?それは本当に悪い習慣ですか?

4
多くの異なるステータスを表す整数コードを返す関数を作り直す
私は、以下の短いサンプルを含めたいくつかのひどいコードを継承しました。 この特定のアンチパターンに名前はありますか? これをリファクタリングするための推奨事項は何ですか? // 0=Need to log in / present username and password // 2=Already logged in // 3=Inactive User found // 4=Valid User found-establish their session // 5=Valid User found with password change needed-establish their session // 6=Invalid User based on app login // 7=Invalid User based on network …

3
クリーンなコードとハイブリッドオブジェクトおよび機能羨望
そのため、最近、コードにいくつかの主要なリファクタリングを行いました。私がしようとした主なことの1つは、クラスをデータオブジェクトとワーカーオブジェクトに分割することでした。これは、とりわけ、Clean Codeの次のセクションに触発されました。 ハイブリッド この混乱は、半分のオブジェクトと半分のデータ構造である不幸なハイブリッドデータ構造につながることがあります。それらには重要な機能を果たす関数があり、パブリック変数またはパブリックアクセサーとミューテーターのいずれかがあり、すべての目的と目的のためにプライベート変数をパブリックにして、他の外部関数がそれらの変数を手続き型プログラムが使用する方法で使用するように誘惑しますデータ構造。 そのようなハイブリッドは、新しい関数を追加することを難しくしますが、新しいデータ構造を追加することも難しくします。彼らは両方の世界で最悪です。それらを作成しないでください。それらは、作者が関数や型からの保護を必要としているかどうか、またはさらに悪いことに無知である混乱した設計を示しています。 最近、私はワーカーオブジェクトの1つ(たまたま、Visitorパターンを実装する)のコードを見て、これを確認しました。 @Override public void visit(MarketTrade trade) { this.data.handleTrade(trade); updateRun(trade); } private void updateRun(MarketTrade newTrade) { if(this.data.getLastAggressor() != newTrade.getAggressor()) { this.data.setRunLength(0); this.data.setLastAggressor(newTrade.getAggressor()); } this.data.setRunLength(this.data.getRunLength() + newTrade.getLots()); } 私はすぐに「!このロジックがであるべき機能の羨望自分自身に言ったData-特に、クラスhandleTradeメソッド。handleTradeとupdateRunする必要があり、常に一緒に起こります」。しかし、「データクラスは単なるpublicデータ構造です。それを始めれば、ハイブリッドオブジェクトになるでしょう!」 何が良いのか、そしてその理由は?どちらを行うかをどのように決定しますか?

4
イベントリスナーモデルが必要であるという症状がある「コードのにおい」は何ですか。
イベントリスナーアプローチが必要であることを示すコードベースの症状は何ですか? 他のクラスのデザインタイムセットでは定義されていない、複数で呼び出す必要があるクラスがある場合、何らかのシグナリングフレームワークが必要ですが、他にどのような状況があるのか​​聞きたいですイベントベースのモデルに変更することで改善されました。


2
単体テスト:「リファクタリングしていて、共同編集者がいない場合、コードのにおいがします」?
私はロイ・オセロベによるユニットテストの芸術を読んでいます。私はセクション7.2にいます。ここでは、作成者がコードのにおいについてこのメモを持っています。 注:外部テストから見えるように内部状態をリファクタリングする場合、それはコードのにおい(コードの設計またはロジックに問題がある可能性がある兆候)と見なすことができますか?共同編集者を公開するためにリファクタリングしているときは、コードのにおいではありません。リファクタリングを行っていて、共同編集者がいない場合は、コードのにおいです(したがって、何もスタブしたりモックしたりする必要はありません)。 編集:著者が「共同編集者」によって意味するのは依存関係です。彼の依存関係の例には、データベースにアクセスするクラスや、OSのファイルシステムにアクセスするクラスがあります。ここで、彼はスタブを定義し、コラボレーターという言葉を使い始めます。 スタブは、既存の制御置換である依存性(または 共同編集システムにおいて)。 作者にはこのコードの匂いの例はなく、これがどのように見えるか理解/描写するのに苦労しています。誰かがこれをもう少し説明して、おそらく具体的な例を提供できますか?

2
オブジェクトがその所有者の多くを知っている場合、それはコードのにおいですか?
Delphi 2007アプリケーションでは、次の構成要素の多くを使用しています FdmBasic:=TdmBasicData(FindOwnerClass(AOwner,TdmBasicData)); FindOwnerClassは、現在のコンポーネントの所有者階層を上に移動して、特定のクラスを検索します(例ではTdmBasicData)。結果のオブジェクトは、フィールド変数FdmBasicに格納されます。これは主にデータモジュールを渡すために使用します。 例:レポートを生成するとき、結果のデータは圧縮され、データモジュールTdmReportBaseDataを介してアクセスされるテーブルのBlobフィールドに格納されます。アプリケーションの別のモジュールには、ReportBuilderを使用して、レポートのデータをページ形式で表示する機能があります。このモジュールのメインコード(TdmRBReport)は、クラスTRBTempdatabaseを使用して、圧縮されたblobデータを、Reportbuilderランタイムレポートデザイナーで使用可能なさまざまなテーブルに変換します。TdmRBReportは、あらゆる種類のレポート関連データ(レポートのタイプ、レポート計算設定など)のTdmReportBaseDataにアクセスできます。TRBTempDatabaseはTdmRBReportで構築されますが、TdmReportBasedataにアクセスできる必要があります。したがって、これは上記の構成を使用して行われます。 constructor TRBTempDatabase.Create(aOwner: TComponent); begin inherited Create(aOwner); FdmReportBaseData := TdmRBReport(FindOwnerClass(Owner, TdmRBReport)).dmReportBaseData; end;{- .Create } 私の考えでは、これはTRBTempDatabaseがその所有者の多くを知っていることを意味し、これがなんらかのコードの匂いやアンチパターンなのかどうか疑問に思っていました。 これについてどう思いますか?これはコードのにおいですか?もしそうなら、より良い方法は何ですか?

4
設定のみのプロパティを持つことが推奨されないのはなぜですか?
今日、私の同僚が私のコードをレビューし、設定のみのプロパティを削除して、代わりにメソッドを使用することを提案しました。 私たち2人は他のことで忙しかったので、Property Design「フレームワークの設計ガイドライン」の本のセクションを見るように言われました。本の中で作家はただ避けようと言った: ゲッターよりも広いアクセシビリティを持つセッターを持つプロパティ そして今、私はなぜそれがセットオンリープロパティを持つことが推奨されないのか疑問に思っていますか?誰かが私のために明確にできますか?

12
C#のプロパティ結合演算子
C#のnull結合演算子を使用すると、コードを短縮できます if (_mywidget == null) return new Widget(); else return _mywidget; 至るまで: return _mywidget ?? new Widget(); C#で使用したい便利な演算子は、オブジェクトのプロパティ、またはオブジェクトがnullの場合は他の値を返すことができる演算子であることに気づきました。交換したいので if (_mywidget == null) return 5; else return _mywidget.Length; と: return _mywidget.Length ??! 5; この演算子が存在しないのには何らかの理由があるに違いないと私は思わずにはいられません。コード臭?これを書くためのより良い方法はありますか?(私はnullオブジェクトパターンを知っていますが、これらの4行のコードを置き換えるためにそれを使用するのはやり過ぎのようです。)
9 c#  code-smell  null 

3
読みやすさのためだけに名前でサブクラスを作成することは悪い習慣ですか?
1つのパッケージに3つのセンサーがあり、すべてを調整する必要があります。これらをsens1、sens2、およびsens3と呼びます。sens1とsens2のキャリブレーションは同じですが、sens3のキャリブレーションには追加のパラメーターが必要です。私の質問は、「読みやすさを維持しながら、ほぼ同一の3つのオブジェクトを処理する最良の方法は何ですか?」です。 もちろん、最初に考えたのは、ポリモーフィズムを使用することでした。汎用のSensorオブジェクトを.calibrate(Parameters params)メソッドでセットアップします。ここで、Parametersクラスを使用すると、実行しているキャリブレーションに基づいてパラメーターの数を変更できます。ただし、これにより次のようになります。 Sensor sens1 = new Sensor(); Sensor sens2 = new Sensor(); Sensor3 sens3 = new Sensor3(); 将来の人々は、1つのセンサーが他の2つのセンサーと根本的に異なることを知る必要がありますが、非常によく似ているため、Sens1とSens2を名前だけでサブクラス化するのが最善のようです。言い換えると、より論理的なクラス名を持たせるために、動作を変更または拡張しない2つのサブクラスを作成します。これらの3つのセンサーはすべて同じパッケージに含まれているため、このデータは非常に頻繁に組み合わされます。これにより、上記のコードが次のように変更されます。 Sensor1 sens1 = new Sensor1(); Sensor2 sens2 = new Sensor2(); Sensor3 sens3 = new Sensor3(); どこ Sensor1 extends Sensor { } Sensor2 extends Sensor { } Sensor3 extends Sensor { @Override …

5
仕事の同僚が、維持しようとしている設計を理解していない場合の対処方法[終了]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか? 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 4年前休業。 私が取り組んでいるソフトウェアプロジェクトには、私と別のプログラマが関わっています。プロジェクトには、MVCフロントエンドを備えたエンジンバックエンドが含まれていました。最初はプロジェクトで多くの作業を行っていたので、主に抽象化とテンプレート戦略を取り巻くいくつかの簡単な設計方法論をセットアップしました。 かなり長い間、私はエンジンのバックエンドを離れて、ウェブサイトで働いていました。しかし、いつかエンジンに戻る可能性があるとの情報を得たので、私はまだエンジンに興味を持っています。 プロジェクトは非常に厳しい締め切りにあるので、私たちは皆、フロントエンドとバックエンドの両方で完成させるために作られたように急いでいます。 私は自分が優れたプログラマであるとは思っていません。そのため、特定のデザインや方法論を人々に強制したり、実行したりすることはありません。より良いソリューションを考え出す。しかし、私はこのエンジンコードに変更が加えられていることに気づきました。私が開発者に別の方法で作業を提案するよう提案したとき、厳しい締め切りを考慮してもメリットはほとんどないため、彼はポイントを理解していないと述べました。 彼が入れたハックはリリース後にさらなる開発を意味する可能性があることを試して説明する必要があり、今すぐ修正できるときに他の人にスラックを拾わせるのは公平ではないと思いました。私は自分がやったことを30分ほどかけて過ごしましたが、その最後に、彼はコードをほとんど書いて、コピーできるようにしてほしいと頼みました。 私が最初に設定したものの基礎は: 抽象クラスx xの具象インスタンスを作成するための抽象ファクトリクラス 何が起こったのかというと、抽象クラスにvirtual / abstraceメソッドとして簡単に配置でき、それに応じて新しい変更が抽象クラスの他のメソッドと同じ原則に従っているので、それに応じて実装できるifステートメントをいくつか置いていました。 これは私には取るに足らないことのように思えますが、関連するクラスを見せても、彼はこれを理解することさえできませんでした。 今私の質問は: 彼がこの概念を理解していたはずであると想定するのは、これは不公平ですか?私たちは厳しい締め切りにあることを理解していますが、それは取るに足らないことだと思いました。プログラマーは、少なくとも中間レベルであることが想定されています。 これは多くの場所で起こっており、私は常に彼に変化を起こさせようとしましたが、彼はそうではありません。無視してもいいですか? この問題を別の場所で提起するのか、それとも吸うだけでいいのか、プロジェクトを再開するときは、これらすべての変更を行ってみてください。 プロジェクトの彼の部分は完成しないので、私は戻って彼を助けなければなりません。私はあまり望んでいません。なぜなら、彼は素晴らしいとは言えないが、まあまあのアーキテクチャでプロジェクトを実行していて、達成しようとしていることを頻繁にフォローしていなかった多くの厄介なコードを実際に配置したからです。 質問が曖昧または不満である場合は、お知らせください。それに応じて編集します。 編集済み:計画されているフォローアップ作業と、私たちが当てはまらなかった作業が後で実施されることに同意されているため、プロジェクトは最初の締め切り後に続行される予定です。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.