問題タブ [refactoring]

安定したコードにアクセスできるが、バグを簡単に導入できるほどきれいなコードがない大規模なチームを処理する最良の方法は何ですか?

ファイルをロックするSVNの行に沿って何かを探しています。

変数を 1 行で宣言するのが悪い習慣なのはなぜですか?

例えば

それ以外の：

表 1: キッチン シンクを含むすべて。間違った形式の日付 (最後の年なのでその列でソートできない)、VARCHAR として格納された数値、「番地」列に完全な住所、名列に名と姓、名字列に市区町村、不完全な住所、何年にもわたって変更された一連のルール、重複レコード、不完全なレコード、ガベージレコードに基づいて、あるフィールドから別のフィールドにデータを移動することにより、前の行を更新します...名前を付けます...ああ、もちろん、TIMESTAMPまたはPRIMARYではありませんKEY 列が見えます。

表 2: この赤ん坊をクラックして開いた時点で、正常化の望みはすべて消え去りました。各エントリに行があり、テーブル 1 の行を更新します。したがって、明日はありません (800MB 相当) のような重複と、Phone1 Phone2 Phone3 Phone4 ... Phone15 のような列 (これらは phone とは呼ばれません。説明のためにこれを使用します) 外部キーは..よく推測してください。table1 の行にどのようなデータがあったかによって、3 つの候補があります。

表 3: 悪化することはありますか? そうそう。「外部キーは、ダッシュ、ドット、数字、および文字の VARCHAR 列の組み合わせです! それが一致しない場合 (多くの場合一致しません)、同様の製品コードの 2 番目の列が必要です。それらの中のデータとの相関関係はなく、必須の Phone1 Phone2 Phone3 Phone4... Phone15. Table1 から複製された列があり、TIMESTAMP または PRIMARY KEY 列が見えません。

表 4: 進行中の作業として説明されており、いつでも変更される可能性があります。それは本質的に他のものと似ています。

100 万行近くになると、これは大混乱です。幸いなことに、それは私の大きな混乱ではありません。残念ながら、「顧客」ごとに複合レコードを引き出す必要があります。

最初に、Table1 に PRIMARY KEY を追加し、すべての日付をソート可能な形式に変換する 4 つのステップの変換を考案しました。次に、Table1 を使用して他のテーブルからプルしてコンポジットを形成できるようになるまで、フィルタリングされたデータを返すクエリのステップをさらに 2 つ実行します。数週間の作業の後、いくつかのトリックを使用してこれを 1 つのステップにまとめました。これで、アプリを混乱に向けて、複合データのきれいなテーブルを引き出すことができます。幸いなことに、目的に必要な電話番号は 1 つだけなので、テーブルの正規化は問題になりません。

毎日何百人もの従業員が想像もつかない方法でこのデータベースを追加/更新/削除し、毎晩新しい行を取得する必要があるためです。

どのテーブルの既存の行も変更可能であり、TIMESTAMP ON UPDATE 列がないため、何が起こったのかを知るためにログに頼る必要があります。もちろん、これはバイナリログがあることを前提としていますが、ありません!

鉛風船のように下がったコンセプトをご紹介。私は彼らの子供たちが実験的な手術を受けなければならないだろうと彼らに言ったかもしれません. 彼らは正確にはハイテクではありません...あなたが集めていなかった場合に備えて...

私の会社がひどく欲しがっている貴重な情報を彼らが持っているので、状況は少しデリケートです. 私は、大企業の上級管理職 (彼らがどのようであるかを知っています) から「それを実現する」ように派遣されました。

bin ログ ファイルをさらに別のアプリケーションで解析し、日中にそのデータベースに対して何を行ったかを把握し、それに応じてテーブルを合成する以外に、夜間の更新を処理する方法は考えられません。私のテーブルに何をすべきかを理解するために、私は本当に彼らの table1 を見る必要があるだけです。他のテーブルは、レコードをフラッシュするためのフィールドを提供するだけです。(混乱の重複があるため、MASTER SLAVE を使用しても役に立ちません。)

別の方法は、table1 のすべての行に対して一意のハッシュを作成し、ハッシュ テーブルを作成することです。次に、毎晩データベース全体を調べて、ハッシュが一致するかどうかを確認します。そうでない場合は、そのレコードを読み取ってデータベースに存在するかどうかを確認し、存在する場合はデータベースで更新し、存在しない場合は新しいレコードとして INSERT します。これは醜く、高速ではありませんが、バイナリ ログ ファイルの解析もきれいではありません。

問題を明確にするためにこれを書きました。多くの場合、他の人にそれを話すと、問題が明確になり、解決策がより明白になります。この場合、私はより大きな頭痛を抱えています！

あなたの考えは大歓迎です。

Rails Migrations のような簡単にインストール/使用できる (UNIX 上での) データベース移行ツールはありますか? このアイデアはとても気に入っていますが、データベースの移行を管理するためだけに ruby​​/rails をインストールするのはやり過ぎに思えます。

キーに基づいて dict をソートし、クラスのオーバーライドされた iter メソッド内からイテレータを値に返そうとしています。新しいリストを作成し、キーを並べ替えるときにリストに挿入するよりも、これを行うためのより適切で効率的な方法はありますか?

データ モデルを反映しなくなった従来のデータベース スキーマにとらわれていることは、すべての開発者にとって悪夢です。しかし、保守性のためにコードをリファクタリングするという話が飛び交っていますが、古いデータベース スキーマをリファクタリングするという話はあまり聞いたことがありません。

古いスキーマに依存するすべてのコードを壊すことなく、より良いスキーマに移行する方法に関するヒントは何ですか? 私は自分の要点を説明するために特定の問題を提案しますが、役立つことが証明されている他のテクニックについても気軽にアドバイスしてください。それらも役立つ可能性があります。

私の例：

私の会社は製品を受け取り、発送します。現在、製品の受領書と製品の出荷には、いくつかの非常に異なるデータが関連付けられているため、元のデータベース設計者は、受領書と出荷用に別のテーブルを作成しました。

このシステムを使って 1 年が経ちましたが、現在のスキーマはあまり意味がないことに気づきました。結局のところ、受け取りも発送も基本的には取引であり、それぞれ商品の金額を変更する必要があり、基本的には +/- 記号だけが異なります。実際、一定期間にわたって製品が変更された合計量を見つける必要があることがよくありますが、この設計では非常に扱いにくい問題です。

明らかに適切な設計は、ID が ReceiptInfo または ShipmentInfo テーブルのいずれかの外部キーである単一の Transactions テーブルを持つことです。残念なことに、間違ったスキーマが既に数年間運用されており、数百のストアド プロシージャと、そこから書き出された数千行のコードが含まれています。では、スキーマを正しく機能するように移行するにはどうすればよいでしょうか?

モンスターを受け継いだ。

これは、.NET 1.1 アプリケーションが Healthcare Claim Payment (ANSI 835) 標準に準拠するテキスト ファイルを処理するように見せかけていますが、怪物です。処理される情報は、医療請求、EOB、および償還に関連しています。これらのファイルは、最初の数桁に識別子を持つレコードと、そのタイプのレコードの仕様に従ってフォーマットされたデータ フィールドで構成されます。一部のレコード ID は、特定のタイプのトランザクションに関連するレコードのグループを区切る制御セグメント ID です。

ファイルを処理するために、私の小さな怪物は最初のレコードを読み取り、これから行われるトランザクションの種類を判断し、現在処理しているトランザクションの種類に基づいて他のレコードの処理を開始します。これを行うには、ネストされた if を使用します。多数のレコード タイプがあるため、いくつかの決定を下す必要があります。各決定には、いくつかの処理と、以前の決定に基づいて行う必要がある 2 ～ 3 のその他の決定が含まれます。つまり、ネストされた if には多くのネストがあります。そこに私の問題があります。

この入れ子になった if の長さは 715 行です。はい、そうです。七百五十行。私はコード分析の専門家ではないので、フリーウェアの分析ツールをいくつかダウンロードし、McCabe の Cyclomatic Complexity 評価で 49 という結果になりました。彼らは、これはかなり高い数値だと言っています。100 が高い基準であるアトランタ地域の花粉数のように高く、ニュースは「今日の花粉数は 1,523 です」と言っています。これは、私が今までに見た中で最高の矢印アンチパターンの例の 1 つです。インデントは最大で 15 タブの深さになります。

私の質問は、そのようなものをリファクタリングまたは再構築するためにどのような方法を提案しますか?

アイデアを探すのにしばらく時間を費やしましたが、良い足がかりが得られませんでした。たとえば、レベルをガード条件に置き換えることも方法の 1 つです。私はそれらのうちの1つだけを持っています。巣が 1 つ落ちて、残りは 14 です。

参考になるデザインパターンがあるかもしれません。コマンド チェーンはこれにアプローチする方法でしょうか? .NET 1.1 のままにしておく必要があることに注意してください。

ありとあらゆるアイデアをありがとう。

最近、プルーニングとクリーンアップが必要な C# コンソール アプリケーションを継承しました。簡単に言うと、このアプリは 110,000 行以上のコードを含む単一のクラスで構成されています。ええ、1 つのクラスで 110,000 行以上。そしてもちろん、アプリは私たちのビジネスの中核であり、動的な Web サイトで使用されるデータを 24 時間更新しています。私の前任者は「本当に優れたプログラマー」だったと言われていますが、OOP (またはバージョン管理) にまったく興味がなかったことは明らかです。

とにかく...コードに慣れているうちに、宣言されているが参照されていないメソッドがたくさん見つかりました。コードのバージョンを変更するためにコピー/貼り付けが使用されたように見えます。プログラマーが getSomethingImportant() に変更を加えるように依頼されたとき、彼はコピー/貼り付けして名前を getSomethingImortant_Date に変更し、getSomethingImortant_Date に変更を加えてから、コード内のすべてのメソッド呼び出しを新しいメソッド名に変更し、古いメソッドをそのままにしていたようです。コードですが、参照されることはありません。

1 つの巨大なクラスをクロールし、すべてのメソッドのリストと各メソッドが参照された回数を返す単純なコンソール アプリを作成したいと考えています。私の推定では、1000 をはるかに超えるメソッドがあるため、手動でこれを行うには時間がかかります。

このコードを調べるために使用できる .NET フレームワーク内のクラスはありますか? または、宣言されているが参照されていないメソッドを特定するのに役立つその他の便利なツールはありますか?

(補足質問: このような非常に大きなクラスの C# アプリを見た人は他にいますか? 多かれ少なかれ 1 つの巨大な手続き型プロセスです。少なくともこのサイズのものは、私が見たのはこれが初めてです。)

控えめに言っても、書き方が不十分な CSS を使用しています。私はデザイン/CSS の専門家ではありませんが、少なくとも CSS のCは理解しています。VS-2008 内の組み込み CSS サポートは以前のバージョンよりも大幅に改善されていますが、それでも私が探しているものは完全には機能しません。

ReSharper で C# を使用できるように、CSS をリファクタリングしてクリーンアップするのに役立つ優れたプログラムまたはユーティリティを誰かが知っているかどうか疑問に思っていました。

あると便利な機能:

• CSS ファイルを調べて、フォント スタイル、色などの一般的なスタイルを抽出する方法を決定します。
• VS-2008 へのプラグインは最高です!
• マークアップ ファイルを調べて、現在のクラスとスタイルの使用を改善するための提案を行います。

タスクを処理するための複雑なワークフロー状態をデータベースに格納する方法に関するベスト プラクティスについて質問があります。私はオンラインで探しても無駄だったので、コミュニティに彼らが何が最善だと思うか尋ねてみようと思いました.

この質問は、前の質問で示したのと同じ「BoxItem」の例から出てきます。この「BoxItem」は、さまざまなタスクが実行されているため、システムで追跡されています。タスクは数日にわたって人的介入を伴う場合があるため、BoxItem の状態を永続化する必要があります。誰がタスクを実行したか (該当する場合)、いつタスクを実行したかも追跡する必要があります。

最初に、実行する必要がある人間と対話するタスクごとに「BoxItems」テーブルに 3 つのフィールドを追加することで、これに取り組みました。

TaskName は完了していますか

日付TaskName完了

ユーザーTaskName完了

これは、ワークフローが単純だったときに機能しました...しかし、現在では複雑なプロセスに成長しています (フロー内で可能な人間の相互作用は 10 を超えています...その約半分はオプションであり、BoxItem に対して実行される場合と実行されない場合があります。その結果、これらのオプションのタスクにも「Do TaskName」フィールドを追加し始めました)、単純なテーブルであるべきだったものが、この状態情報の保持に完全に専念する40ほどのフィールドになっていることがわかりました.

もっといい方法はないかと悩んでいますが…困っています。

最初に考えたのは、特定のボックスで実行できるタスクを定義する一般的な「BoxItemTasks」テーブルを作成することでしたが、それでも日付とユーザーの情報を個別に保存する必要があるため、あまり役に立ちませんでした。

私の 2 番目の考えは、おそらくそれは問題ではないということでした。このテーブルに状態保持専用のフィールドが 40 以上あっても心配する必要はありません。しかし、それは保持する情報が多いように感じます。

とにかく、3番目のオプションが何であるか、または上記の2つのオプションのいずれかが実際に合理的であるかどうかについて、私は途方に暮れています. このワークフローは将来さらに複雑になる可能性があり、新しいタスクごとに、追跡をサポートするためだけに 3 ～ 4 つのフィールドを追加する必要があります。

この状況であなたはどうしますか？

これは、ORM を使用せずに構築された既存のシステムの保守であるため、ORM だけに任せることはできません。

編集：

Kev、あなたはこのようなことについて話しているのですか:

ボックスアイテム

(PK) BoxItemID

(その他関係ないもの)

BoxItemActions

(PK) BoxItemID

(PK) BoxItemTaskID

完成されました

完了日

ユーザー完了

BoxItemTasks

(PK) タスクタイプ

説明（必要であれば）

うーん...それはうまくいくでしょう...それは、どのアイテムがどの状態にあるかを確認するためにSQLクエリを実行する現在のアプローチを変更する必要があることを表していますが、長期的には、このようなものがよりうまく機能するように見えます(シリアライゼーションのアイデアが表すような根本的な設計変更を行うこと...時間があれば、そのようにしたいと思います.)

これはあなたがKinについて言及していたことですか、それとも私はそれを理解していませんか?

編集：ああ、現在の状態を判断するための「最後のアクション」についてもあなたのアイデアが見えます...私はそれが好きです! それは私にとってはうまくいくと思います...少し変更する必要があるかもしれません(ある時点でタスクが同時に発生するため)が、アイデアは良いもののようです!

EDIT FINAL：要約すると、将来、誰かが同じ質問でこれを調べている場合...システムに情報がクエリ可能なインターフェースに事前にロードされている場合（つまり、私が取り組んでいるアドホック システムのように、データベース自体を直接呼び出すわけではありません)。ご回答ありがとうございます。