問題タブ [brownfield]

私は月曜日に新しい仕事を始めます。この会社には、.NET で記述された自社開発のエンタープライズ ケース管理アプリケーションがありASP.NET/VB.NETます。彼らはアジャイル開発プロセスを実装しようとしています。彼らは、2 人のスクラム マスター認定を取得し、アジャイル コーチを雇うまでになりました。現在、6 ～ 9 か月のリファクタリングに集中しています。

私の質問は、この環境を考慮して、コードベースに慣れ、着地したらすぐに生産性を高めるための優れたアプローチ/ツールは何ですか? なにか提案を？

最近、助けが必要な SQL Server 2000 データベースの開発を引き継ぎました。まもなく SQL Server 2005 にアップグレードする予定です。このデータベースには、テーブルに監査フィールド (CreatedBy、CreatedDate など) がなく、外部キーがなく、全体的な設計がひどいものです。インライン SQL を使用してデータベースに直接アクセスするプログラムや、その他の古い/悪い慣行が半ダースあります。

スキーマとデータ アクセスをクリーンアップしたいと思います。開始するのに適した場所について何か提案はありますか? これは運用データベースであり、改善されている間も機能し続ける必要があります。

私は現在の仕事のために新しい小売 e コマース ストアフロントの開発を任されており、RoR を使用して、A) Rails の限られた知識で「実際の」プロジェクトを構築し、B) 経営陣に迅速なターンアラウンドとフィードバックを提供することを検討しています。 (彼らはこれをできるだけ早く終わらせたいと考えており、彼らの締め切りはかなり非現実的です。SEO/SEM を使用してマーケティングを開始できるように、何もない状態から実用的なモデルになるまでに数週間かかると話しているのですが、冗談ではありません。"上司がそれが未来だと聞いたからです）。

データベース構造は整っていますが、それはまったくひどいものであり、韻も理由もなしに一緒に投げ込まれたため、ほとんど無視して、新しいデータベースをゼロから作成します。ただし、アプリケーションにロードする必要がある既存のデータがあります (前述のように、これは e コマース アプリであり、製品データがあります)。このデータを使用可能な形式に変換する必要があるのは、サプライヤが暗号化された省略形の列名を提供し、特にカテゴリで非常に非正規化されているためです (以前に質問を投稿しました - 基本的に、カテゴリ テーブルには 6 つのフィールドがあります)。 、各カテゴリ/サブカテゴリに 1 つずつ、そのカテゴリが適用されない場合は一部が空白になります)。

私に再考を与えている2つの主な問題があります：

1. 私が言ったように、データは「適切な」データベーススキーマに入れる必要があります。そのまま載せるわけにはいきません。そのための適切なデータ モデルについていくつかの考えがありますが、私の分析はまだ完了していません。さまざまなもの (products_categories、products_attributes、products_prices など) をリンクするための大量の結合テーブルが存在することになり、これらのテーブルは ID ではなく SKU によって製品をリンクします (以下を参照)。

2. すべてのものには ID が既に生成されていますが、新しく追加するものには ID を自動生成する必要があります。これが成熟した RDBMS で問題になるとは思えませんが、Rails が ID 自体を生成するのが好きであることは知っています。また、ほとんどすべての製品関連のテーブルは、ID と I ではなく、SKU によってリンクされています (サプライヤから提供されたデータには、実際にはプレフィックスと在庫番号からなる複合キーがあり、これらを組み合わせて完全な SKU を構成しています)。これがパフォーマンスの問題になるかどうかはわかりません (もちろん、これらの列に手動でインデックスを作成して高速化することもできます)。ただし、これは、Rails の規則から脱却する必要があることを意味します。

要するに、市場投入までの時間と開発の容易さに関しては、Rails は良い選択かもしれないと思いますが、アプリケーションを開発する必要があるため、既存のデータ コンテンツを操作しなければならないことは苦痛になる可能性があります。それは「従来の」Rails アプリではなく、Rails の使用について大きな疑問を投げかけています。他にもいくつかの問題があります (Linux サーバーをセットアップする必要があることと、私が住んでいる地域には Rails 開発者がほとんどいないという事実があるため、会社を辞めた場合、基本的に更新/変更に関して彼らを人質に取っていることになります) . 私は進むべき最善の道について本当に確信が持てません。

私は後任のために初めていくつかの就職面接を行っています。彼らがブラウンフィールドプロジェクトにどのようにアプローチするのか知りたいのですが、質問の言い方がよくわかりません。

彼らの態度がどのようなものか知りたいです。たとえば、捨てて書き直す、ツールを使ってリファクタリングする、コードをステップ実行して理解する、どのような本を読んだか (例: 「レガシー コードを効果的に使用する」)。

誰かがブラウンフィールドのソフトウェア開発をどのように行っているかを知るにはどうすればよいでしょうか?

最近、私は「強化」するために仕事でビジネスクリティカルなプロジェクトを継承しました。このコードは、過去5年間にわたって作成され、多くの人に渡されてきました。もはや会社にいないコンサルタントとフルタイムの従業員は、この非常に繊細で非常に機密性の高いアプリケーションを破壊しました。私たちのほとんどは、レガシーコードまたはこのタイプのプロジェクトに対処する必要があります...開発者であることの一部です...しかし...

ゼロユニットとゼロシステムテストがあります。ロジックは、ストアドプロシージャ、ビュー（はい、ビューと言いました）、およびコードの間で混ざり合っています（理由もなく複製されることもあります）。ドキュメンテーション？そうだね。怖いです。はい、最小限の「微調整」またはリファクタリングを行うことは非常に神聖です。1つの小さな事故、そして私の雇用主にとって大きな収入の損失と潜在的な法的問題があるでしょう。

それで、何かアドバイスはありますか？私の最初の考えは、既存のコードに対してアサーション/単体テストを書き始めることです。ただし、ストアドプロシージャには多くのロジックが組み込まれているため、これまでのところしかできません。（ストアドプロシージャをテストすることは可能ですが、ソースコードロジックの単体テストと比較すると、歴史的にはるかに困難です）。別のまたは追加のアプローチは、アプリケーションが関数を実行する前後のデータベースの状態を比較し、コードを変更してから、データベースの状態を比較することです。

この質問を修飾させてください。Model-View-Presenterを使用せず、TDDを使用して作成されていない「従来の」ASP.NETアプリケーション（Webフォーム）に取り組んでいます。また、時代遅れのデータアクセス戦略（ストアドプロシージャを呼び出してオブジェクトにデータを入力して永続化する手書きのDAOレイヤー）を使用しています。これは、私の強い願望にもかかわらず、ORMにアップグレードされる可能性は低いです。

私がアプリケーションの開発を引き継いだので、ほとんどの新機能はTDDを使用して実装されました。それでも、古いコードベース、DALレイヤー、UI全体はテストされていません。アプリケーションがその神秘的な70％のコードカバレッジ目標からどれだけ離れているかを理解する前に、コードカバレッジを決定するときに通常どのような種類のコードが含まれるかを明確にしたいと思います。

ビジネスロジックコードは明確に含まれていますが、WebFormsコードはどうですか？また、データアクセスコードはどうですか？上記のように、データアクセス層はストアドプロシージャを使用してオブジェクトグラフにデータを入力し、それらをDBに永続化します。オブジェクトの永続性と再水和は含まれるべきものですか？

この質問があまりにもオープンエンドである場合は、お詫び申し上げます。このブラウンフィールドアプリケーションをより良い形にする方法について、少し圧倒され、混乱しているように感じます。

ありがとう！

私はNHibernateでこの関係をモデル化する必要があります（トピックにとどまるためにコードを少し単純化しました）-従業員はアカウントマネージャーになることができます（したがって、それはオプションです）：

テーブルEmployee（Id、Number、Name）テーブルEmployeeIsAccountManager（Number、MaxAllowedDiscount）

テーブルEmployeeIsAccountManagerのId外部キーがテーブルEmployeeを指す代わりに、テーブルEmployeeIsAccountManagerのNumber列を指すNumber列がEmployeeテーブルにあります。

これをNHibernateでマッピングするにはどうすればよいですか？EmployeeIsAccountManagerクラスマッピングで外部ジェネレーターを使用しようとしましたが、外部生成値としてNumberを使用すると、NumberではなくIdであるEmployeeのIDにマップされます。構成を使用するようにクラスをモデル化しました。

私はたくさん（1対1、多対1、外国の発電機）を試しましたが、これがNHibernateで実行できるかどうかわかりません。ところで：クラスやマッピングなどを変更することはできますが、ブラウンフィールドステータス（2百万行以上のコード、約1000フォームの古いアプリケーション）のため、テーブル構造を変更できません。

どんな助けでもありがたいです、ありがとう！テッド

作業が難しい古いスキーマを持つ古いテーブルがいくつかあります。

NHibernate を使用して、このデータの一部をより適切なモデルに変換することは可能ですか?

たとえば、いくつかのプロパティに分割したい整数のステータス列があるとします。

次のようなものが必要です。

（Status列挙型はどこにありますか）

protectedステータスを取得できるフィールドを使用し、追加のプロパティのゲッターを定義して、バッキング フィールドに基づいて適切な値を返すことができることはわかっていますが、これにより、これらに基づいてクエリを実行する機能が無効になると確信しています。プロパティ。

ただし、これでは、 などのクエリを実行して.Query(p => p.IsActive)、それを などの SQL に変換することはできませんwhere status = 0よね?

カスタムを介して唯一の方法IUserTypesですか？IUserTypeもしそうなら、これを達成するために簡単に作業できるヘルパーフレームワークはありますか?

他の人はこれをどのように処理しますか？

私は、ブラウンフィールド アプリケーションでユーザー固有のタイム ゾーンを実装するためのソリューションを考え出すことを担当しています。データベースに保存されるすべての日付は、サーバーのローカル時間で保存されます。これらの日付とともに保存されるタイム ゾーンまたはオフセット情報はありません。

これは非常に大規模なアプリケーションであるため、これは大変な作業になると思います。私の懸念は、これを可能な限りリスクを少なくして行うことです。誰もこれを以前にやったことがありますか？もしそうなら、最善のアプローチは何ですか?また、避けるべき落とし穴は何ですか?

現在の考え方は、意味のある時間コンポーネントを持つ日付列のすべてのデータを UTC に変換することです。次に、プレゼンテーション レイヤーで、ユーザーに表示する必要があるときに、datetime オブジェクトを UTC からユーザーのタイム ゾーンに変換する関数を実行する必要があります。

これは、SQL Server 2008 データベースを使用する ASP .NET アプリです。私がこれについて言及するのは、それらのテクノロジーの中に、物事をよりスムーズにするために使用できる、私が知らない便利なツールがあるかもしれないからです.

PreNote：別名手洗い; これはブラウンフィールドプロジェクトで行われている作業です

次のような「ProductLine」テーブルがあります

現在のシステムには、製品テンプレートラインのテーブルがあり、新しいリセラーが作成されるたびに、そのリセラーにリンクされた一連の製品ラインが作成されます。そのリセラーが組織の製品を編集したい場合は、アカウントに基づいて表示されるという考えです。

これらの製品ラインは、販売テーブル（カートテーブルにリンクされている）にリンクされている販売ラインテーブルで使用されます。

さまざまな理由で製品ラインに接続されたテーブルがいくつかあります。

私が見ていたのは、製品ラインの重複排除コピーを作成し、一部のデータを削除して、再販業者が変更を加えた場合にのみ新しいラインが作成されるようにすることでした。したがって、ページが124,000行を超えて69行に減少します（5年間でこの機能を使用した人はいません）。

次に、古いProductLineテーブルを参照として使用し、既存のデータ（販売ラインテーブルのProductLineId ）を変更して、元の行ProductIDを読み取り、新しい一致するLineID（製品ごとに1つ）を見つけて、新しいProductLineIDを指すようにします。。

これを行うための最良の方法は何だろうと思っていました。カーソルが頭に浮かびますが、ピッチフォークを使用してDBAを広範囲から引き出す傾向があります。おそらく、SQLの苦痛が少ないほど、いくつかのテーブルで同様のクエリを実行する必要があります。

視覚化を少し簡単にするために、販売ラインは次のようになります

追加

古いProductLineテーブルの名前をLegacyProductLineに変更する予定です。次に、重複排除して、そこから製品ラインをクリーンなProductLineTableに挿入します。

次に、SalesLine（およびその他）のProductLineIdを新しいProductLineIdに置き換える必要があります。

LegacyProductLineは、ProductLineTableのProductLineIDが何であるかを認識しません。したがって、他に一致するパラメーターがないため、それらを一致させる方法としてProductIDを検討していました。

レガシーテーブルは参照用に一時的なものであり、削除されます。SaleLineテーブルのProductLineIDを変更する必要があります。

現在、SaleLineテーブルには、レガシーテーブルのProductLineIdが含まれています。これらは、ProductLineテーブルのProductLineIdを使用するために更新する必要があります。