テーブルの継続的な作成と削除は、アーキテクチャ上の欠陥の兆候ですか？

最近、私はプログラム開発中に、彼らがアジャイル開発プロセスを使用する場合はこれが正常であると言って、新しい機能と正当化された事に取り組んでいる間、定期的にテーブルとカラムを定期的に作成および削除することを述べた開発者と議論しました。

私のバックグラウンドのほとんどはウォーターフォール開発環境にあるので、これがアジャイル開発で実際に適切であると考えられているのか、またはこれが根本的な問題の兆候であるのか、プログラムアーキテクチャまたはアジャイルプロセスのフォローに関するものなのか疑問に思います。

「アジャイル」は、よく考えられていない、混chaとした、急いでいる、あなたのパンツの同義語になっていることは、毎日ますます明白になっています。そして、私が理解しているように、それらはどれもアジャイル手法と互換性がありません。

効果的で再現性のあるアジャイルプロセスを実現することは容易ではなく、製品の品質向上につながる可能性がありますが、実行する作業の総量が本質的に減少するとは考えていません。

データベースを「リファクタリング」する時間がないと言われた場合、おそらくデータベースのバージョン管理と移行をセットアップする時間もありません。彼らはおそらく、そのための一連の機能テストを作成するのに時間をかけていません。これらのことはすべて、成功へと向かう堅実なアジャイルプロセスを考えるとき、私が考えるものです。

最終的に、アジャイルは単なる言葉です。あなたが日々何をしているのかは、あなたが成功するかどうかを決定します。

設計の進化に合わせてテーブルを作成および削除することは珍しいことではありませんが、データベースがこれらすべてのテーブルを実際に使用していることを確認するために、クリーンアップが行われる場合があります。

はい、アジャイルはリファクタリングがすべてですが、システムがリファクタリングするには大きすぎると言っている場合、アジャイルの実行を停止し、現在はカウボーイプログラミングに過ぎません。開発チームはそう呼ばれることを嫌いますが、それが彼らがしていることです。動くものを射撃する範囲に乗ってください。

DBAが役立ちます。開発とアジャイル開発を理解しているDBAを取得してください。開発チームは、投獄されるのではなく、拘束される必要があります。

一般に、プログラミングとデータベース管理が厳密に分離されていないプロセスでは、多くの場合、新しいテーブルの作成と新しい列の追加は非常に正常です。新しい機能は、どこかに行く必要がある新しいデータを作成する場合があります。それを避けるために厳しすぎると、内部プラットフォームモデルになってしまいます。

よく書かれたソフトウェアは、これらの新しいデータベースオブジェクトにほとんど気付かないので、テーブルの新しい列が原因で壊れることはありません。

一方、列やテーブルを定期的に削除することは疑わしいです。新しい機能ではテーブルを削除する必要がないため、これは完全にプランレスで作業している人のサインです。

データベースのバージョン管理と移行を簡単に行うことができ、変更を加えても問題が解決しないことを証明するテストを実施できれば、おそらく非常に機敏なプロセスを実行できます。

コメントに照らして-一般的にこれらの効果に対して、自分自身をアジャイルと正当化するカウボーイの束があります-悲鳴を上げます。速い。そして、あなたができるすべてをthedailywtf.comに投稿して、私たち全員があなたの恐怖を楽しむことができるようにします。

StackExchangeでのほとんどの回答と同様に、応答は「依存」する必要があります。アジャイル開発では、実装中に要件と仕様が発見されます。

しかし、めったに必要ないはずな関係に新しい属性を追加し、リレーショナルモデルが適切に正規化されたときに、アジャイル開発を与え、新しいエンティティは、一般的に、古いものを参照する必要があります与えられた適切なモデル。

ほとんどの開発者は、時間の制約、怠laz、無能またはクエリの複雑さのために、DBを正規化しません。再正規化には、既存のデータの転送、DAOの変更などが必要であり、リスク要因が発生します。

あなたの質問に答えるために、いや、それはアジャイルプロセスでは普通ではありません。

アジャイルの態度に起因すると思われる場合は、アジャイルの短期反復設計/開発/テストサイクル、および既知の要件を満たすが、新しい要件を満たすことができるように適切に構成された軽量ソリューションにアジャイルが重点を置くことによる最小限の変更。これら2つのことを考えると、開発者は、何が起こるかを知らず、彼の変更を元に戻すことのできない方法でDBに影響を与えるべきではなく、単にスキーマに必要な変更を加えると言うかもしれません可能な限り「最も軽い」方法であり、その後、いくつかの「軽い」変更のセットが、より永続的で安定したものにリファクタリングされます。

そうは言っても、アジャイルの理論と方法論を購読している開発者とはまだ仕事をしておらず、何らかの理由でスキーマ内のテーブルを定期的に作成および削除する必要があると考えました。アジャイルは、平手打ちやボルトオンを意味するものではありません。特定のレコードに属するデータの新しいフィールドを追加する必要があるストーリーが与えられた場合、テーブルにフィールドを追加します。その変更が何かを壊す場合、あなたは理由を理解し、必要に応じて他の変更を行います（クエリされるDBに列を追加することで、壊されることはほとんどありません;この種の変更で壊れる場合より大きな問題がある）。通常、リファクタリングはコードに制限されています。スキーマの変更は通常、コードの変更よりも複雑なプロセスです。したがって、スキーマの変更が必要な場合、通常は慎重に行われます。プロジェクトの将来の方向性に関する知識に少なくともある程度の注意が払われました。データベースの一部またはすべてを再構築する必要があることは、設計の根本的な失敗を示しています。アジャイルであることは、プログラムとデータ構造を有機的に構築するときに従うべき基本的なアーキテクチャと設計ルールの「マスタープラン」がないことを意味しません。

今、アジャイルには、あなたが今「知っている」ことと後で学ぶこととが矛盾する場合があります。システムにすべての人のアドレスが必要であるという要件があるとします。これは1対1の関係であり、ほとんどの場合データが必要になるため、PersonテーブルにAddressフィールドを追加するだけです。1週間後、個人が複数の住所を持つことができるという要件を受け取ります。これで1：Nの関係になり、適切にモデル化するには、以前の変更を元に戻して、フィールドを新しいAddressテーブルに分割する必要があります。これは、特に上級開発者の間では日常的ではありません。経験豊富な開発者は、PersonにAddressがあることを確認し、これらを概念的に分離し、PersonテーブルとAddressテーブルを作成し、PersonをAddressIDへのFK参照でリンクします。このようなスキーマは、関係の性質が変化した場合に変更が容易です。「ワイド」データテーブル全体を作成または削除することなく、PersonとAddressの関係を1：1から1：NからN：Nに簡単に変更できます。

アジャイル環境で作業する場合、前もって設計に重点を置くことはないため、最初のリリースでは、これが大きな問題であるとは思わない。

私が見たことのない700のテーブルがあるシステムについてコメントするのは難しいですが、それらすべてを必要とするかもしれませんが、データベースが十分に管理されていない場合もあります。

アジャイルであっても、大規模なシステムでは、スキーマを担当する誰か/チームがまだいることは非常に一般的です。

そうした変更を頻繁に行っている場合、特にライブアプリケーションでテーブルと列を削除している場合は、経験不足の兆候のように見えます。彼らが従うと主張しているプロセスとは何の関係もありません。「アジャイル」は、コードを打ち始める前に、座って保存する必要のあるデータとそれがどのように関連するかを考えない言い訳ではありません。彼らが初期構造の10-20％以上を変更していることに気付いた場合、私にとっては、物事を熟考していないか、要件を分析してデータベースを設計した経験があまりないという指標であり、単に彼らもそれの多くは最初は間違っています。

あなたのチームは確かに単なるカウボーイコーディングであるように思えますが、コードまたはデータベースのリファクタリングに問題はないはずです。仕事を失うわけではありません。新しく学んだ現実に適応しています。

チームが必要とするのは、変更を試し、テストを行い、ユーザーにバウンスして、意味があるかどうかを判断するためのサンドボックスです。その時点で、意味のある変更を（適切な回帰テストを使用して）スキーマに統合することで問題はありません。

アジャイルはコーディングに関するものであり、データベースはコードではありません。データベースの変更は、家の改造のように扱う必要があります。人々はどういうわけか、アジャイルは行為が後で計画を立てることを意味するという信念を得ましたが、これは全く真実ではありません。アジャイル手法の下でも、特にデータベース設計と同じくらい重要なことを計画するために、時間が必要です。

私の最後の仕事はこのようなチームでした。アジャイルプロセスを使用する場合、要件の変更。変更によって、既存のエンティティに新しい属性が必要になり、既存のテーブルの新しい列が必要になったり、まったく新しいエンティティが必要になり、既存のテーブルとの関係を持つ新しいテーブルが必要になることがあります。これらの種類の変更はテリトリーに付属しており、スキーマに触れたくないという理由だけで無視することはできません。成功は、あるデータベースバージョンから次の適切なユニットテストに移行する際にデータの整合性を維持することで判断されます。

スキーマに不要な変更を加えないようにしてください。たとえば、機能で新しいテーブルを作成する必要がある場合は、チェックインしてテスト環境に展開する前に、そのテーブルの定義に満足していることを確認してください。データの移行後にデータベーススキーマへの変更を取り消さなければならないのは、痛い場合があります。