タグ付けされた質問 「anti-patterns」

最近、私は人間に優しいクラス名でJavaコレクションを「マスキング」する習慣を身につけています。いくつかの簡単な例： // Facade class that makes code more readable and understandable. public class WidgetCache extends Map<String, Widget> { } または： // If you saw a ArrayList<ArrayList<?>> being passed around in the code, would you // run away screaming, or would you actually understand what it is and what // it …

46 java  anti-patterns  generics  collections 

プロジェクトの既存のモジュールを拡張する必要があります。私はそれが行われた方法が好きではありません（コピー/貼り付けられたコードのような、アンチパターンがたくさんあります）。多くの理由で完全なリファクタリングを実行したくありません。 したほうがいい： 次のメンテナーとの混乱を避け、コードベースとの一貫性を保つために、間違っていると感じたとしても、既存の規則を使用して新しいメソッドを作成しますか？ または コードに別のパターンを導入している場合でも、私が気分が良いものを使用してみてください？ 最初の回答後に編集された精度： 既存のコードは混乱ではありません。簡単に理解できます。しかし、良いデザインで回避できる多くの定型コードを導入しています（その結果、コードを追跡するのが難しくなるかもしれません）。私の現在のケースでは、古き良きJDBC（インボードのスプリングテンプレート）DAOモジュールですが、すでにこのジレンマに遭遇しており、他の開発者フィードバックを探しています。 時間がないので、リファクタリングしたくありません。そして、時間が経っても、完全に機能するモジュール全体にリファクタリングが必要であることを正当化するのは困難です。リファクタリングのコストは、そのメリットよりも重いでしょう。覚えておいてください：コードは乱雑でも複雑でもありません。そこにいくつかのメソッドを抽出して、ここで抽象クラスを紹介することはできません。それは設計上の欠陥です（極端な「愚かなシンプルを保つ」の結果だと思います） したがって、質問はそのように尋ねることもできます： 開発者として、あなたは簡単な愚かな退屈なコードを維持することを好みますか、またはあなたの場所で愚かな退屈なコードを行うヘルパーを持っていますか？ 最後の可能性の欠点は、いくつかのことを学ばなければならず、完全なリファクタリングが完了するまで、簡単な愚かな退屈なコードを維持しなければならないことです）

45 refactoring  coding  maintenance  anti-patterns 

実行を停止してはならないいくつかのエラーを処理するためにerror、クライアントがチェックして例外をスローするために使用できる変数があります。これは反パターンですか？これを処理するより良い方法はありますか？この動作の例については、PHPのmysqli APIをご覧ください。可視性の問題（アクセサ、パブリックスコープとプライベートスコープ、クラス内の変数はグローバルですか？）が正しく処理されると仮定します。

44 design-patterns  object-oriented  exceptions  patterns-and-practices  anti-patterns 

私の同僚は、「ロギング/キャッシングなどが横断的な関心事である」と言ってから、対応するシングルトンをどこでも使用して進めます。それでも、彼らはIoCとDIが大好きです。 SOLI Dの原則を破ることは本当に正当な言い訳ですか？

43 dependency-injection  solid  anti-patterns  singleton 

私が仕事で取り組んでいる大規模なプロジェクトのライブラリを作成しているときに、トークンを電子メールアドレスに送信する必要があるという問題が発生し、その後コードに戻されてさらに使用できるようになりました。 私の同僚は（Pythonを使用してcode = input("Enter code: ")）STDINから読み、それをユーザーに渡すように言っていますが、私にはライブラリがサーバー上のバックグラウンドタスクで使用される可能性があるため（この場合は間違いなく）、これは悪い習慣のようです。 これがアンチパターンと見なされるかどうか疑問に思っていました。

39 programming-practices  libraries  anti-patterns 

クラスに関係のない関数をどこに置くべきかという質問は、C ++でクラス内のユーティリティ関数を結合するのが理にかなっているのか、それとも名前空間にフリー関数として存在するのかという議論を巻き起こしました。 私は、後者のオプションが存在しないC＃のバックグラウンドから来ているため、私が書いている小さなC ++コードで静的クラスを使用する傾向があります。しかし、その質問に対する最高の投票された回答といくつかのコメントは、静的なクラスがアンチパターンであることを示唆していても、無料の関数が優先されるべきであると述べています。C ++ではなぜそうなのですか？少なくとも表面的には、クラスの静的メソッドは、名前空間の自由な関数と見分けがつかないように見えます。なぜこのように後者を好むのですか？ ユーティリティ関数のコレクションが何らかの共有データを必要とする場合、たとえば、プライベート静的フィールドに保存できるキャッシュなど、状況は異なりますか？

39 c++  design-patterns  anti-patterns 

私は同僚と議論をしていましたが、最終的にはサブクラス化の目的に関して直感が矛盾することになりました。私の直感では、サブクラスの主な機能がその親の限られた範囲の値を表現することであれば、おそらくサブクラスであってはならないということです。彼は反対の直観を主張しました：サブクラス化はオブジェクトがより「特定的」であることを表し、したがってサブクラス関係がより適切であるということです。 私の直感をより具体的に言うと、親クラスを拡張するサブクラスがあるが、サブクラスがオーバーライドする唯一のコードがコンストラクターである場合（そう、コンストラクターは一般に「オーバーライド」しないことを知っています。本当に必要だったのは、ヘルパーメソッドです。 たとえば、このやや現実的なクラスを考えてみましょう。 public class DataHelperBuilder { public string DatabaseEngine { get; set; } public string ConnectionString { get; set; } public DataHelperBuilder(string databaseEngine, string connectionString) { DatabaseEngine = databaseEngine; ConnectionString = connectionString; } // Other optional "DataHelper" configuration settings omitted public DataHelper CreateDataHelper() { Type dataHelperType = DatabaseEngineTypeHelper.GetType(DatabaseEngine); DataHelper …

37 design-patterns  object-oriented  inheritance  anti-patterns 

次の設計を検討してください public class Person { public virtual string Name { get; } public Person (string name) { this.Name = name; } } public class Karl : Person { public override string Name { get { return "Karl"; } } } public class John : Person { public override string Name …

37 programming-practices  inheritance  class-design  anti-patterns 

モノのストリームがあり、それらを途中で「強化」したい場合peek()、これを行うために使用できます。たとえば： streamOfThings.peek(this::thingMutator).forEach(this::someConsumer); コードのこの時点でthingMutatorモノを変更することは正しい動作であると仮定します。たとえば、メソッドは「lastProcessed」フィールドを現在の時間に設定できます。 ただし、peek()ほとんどのコンテキストでは、「見て、触れないでください」という意味です。 ストリーム要素の突然変異にアンチパターンを使用peek()していますか？ 編集： より一般的な代替アプローチは、消費者を変換することです。 private void thingMutator(Thing thing) { thing.setLastProcessed(System.currentTimeMillis()); } パラメータを返す関数に： private Thing thingMutator(Thing thing) { thing.setLastProcessed(currentTimeMillis()); return thing; } map()代わりに使用します： stream.map(this::thingMutator)... しかし、それは機能的なコード（return）を導入しpeek()、同じオブジェクトを返すことを知っているので、それがより明確であるとは確信していませんがmap()、同じクラスのオブジェクトであることは一目でさえわかりません。 さらに、peek()あなたは突然変異するラムダを持つことができmap()ますが、列車の残骸を構築する必要があります。比較する： stream.peek(t -> t.setLastProcessed(currentTimeMillis())).forEach(...) stream.map(t -> {t.setLastProcessed(currentTimeMillis()); return t;}).forEach(...) 私は思うpeek()ので、何の「神秘的」副作用はありません、バージョンが明確で、かつラムダは明らかに変異されます。同様に、メソッド参照が使用され、メソッドの名前が明らかに突然変異を暗示している場合、それも明確で明白です。 個人的には、peek()突然変異に使うことをためらわない-非常に便利だと思う。

37 java  anti-patterns  java8  stream-processing  mutable 

いくつかの名前があります。それらの名前に手を伸ばせば、すでに何かを台無しにしていることがわかります。 例えば： XxxManager クラスはクラスが何をするのかを記述する必要があるため、これは良くありません。クラスが行うことに対して思いつく最も具体的な単語が「管理」である場合、クラスは大きすぎます。 他にどのようなアンチパターンが存在しますか？ 明確にするために、私は「どのような名前が悪いのか」とは問いません。その質問は完全に主観的なものであり、それに答える方法はありません。「システムの全体的な設計上の問題を示す名前は何ですか」と私は尋ねています。つまり、コンポーネントXyzを呼び出したい場合は、おそらくコンポーネントが不十分であることを示しています。また、すべてのルールには例外があることに注意してください-私は本当にデザインを停止して再考する必要がある場合の警告フラグを探しています。

35 naming  anti-patterns 

私は悪いプログラミング習慣に関する記事を読んでいました。 言及した- 値を別の表現に変換してから元の位置に戻す「ヨーヨーコード」（例：小数を文字列に変換してから小数に戻す、または文字列をパディングしてからトリミングする） 彼が与えた特定の例がプログラムを書くのに悪い方法である理由を私は理解していません。値を使用できるように状況が必要な場合は、元に戻すことは問題ないようです。 誰でもこれについて説明できますか？

35 programming-practices  anti-patterns 

コードレビューの後、デザインの選択について議論したところです。あなたの意見は何でしょうか。 このPreferencesクラスは、キーと値のペアのバケットです。NULL値は正当です（重要です）。特定の値がまだ保存されていない可能性があり、要求されたときに事前定義されたデフォルト値で初期化することにより、これらのケースを自動的に処理したいと考えています。 説明したソリューションでは、次のパターンを使用しました（注：これは実際のコードではなく、明らかに-説明のために単純化されています）。 public class Preferences { // null values are legal private Map<String, String> valuesFromDatabase; private static Map<String, String> defaultValues; class KeyNotFoundException extends Exception { } public String getByKey(String key) { try { return getValueByKey(key); } catch (KeyNotFoundException e) { String defaultValue = defaultValues.get(key); valuesFromDatabase.put(key, defaultvalue); return defaultValue; } …

33 java  programming-practices  coding-style  exceptions  anti-patterns 

最近、分岐とマージとSCMについてのMSDNの記事に出くわしました：分岐とマージプライマー-Chris Birmele。 記事では、「ビッグバンマージ」はマージアンチパターンであると述べています。 Big Bang Merge —開発作業の最後までブランチのマージを延期し、すべてのブランチを同時にマージしようとします。 これは、私の会社が生産されているすべての開発ブランチで行っていることに非常に似ていることに気付きました。 私は非常に小さな会社で働いており、1人が最終審査とトランクマージの権限を持っています。5人の開発者（私を含む）がいて、それぞれに個別のタスク/バグ/プロジェクトが割り当てられ、それぞれ現在のトランク（subversion）から分岐し、分岐で開発作業を実行し、結果をテストし、ドキュメントを作成します。必要に応じて、他の開発者とピアレビューとフィードバックループを実行し、プロジェクト管理ソフトウェアでレビュー+マージのためにブランチを送信します。 トランクリポジトリの唯一の権限である私のボスは、ブランチのレビューのすべてを実際に可能な限りレビューを行う単一の時点まで延期し、一部のブランチは拡張/修正のためにスローバックされます。ブランチはすぐにトランクにマージされ、一部のブランチは競合などのためにスローバックされます。 10〜20のアクティブなブランチを最終レビューキューに入れてトランクにマージすることは珍しくありません。 また、2つのブランチが同じトランクから作成されたものの、同じコードを変更したため、最終レビューとマージの段階で競合を頻繁に解決する必要があります。通常、これを回避するには、トランクから分岐し直して変更を再適用し、競合を解決してから、レビューのために新しいブランチを送信します（poor mans rebase）。 私が持っているいくつかの直接的な質問は次のとおりです。 「ビッグバンマージ」と呼ばれる非常にアンチパターンを示していますか？ このマージプロセスの結果に見られる問題の一部はありますか？ 上司のボトルネックを増やすことなく、このマージプロセスを改善するにはどうすればよいですか？ 編集：私の上司がトランクリポジトリに対する彼のグリップを緩めるか、他の開発者がトランクにマージできるようにすることを疑います。彼の理由は定かではありませんが、私はこのトピックを取り上げるつもりはありません。なぜなら、それは以前に取り上げられており、かなり早く撃downされたからです。彼らは私たちを信じていないだけだと思いますが、とにかくすべてが追跡されているので意味がありません。 この状況に関する他の洞察は歓迎されます。

28 svn  anti-patterns  merging  scm 

過去数ヶ月間、私は次のテクニック/パターンで数回つまずきました。しかし、特定の名前を見つけることはできないようです。また、その長所と短所を100％確信しています。 パターンは次のとおりです。 Javaインターフェース内では、一般的なメソッドのセットが通常どおり定義されます。ただし、内部クラスを使用すると、デフォルトのインスタンスがインターフェースを介してリークされます。 public interface Vehicle { public void accelerate(); public void decelerate(); public static class Default { public static Vehicle getInstance() { return new Car(); // or use Spring to retrieve an instance } } } 私にとって、最大の利点は、開発者がインターフェイスについてのみ知る必要があり、実装についてではなく、インスタンスをすぐに作成したい場合などです。 Vehicle someVehicle = Vehicle.Default.getInstance(); someVehicle.accelerate(); さらに、構成に応じてインスタンスを動的に提供するために、Springと共にこの手法が使用されているのを見てきました。この点で、これもモジュール化に役立つようです。 それにもかかわらず、インターフェイスを実装の1つと結合するため、これがインターフェイスの誤用であるという感覚を揺るがすことはできません。（依存性反転の原理など。）誰もがこの技術がどのように呼ばれるか、そしてその長所と短所を私に説明してもらえますか？ 更新： しばらく検討した後、次のシングルトンバージョンのパターンがはるかに頻繁に使用されていることを再確認しました。このバージョンでは、パブリックの静的インスタンスは、（フィールドが最終であるために）1回だけ初期化されるインターフェイスを介して公開されます。さらに、インスタンスはほとんどの場合、Springまたは実装からインターフェイスを分離する汎用ファクトリーを使用して取得されます。 public interface Vehicle …

28 java  interfaces  anti-patterns  technique 

複数の開発者がシステムに新しい機能を追加しただけで、アーキテクチャ全体を実際に監視したり、リファクタリングを実行したりしない、歴史的に成長したソフトウェアシステムを説明するアンチパターンはありますか？ これは、管理者/顧客が絶えず新しい機能を要求し、誰も何もリファクタリングせず、他の開発者が以前に行ったことに追加するだけの場合に起こると思います。 開発者がソフトウェアシステムに圧倒されており、現在どのように機能するかを実際に理解していないため、コードをリファクタリングして変更するのではなく、最後にコードを追加/接着するだけの場合もあります。 そのため、時間の経過とともに、システムの保守がますます難しくなっています。 （これらの種類のアンチパターンの写真は、プログラミング全体に誰もがこれをより明確にするためにありますか？全体的なデザインを考えずに機能を追加するだけで構築された車のように。後方に移動しながらトレーラーを牽引し、エンジニアが車両の前面に牽引バーを溶接するだけです。作業は完了しました。しかし、カウルはもう開きません。）

28 design  terminology  anti-patterns  technical-debt  legacy-code