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

13
それで、シングルトンは悪いのでしょうか?
最近、シングルトンの使用(および過剰使用)に関する問題について多くの議論がありました。私も私のキャリアの早い段階でそれらの人々の一人でした。現在、問題が何であるかを見ることができますが、良い選択肢を見つけることができない場合がまだ多くあります。反シングルトンの議論の多くは実際にそれを提供しません。 ここに私が関わった最近の主要なプロジェクトの実例があります: アプリケーションは、頻繁に更新されないサーバー状態からの大量のデータを使用する多くの個別の画面とコンポーネントを持つシッククライアントでした。このデータは基本的にシングルトンの「マネージャー」オブジェクト、つまり恐ろしい「グローバル状態」にキャッシュされていました。データの保存と同期を維持するアプリ内のこの場所を1つにして、サーバーからさまざまなサポートデータを繰り返し要求することなく、開いた新しい画面で必要なもののほとんどを照会できるようにするというアイデアでした。サーバーへの絶え間ないリクエストは帯域幅を使いすぎます-そして私は週に数千ドルの追加のインターネット請求書を話しているので、それは受け入れられませんでした。 基本的にこの種のグローバルデータマネージャーキャッシュオブジェクトを持つ以外に、ここで適切と思われる他のアプローチはありますか?もちろん、このオブジェクトは「シングルトン」である必要はありませんが、概念的には「シングルトン」であることが理にかなっています。ここできれいな代替品は何ですか?

10
コールチェーンのいくつかのレベルでのみ使用される(パラメータを渡す)パターンの名前はありますか?
私はいくつかのレガシーコードでグローバル変数を使用する代替案を見つけようとしていました。しかし、この質問は技術的な選択肢に関するものではなく、私は主に用語について心配しています。 明らかな解決策は、グローバルを使用する代わりに関数にパラメーターを渡すことです。このレガシーコードベースでは、値が最終的に使用されるポイントと最初にパラメーターを受け取る関数の間で、長い呼び出しチェーン内のすべての関数を変更する必要があることを意味します。 higherlevel(newParam)->level1(newParam)->level2(newParam)->level3(newParam) どこnewParam私の例では、グローバル変数以前だったが、それは代わりに、以前にハードコード値だったかもしれません。ポイントは、newParamの値がで取得されhigherlevel()、で「移動」する必要があることlevel3()です。 値を変更せずに「渡す」多くの関数にパラメータを追加する必要があるこのような状況/パターンの名前があるかどうか疑問に思っていました。 うまくいけば、適切な用語を使用することで、再設計のソリューションに関するリソースをさらに見つけ、同僚にこの状況を説明できるようになります。

7
マジックストリングの何が問題になっていますか?
経験豊富なソフトウェア開発者として、私は魔法の文字列を避けることを学びました。 私の問題は、それらを使用してから非常に長い時間であり、その理由のほとんどを忘れてしまったことです。その結果、私が経験の浅い同僚になぜ彼らが問題なのかを説明するのに苦労しています。 それらを避けるための客観的な理由は何ですか?それらはどのような問題を引き起こしますか?

9
制御フローとしての例外は深刻なアンチパターンと見なされますか?もしそうなら、なぜですか?
90年代後半に戻って、フロー制御として例外を使用するコードベースでかなり作業しました。テレフォニーアプリケーションを駆動する有限状態マシンを実装しました。最近、MVC Webアプリをやっているので、当時のことを思い出します。 どちらにもController、次に進む場所を決定し、データを宛先ロジックに提供するものがあります。DTMFトーンなどの旧式の電話のドメインからのユーザーアクションは、アクションメソッドのパラメーターになりましたがViewResult、aのようなものを返す代わりに、をスローしましたStateTransitionException。 主な違いは、アクションメソッドがvoid関数であったことだと思います。私はこの事実で私がしたことをすべて覚えていませんが、15年前のようにその仕事以来、私は他の仕事の生産コードでこれを見たことがないので、私は多くのことを覚える道を行くことをheしました。これはいわゆるアンチパターンであるという兆候だと思いました。 これは事実ですか?もしそうなら、なぜですか? 更新:質問をしたとき、@ MasonWheelerの回答をすでに念頭に置いていたので、私の知識に最も追加された回答を使用しました。彼も同様に正しい答えだと思います。

27
ソースコード生成はアンチパターンですか?
何かを生成できる場合、それはコードではなくデータです。 それを考えると、ソースコード生成のこの考え全体は誤解ではないでしょうか?つまり、何かのコードジェネレーターがある場合、そのパラメーターを、必要なパラメーターを受け取り、「生成される」コードが実行するはずの正しいアクションを実行できる適切な関数にしてみませんか。 パフォーマンス上の理由で行われている場合、それはコンパイラの欠点のように聞こえます。 2つの言語を橋渡しするために行われている場合、それはインターフェースライブラリの欠如のように聞こえます。 ここに何かが足りませんか? コードもデータであることを知っています。私が理解していないのは、なぜソースコードを生成するのですか?なぜそれをパラメーターを受け入れ、それらに作用することができる関数にしませんか?

11
「車輪の再発明」の反対のアンチパターンの名前は何ですか?[閉まっている]
「車輪の再発明」アンチパターンは非常に一般的なものです-すぐに使えるソリューションを使用する代わりに、独自にゼロから作成してください。コードベースは不必要に成長し、同じことをするわずかに異なるインターフェースがわずかに異なりますが、わずかに異なりますが、すぐに利用できる関数を書く(そしてデバッグする)時間は無駄になります。私たちは皆これを知っています。 しかし、スペクトルの反対側に何かがあります。2行のコードである独自の関数を作成する代わりに、フレームワーク/ API /ライブラリをインポートし、インスタンス化し、構成し、フレームワークで受け入れられるようにコンテキストをデータ型に変換し、必要なことを正確に行う1つの関数を呼び出します。ギガバイトの抽象化レイヤーの下の2行のビジネスロジック。そして、ライブラリを最新の状態に保ち、ビルドの依存関係を管理し、ライセンスの同期を維持する必要があります。また、インスタンス化のコードは、「車輪を再発明」した場合よりも10倍長く複雑です。 理由はさまざまです:コストに関係なく「車輪の再発明」に厳密に反対する経営陣、要件とわずかに重複しているにも関わらず、彼らの好みの技術を押している人まだ到着していないフレームワークの使用、またはいくつかのインポート/インクルード/ロード命令が「舞台裏」で伝える「重み」を誤解している。 この種のアンチパターンに共通の名前はありますか? (それが正しいか間違っているか、それが本当のアンチパターンまたは意見に基づいたものである場合、私は議論を始めようとはしていません。これは単純で客観的な命名法の質問です。) 編集:提案された「重複」は、外部システムとは完全に離れて、「すべての準備を整える」ために独自のコードをオーバーエンジニアリングすることについて語っています。このことはある場合にはそれから生じるかもしれませんが、一般的には「車輪の再発明への嫌悪感」に由来します。問題に対する「既製の」解決策が存在する場合、それがどの程度適合しておらず、どのような費用がかかっても、それを使用します。新しいコードの作成とメンテナンスのコストと比較した場合、これらの依存関係の統合とメンテナンスのコストを完全に無視して、コードの重複よりも新しい依存関係の作成を独断的に支持します。


30
コードを見ると、どのものがすぐに警報を鳴らしますか?[閉まっている]
数週間前にソフトウェア職人のイベントに参加しましたが、コメントの1つは「見たときに悪いコードをすべて認識していると確信している」というもので、誰も議論することなく賢くうなずきました。 この種のことは、誰もが自分が平均以上のドライバーだと思っているという真実があるので、常に私を心配しています。悪いコードは認識できると思いますが、他の人がコードの匂いだと考えるものについては、人々のブログやほんの一握りの本で詳細に議論されることはめったにないので、もっと学びたいと思います。特に、ある言語ではコード臭があり、別の言語では臭いがないものについて聞くのは面白いと思います。 簡単なものから始めます。 コメントアウトされたコードの割合が高いソース管理のコード -なぜそこにあるのですか?削除するつもりでしたか?それは半分完成した作品ですか?多分それはコメントアウトされるべきではなく、誰かが何かをテストしているときにのみ行われたのでしょうか?個人的には、この種のことは、それがあちこちの奇妙な行であっても本当に迷惑だと感じますが、コードの残りの部分に大きなブロックが散在しているのを見ると、まったく受け入れられません。また、通常、残りのコードも疑わしい品質である可能性が高いことを示しています。


14
このアンチパターンの名前は?ローカル変数としてのフィールド[終了]
私がレビューしているいくつかのコードでは、次のものと同等の道徳的なものを見ています: public class Foo { private Bar bar; public MethodA() { bar = new Bar(); bar.A(); bar = null; } public MethodB() { bar = new Bar(); bar.B(); bar = null; } } このフィールドbarは論理的にローカル変数です。これは、その値がメソッド呼び出し間で持続することを意図していないためです。ただし、メソッドの多くはFootypeのオブジェクトを必要とするBarため、元のコード作成者はtypeのフィールドを作成しましたBar。 これは明らかに悪いことですよね? このアンチパターンに名前はありますか?

6
EAV-すべてのシナリオで本当に悪いですか?
私は、プロジェクトのいくつかの要素にエンティティー属性値(EAV)モデルを使用することを考えていますが、Stack Overflowでのそれに関するすべての質問は、 EAVをアンチパターンと呼ぶ答えになります。 しかし、私はそれがすべての場合においてそれが間違っているかどうか疑問に思っています。 ショップ製品のエンティティを考えてみましょう。名前、説明、画像、価格など、ロジックに多くの場所で参加する共通の機能があり、時計やビーチボールなどの(半)固有の機能はまったく異なる側面で説明されます。したがって、EAVはそれらの(半)固有の機能を格納するのに適していると思います。 これはすべて、製品リストを表示するために製品テーブルに十分な情報があり(EAVが関与しないことを意味します)、1つの製品を表示するとき/最大5つの製品などを比較するときだけです。EAVを使用して保存されたデータが使用されます。 Magentoコマースでそのようなアプローチを見てきましたが、非常に人気がありますが、EAVが妥当な場合はありますか?

8
受信パラメータの変更はアンチパターンですか?[閉まっている]
私はJavaでプログラミングしており、常にコンバーターを次のように作成しています。 public OtherObject MyObject2OtherObject(MyObject mo){ ... Do the conversion return otherObject; } 新しい職場でのパターンは次のとおりです。 public void MyObject2OtherObject(MyObject mo, OtherObject oo){ ... Do the conversion } 私にとっては、着信パラメータを変更しないことに慣れていたので、少し臭いです。この着信パラメータの変更はアンチパターンですか、それとも大丈夫ですか?重大な欠点がありますか?

8
ORMは反パターンですか?[閉まっている]
ORMとその長所と短所について同僚と非常に刺激的で興味深い議論をしました。私の意見では、ORMは非常にまれな場合にのみ役立ちます。少なくとも私の経験では。 しかし、現時点では自分の主張をリストしたくありません。それでは、ORMについてどう思いますか?長所と短所は何ですか?


8
「まだ行われていない場合に何かを行う」という用語(または「パターン」?)[クローズ]
かなり基本的に聞こえますが、最近、同僚に、呼び出されたメソッドstartHttpServerがまだ実行されていない場合にサーバーを起動するだけなので、理解するには複雑すぎると言われました。「真剣に?私はこれを何十年も続けてきました。これはプログラミングの一般的なパターンです」と答えたとき、私はトラブルに陥ります。私が認めようと思うよりも頻繁に、彼は、プログラミングコミュニティ全体が彼の視点の背後にあることを示す文書化された証拠とともに戻ってきて、私はひどい気持ちになります。 質問:必要なアクションが既に有効になっている場合、ノーオペレーションであるメソッドの概念の背後にある文書化された設計パターンはありますか?または、パターンでない場合、名前もありますか?そうでない場合、この方法でメソッドを記述することを検討するのが複雑すぎると考える理由はありますか?

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