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

腐敗防止レイヤーの本当の意味を理解しようとしています。私はそれがレガシーコードまたは悪いAPIを移行/回避する方法であることを知っています。私が理解していないのは、それがどのように機能し、何が望ましくない層からきれいに分離するのかということです。 私はいくつかの検索を行いましたが、簡単な例や説明が見つからないため、それを理解し、簡単な例で説明できる人を探しています。私の質問を満足させる答えは、単純なものである必要があり（必ずしも短くはありません）、実装と使用のわかりやすい例を提供する必要があります。 私のユースケースについては、この質問を参照してください。

151 design-patterns  api-design  legacy  bad-code 

クライアントから、別のコンサルタントが開発したASP.NET WebformsアプリケーションであるWebサイトの再設計を依頼されました。比較的簡単な仕事のように見えましたが、コードを見てみると、そうではないことは明らかです。 このアプリケーションはうまく書かれていません。まったく。SQLインジェクション攻撃に対して非常に脆弱であり、ビジネスロジックがアプリケーション全体に広がっており、多くの重複があり、デッドコードは何もしません。その上、それは窒息させられている例外をスローし続けるので、サイトはスムーズに実行されるように見えます。 私の仕事は単純にHTMLとCSSを更新することですが、HTMLの多くはビジネスロジックで生成されており、整理するのは悪夢です。再設計に関する私の見積もりは、クライアントが目指していたよりも長くなっています。彼らはなぜそんなに長いのか尋ねています。 このコードがどれほど悪いかをクライアントに説明するにはどうすればよいですか？彼らの頭の中では、アプリケーションは素晴らしい動きを見せており、再設計は一回限りのものにすべきです。前のコンサルタントに対する私の言葉です。非技術系クライアントが理解できる簡単で具体的な例を挙げるにはどうすればよいですか？ 更新 すべての回答をありがとう。SQLインジェクション攻撃のデモは理にかなっており、これをテスト環境でデモします。これは、このアプリケーションの多くの問題のほんの一部です。私は、htmlとcssの更新を行うために、他の部分（データレイヤーで生成されるhtmlなど）をより良いプラクティスに置き換える必要がある理由を説明する方法を探していました。ここには多くの良い提案がありますが、クライアントと話をするときに一緒にまとめます。

129 freelancing  client-relations  bad-code 

ループに入れ子になったループから抜け出すために保存することを理解しています。このgotoステートメントは回避され、バグが発生しやすいプログラミングスタイルとして悪用され、決して使用されることはありません。 代替テキスト： 「ニール・スティーブンソンは自分のラベルに「dengo」という名前を付けるのはかわいいと思っている」 オリジナルのコミックを参照：http : //xkcd.com/292/ 私はこれを早く学んだからです。どんな種類のバグがgoto実際につながるのかについての洞察や経験は本当にありません。ここで何を話しているのか： 不安定？ 維持不能または読み取り不能なコード？ セキュリティの脆弱性？ 完全に何か他のもの？ 「goto」ステートメントは実際にどのようなバグにつながりますか？歴史的に重要な例はありますか？

103 coding-style  history  bug  bad-code  goto 

昨日、私は「趣味」のプログラマーと話し合っていました（私自身はプロのプログラマーです）。私たちは彼の仕事のいくつかに出会い、彼は彼のデータベースのすべての列を（実動サーバー/コード上でも）常に照会すると言いました。 私は彼にそうしないように説得しようとしたが、まだそれほど成功していなかった。私の意見では、プログラマーは、「可愛さ」、効率、およびトラフィックのために実際に必要なものだけを照会する必要があります。私の見方に誤りがありますか？

96 database  sql  mysql  bad-code 

Linus Torvaldsによるこの有名な暴言を読んだ後、私は実際にC ++のプログラマーにとっての落とし穴は何なのか疑問に思いました。私はこの質問とその回答で扱われているタイプミスや悪いプログラムフローを明示的に言及していませんが、コンパイラによって検出されず、最初の実行時に明らかなバグ、完全な設計エラーを引き起こさないより高レベルのエラー、 Cではありえないが、コードの完全な意味を理解していない新参者がC ++で行う可能性が高いこと。 また、通常は予想されないパフォーマンスの大幅な低下を指摘する回答も歓迎します。私が書いたLR（1）パーサージェネレーターについて、ある教授が私に言ったことの例： 不要な継承と仮想性のインスタンスを使用しすぎています。継承は設計をより複雑にし（RTTI（実行時型推論）サブシステムのために非効率的です）、したがって、たとえば解析テーブルのアクションなど、理にかなっている場合にのみ使用する必要があります。テンプレートを集中的に使用するため、実質的に継承は必要ありません。」

35 c++  errors  mistakes  bad-code 

すべてのプログラミングプロジェクトについて、過去のプログラミング経験のあるマネージャーは、プロジェクトのデザインパターンを推奨するときに輝かそうとします。理にかなっている場合、またはスケーラブルなソリューションが必要な場合、デザインパターンが好きです。たとえば、プロキシ、オブザーバー、コマンドパターンを積極的に使用してきましたが、毎日そうしています。しかし、オブジェクトを作成する方法が1つしかない場合、Factoryは将来的にすべてを簡単にする可能性がありますが、コードを複雑にし、純粋なオーバーヘッドであるため、Factoryパターンを使用することを本当にためらっています。 だから、私の質問は私の将来のキャリアと、ランダムなパターン名を投げるマネージャータイプに対する私の答えです： どのデザインパターンを使用しましたか？最悪の設計パターンはどれですか、それらが理にかなっている単一の状況を除いて考慮する必要があるものです（読んでください：どの設計パターンが非常に狭く定義されています）？（アマゾンの全体的な良い製品のネガティブなレビューを探して、デザインパターンを使用する際に最もバグを起こした人々を探しているようです。）そして、ここでアンチパターンについてではなく、通常と考えられるパターンについて話しています「良い」パターン。 編集：一部の人が答えたように、問題はほとんどの場合、パターンが「悪い」のではなく「間違って使用されている」ことです。パターンを知っていれば、それはしばしば誤用されるか、使用するのが難しい場合でも、答えとして当てはまります。

28 bad-code  anti-patterns  patterns-and-practices  design-patterns 

現在のプロジェクトでは、JSONのみをサポートするものとして文書化されている、新しく作成されたRESTful APIの使用を伴うサービスの実装を担当しています。 クライアントは、一貫して「application / json」のacceptヘッダーと「application / json」のcontent-typeで要求を行います。ただし、一部のエンドポイントは、HTMLのコンテンツタイプ、さらにはHTML本文で応答を送信します。私にとってこれは明らかに間違ったアプローチであり、正当化することはできません。 プロジェクト全体を通して、この同じプラクティスが2つの異なるベンダーと2つの異なるサービスに適用されています。サービスを変更する必要がある理由を正当化する必要があることに気づきました。ベンダーは、クライアントはこれに対処する必要があると述べており、デフォルトの「箱から出して」これに対処しないため、選択したRESTライブラリでさえ疑問視されています（RestEasy）。 これはフラストレーションの大きなポイントでした。私の主張を裏付ける多くの参考文献を見つけることができません。これは、それが非常に明白であるので、ポイントが議論の余地があるからだと思います。 問題は、何かが足りないということですか？私はこれについて熱心ですか？このシナリオでcontent-typeのapplication / jsonを持たないJSON APIを使用しても大丈夫ですか？参照をいただければ幸いです。商業的な観点からこの状況をどのように解決しますか？

25 rest  api-design  json  bad-code 

既存のサードパーティ製ソフトウェアの拡張機能を作成しようとしていたため、そのデータベースは恐ろしく非正規化されていたため、これを考えていました。既存のテーブルを使用して、多数の新しいフィールドを追加する必要がありました。 デザインスタイル（1つの大きなテーブルにあるほとんどすべてのプロパティで構成される）で新しいテーブルを作成するか、新しいテーブルセットを一緒に作成し、トリガーなどの特別なものを使用して、新しいテーブルと古いテーブル。 結局、既存の貧弱なデザインスタイルを使用するという最初のオプションに行き着きましたが、この質問が残されました：既存の悪い慣行に行くのか、既存のコードにうまく合わない良い慣行を実装するのが良いのでしょうか？どちらかを選択する必要がある状況はありますか？ 注：これまでの多くの答えは、悪いコードをゆっくりとリファクタリングすることに関係していますが、私はそれをすることができません。コードは私たちのものではなく、ベンダーによって頻繁に更新されます。私はそれの上にのみ構築できます。

25 code-quality  coding-standards  bad-code 

私は現在、私の仕事で以前働いていたいくつかの開発者によって構築されたシステムをレビューしています。システムはユーザーの観点からはかなりうまく機能しますが、コードレビューを掘り下げると、まったく混乱します。私は、アプリケーションの構築方法が将来の更新に耐えられず、使用量が大幅に増加することはないと確信しています。 問題は、それがどれほど悪いかは知っているが、上司はそうではないということです。マネージャーにそれを証明して問題を実際に確認し、現在のコードベースで最小限のトリアージを行い、近い将来、アプリケーションの次のバージョンの新しい開発ラインを開始できるようにするにはどうすればよいですか？

23 code-reviews  bad-code 

私がキャリアで出くわした繰り返しのテーマは、チームに到着する新しい開発者であること、そして既存のユニットと統合テストスイートに対する固有の不信をすぐに持つことです。 面接中に、経営陣から「ユニットテストを強力にサポートしている」ことと、それを公然と奨励していることが伝えられます。彼らはそうしますが、テスト自体についてのすべては単に間違っています。100％の統合テストカバレッジがあり、10％未満の反復可能な単体テストカバレッジがある場合、100％のカバレッジを主張しているという事実と同様です。私が見つけた他のいくつかの問題： 単体テストと統合テストの間に明確な兆候はありません。単体テストと統合テストは、同じクラスに混在しています。 特定の環境のデータベース上の非常に特定の動的データに対する未宣言の明示的な依存関係がある統合テスト。 非トランザクション統合テスト。基本的には、後からクリーンアップするかどうかわからないテストであり、テストを再現可能にするために手動のデータベース「スクラビング」が必要になる場合があります。 モッキングは一切行われません。アプリケーションコードでは、モッキングを可能にするためだけに大幅な見直しが必要です。つまり、テストを考慮せずに設計します。 テスト名をすばやく確認して、実行中のテストを大まかに判断するための明確な命名規則はありません。 これは、すべてのテストが役に立たないか悪いというわけではなく、かなりの数のテストが非常に良く、維持する価値があると言っているわけではありませんが、金のためにパンするような気がします。ブラックボックステストケースのデータベースを台無しにするのが怖かったからといって、意図的にテストを実行することは避けました。 これは本質的に、私が個人的に何らかの方法で書いたりレビューしたりしていないユニットおよび統合テストの固有の不信感を与えました。あるレベルでは、テストスイートの品質を信頼していない場合、チームやプロジェクトにはまったく価値がありません。 この状況に陥ったとき、あなたはどうしますか？攻撃の最善の計画は、このようなものに取り組むことだと思いますか？ すべてのテストをリリース間で途方もない努力でリファクタリングする必要がありますか？このレガシープロジェクトが1日の強固な単体テストの対象となる可能性があるという考えを捨てる必要がありますか？

21 unit-testing  team  refactoring  bad-code  integration-tests 

TheDailyWTFだけでなくSOにも、意図的に悪いコードに関する多くの話があります。典型的なケースは次のとおりです。 無駄な時間を浪費する構造（たとえば、巨大な値にカウントする空のループ）があるため、プログラマーは、タスクを削除することでアプリケーションを簡単に「高速化」できます。 意図的に誤解を招く、間違っている、またはまったくドキュメントを提供して、高価なサポートリクエストを生成する。 すぐにエラーを生成するか、さらに悪いことに、すべてが正常に機能していても生成され、ロックを解除するために高価なサポート呼び出しが必要になるようにアプリケーションをロックします。 これらのポイントは、多かれ少なかれ悪意のある態度を示しますが（場合によっては偶然であっても）、特に最初のポイントはかなり頻繁に発生します。 そのような構成体をどのように扱うべきですか？問題を無視するか、問題のあるコードを削除しますか？上司に通知するか、「機能」を紹介した人に話しますか？

21 bad-code 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私は大企業の請負業者です。現在、プロジェクトには3人の開発者がいますが、私も含めています。 問題は、他の2人の開発者が実際に理解していないことです。「それ」とは、次のことを意味します。 彼らは私たちが使用している技術のベストプラクティスを理解していません。私と他の人が彼らに例を与えてから6ヶ月後、ひどいアンチパターンが使用されています。 彼らは、主にスパゲッティコードを生成する「コピーアンドペースト」プログラマです。 彼らは絶えず物事を壊し、変更を実施しますが、すべてが良いかどうかを確認するための基本的な煙のテストを行いません 彼らは、コードレビューの依頼を拒否/​​まれにしています。 彼らは、コードのフォーマットなどの基本的なことを拒否/まれに行います。 クラスに関するドキュメントはありません（jsdocs） 何もしないコードを削除することを恐れる バージョン管理を行っていても、コメントされたコードブロックはどこにでも残します。 他のコードをフォーマットし、バグを修正し、壊れた機能を発見し、スパゲッティを削除するための抽象化を作成するにつれて、私はますますイライラしています。 私は本当に何をすべきかわかりません。欲求不満にならないようにしていますが、それは単なる混乱です。私はこれらの人々を人間として気に入っていますが、コーディングの状況がひどく、一日中ウェブを閲覧していれば、より速く動くことができると感じています。 マネージャーに他のsvnコミットアクセスを確認するように依頼するのは行外でしょうか。コミットは、私たちがやっていることに精通している人によるレビュー後にのみ行うことができますか？請負業者として、それが最善の策かどうかはわかりません。 修正しているものの数を明確にする微妙な/それほど微妙でない方法はありますか？

17 bad-code 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私はかなり大きくてバグのあるアプリケーションに取り組んでいます-それが書かれている方法のために（詳細は省きますが、あなたが考えることができるほとんどの分野でルールに違反します）、大きなリファクタリングなしでそれを開発することはほとんど不可能です。 アプリの重要な部分は、インターン、n00bsなどによって作成されました。しかし、Master Developerの階級にプログラマーもいました。そして、謙虚に、彼が残したコードも、おそらくは別の方法で疑わしいです。 確かに、彼のコードはほとんどの場合、仕事を終わらせる傾向がありますが、通常はわかりにくく、車輪を再発明します（たとえば、通常のSQL dbバックアップを実現する大きなカスタムメソッド）など。基本的に、不必要な混乱と多くのオーバーエンジニアリング そして、他の資質を伴わない場合、高度に熟練したコーダーであること（私は意図的に「開発者」という単語をより広いスキルのセットを示すと仮定して使用しません）が実際には有毒であると考えるようになりました。 それが真実だと仮定すると、私が考えることができるいくつかの理由は次のとおりです。 簡単にコーディングしている場合、ライブラリや既存の機能などを使用せずに、その場で独自のソリューションを簡単にスナップアウトできる（または実際には短期的には）と感じます。 複雑なプログラムのメンタルイメージを簡単に維持できる十分な経験がある場合、それをモジュール、レイヤーなどに分割する傾向は低くなります。 私のポイントは、流なコーダーが偶然悪い開発者である場合、流fluさは後者を補うだけでなく、実際にはむしろより多くの害をもたらすということです。 あなたはそれをどう思いますか？それは本当ですか？

16 refactoring  skills  bad-code  reinventing-the-wheel 

難問：新機能の作業中または欠陥の修正中に、コードに古い問題が見つかります。あなたは何をするべきか？それを修正し、コードの動作を変更する危険を冒してください。それは、これまでに何らかの欠陥によってうまく機能しているか、あるいは欠陥が検出されていないか、報告する時間がないかのどちらかです。そのままにして、問題が原因でコードを後で操作しにくくする必要がありますか？問題を修正すると、元のタスクの時間が増えるだけで、強制的に回帰テストが行​​われます。仕事に感謝する人はほとんどいません。しかし、それを修正することは、どういうわけか正しいようです。問題の少ないコードは、リファクタリングやビルドが簡単です。 Webアプリケーションの近代化に取り組んでいるとき、私はこの状況に何度も気づきました。これらの古いバグに取り組んでいるとき、自分が強迫観念を持っているのか、それとも名誉あるのかはわかりません。これらの状況をどのように処理しますか？ ありがとう、コーリー

15 code-quality  bad-code  refactoring  maintenance 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 7年前に閉鎖されました。 あなたがプレッシャーにさらされているとき、締め切りが近づいており、マネージャーがあなたの首に息を吹きかけています。あなたはあなた自身が悪いコードを書き始めていると思いますか？TDDとベストプラクティスは、物事を成し遂げるために脇道をすり抜けますか？そのような状況では何をしますか？どんな経験をしましたか？

14 bad-code