アジャイル開発では、データベースの前にフラットファイルで永続性を試す必要がありますか？
アジャイル開発では、ポリシーとアプリケーションロジックは永続性メソッドなどの詳細よりも重要であるため、永続性の決定は最後に行う必要があると誰かが私に説明しました。したがって、このメソッドの弱点が明らかになるポイントに到達するまで、フラットファイルなどのより単純な永続性から始めて、永続性を変更することをお勧めします。リレーショナルデータベースを使用する。
これは本当ですか、それともコンセプトを誤解しましたか？これは通常、アジャイルチームがアプリケーションを構築する方法ですか？それの根拠は何ですか、そして私がこのアプローチを取るべきではないときは？
伝えられているコンセプトは、アジャイルで関連性のあるものの一部であり、物事を最後の責任ある瞬間に押し上げるアイデアです。
ただし実際に取られた例は、最初は完全に誤った仮定に依存しています。
rDBMSを使用するよりもフラットファイルデータベースを実装する方が簡単/少ない作業です。 -しばしば完全に偽
例は次のとおりです。永続性レイヤーは、不適切であると判断されるまで、可能な限り単純な実装に維持されます。
多くの開発チームにとって、これを実行するためにデータベースを立ち上げるのは1、2時間（ORMを使用した小さなデータベースの場合は15分）程度ですが、彼らがいじり続ける必要のないフラットファイルデータベースは、データベースがUIでテーブルを作成し、いくつかの列を追加し、ORMですべてを生成するようなシンプルな場合、シークとデータテーブル構築タイプのコードをすべて手動で手書きする必要があるため、多大な苦痛と煩わしさそれ以外は必要です。
さらに、永続層が最初からわからない場合は、チームがよく知っている一般的なRDBMSから始めるのがさらに適切であり、後でフラットファイルからRDBMSに変更を加えると、後で変更するよりもはるかに大きくなります。あるRDBMSから別のRDBMSへの変更。ほとんどの一般的なRDBMSを他のRDBMSに変換するための多くのツール、およびヒントなどがあります。フラットファイルから特定のRDBMSに変換するためのツールはごくわずかですが、フラットファイルには独自のライブラリを除いてツールが以前に作成されていない独自の形式があります。
要約すると、概念は正確で正確ですが、例は非常に大きく、（ほとんどの場合）不正確であることが多いに基づいています。
DBを使用することがわかっているので、フラットファイルを処理するコードを書く意味はあまりありません。いくつかの読み取り専用CSVを使用して数回の繰り返しを経験するかもしれませんが、捨ててしまうことがわかっているコードを書いていることにすぐに気づくでしょう。
SQLite （ファイルに格納されているサーバーレスSQLデータベースを提供するライブラリ）のようなものを使用して、初期の複雑さを簡略化するためにできる1つのこと。それは柔軟な型システムを持っているので、スキーマに真剣にコミットする必要はありません。DBに構成/接続してDBを再構築するサーバーは、ファイルを削除するのと同じくらい簡単です。また、必要に応じて、バージョン管理にコードと共にDBイメージを含めることもできます。
これは例であり、概念自体ではなく、概念を示すために使用されます。
コンセプトは、 最後の責任のある瞬間 まではアーキテクチャ上の決定を行わないことですが、それ以降は行いません。しかし、実際には、非常に早い段階で使用するデータベースを決定することがよくあります。それは完璧ではないかもしれませんが、それは事実です。
その決定がなされた後は、それを積極的に回避することはありません。多くの場合、既存のデータベースに何かを保存するのは、フラットファイルに保存するのと同じくらい簡単です。
ただし、LinuxのMySqlからWindowsのSQL Serverへの変更は、フラットファイルからWindowsのSQL Serverへの変更ほど簡単ではない場合があります。それが本当のポイントです。したがって、最終的な解決策については疑問がありますが、変更を考慮して、最も単純なオプションを選択してください。決定が下されたら、それに固執します。
何しつこいですか？
私はアジャイルチームに所属しており、1つのアプリケーションで、ほぼすべてをデータベースに保持しています。気を付けてください。そうしなければ、このアプリケーションでできることは多くありません。データベースに永続化することは、そのraison d'êtreの大部分です。
だから：あなたは何を持続していて、あなたのアプリケーションは何をしていますか？アプリケーションが実際にデータを永続化しないcareでない場合は、フラットファイルかどうかの決定（その決定はどこかに構成ファイルに保存できます）を行う小さなレイヤーを作成できます。データベース。アプリケーションとデータを評価し、特定のケースでデータベースの永続性に時間を費やすのが理にかなっているのか、それとも単にフラットファイルを読み書きするのかを決定する必要があると思います（=おそらくより高速です）開発時間の）。
多くの人々は、アジャイルのその側面を、将来の機能について事前に計画してはならないという意味であると誤解しています。真実と違うことがあってはならない。しないことは、将来の機能の計画を立てて、顧客への価値の提供を今すぐに遅らせることです。
それが永続化のようなものにどのように適用されるかは、アプリケーションに大きく依存します。私の現在の趣味のプロジェクトの1つは電卓です。最終的に、ユーザー定義の定数と関数を保存し、プログラムを閉じるときに状態を保存できるようにしたいと考えています。それには粘り強さが必要ですが、どのような形を取るかについても考え始めていません。私のプログラムは永続性がなくても非常に使いやすくなり、今すぐ追加すると、最初のリリースに大幅な遅延が追加されます。完璧になるのを待つ間、機能する電卓は機能がまったくないよりも少ないほうがいいです。
私の別の趣味のプロジェクトは、ビデオと写真の色補正です。このアプリケーションは、進行中の作業を保存できなければ完全に使用できなくなり、そのために必要なコードはプログラム全体に行き渡ります。最初から正しく理解していないと、変更するのが非常に困難になる可能性があるため、永続性の維持にかなりの労力を費やしました。
ほとんどのプロジェクトはその中間に位置しますが、追加の作業がほとんどまたはまったくない場合でも、将来の機能の計画に不満を感じることはありません。データベースは複雑な場合がありますが、その複雑さのほとんどは、十分にテストされた堅固なインターフェースの背後に隠されています。データベースで無料で提供されるすべての機能のため、アプリケーションで行う必要のある作業は、フラットファイルよりもデータベースの方がはるかに少ない場合があります。データベースサーバーの面倒にまだ対処したくない場合は、SQLiteのような「ハイブリッド」オプションがあります。
あなたは間違った価値観に焦点を当てていると思います。アジャイルでは、ビジネス価値が重視されます。一部のエンドユーザーにビジネス価値を提供するために製品を作成します。
永続層を後で作成するか、途中で作成するかは、ビジネス価値を顧客に提供するための戦略です。 「アジャイル」という用語自体が、どちらかを実行する必要があるかどうかを決定しているとは思いません。
データストレージ戦略の延期に関する見解は、ロバートC.マーティン（アジャイルマニフェストの作者の1人）が このプレゼンテーション で提唱しています。
とても良いプレゼンテーションですので、ぜひご覧になってみてください。
しかし、私はそれに同意しません！少なくともある程度。
ユーザーストーリーに永続化する必要があるデータが含まれていて、実際にはどのようなタイプの永続化も実装されていない場合、ユーザーストーリーを「完了」と呼ぶことができるとは思いません。
製品の所有者が今が稼働開始の時期であると判断した場合、それを実行することはできません。また、プロジェクトの後半まで持続性の実装を開始していない場合、持続性レイヤーの実装にかかる時間についての情報もないため、プロジェクトに大きなリスクが残ります。
私が取り組んだアジャイルプロジェクトは、データアクセス戦略を延期していません。しかし、分離されているため、途中で変更することができます。また、データベーススキーマ全体は事前に設計されていません。テーブルと列は、最終的にビジネス価値を提供する保存されたユーザーを実装するために必要なときに作成されます。
新しいプロジェクトに着手するときに、最初にどの質問に答える必要があるかを確認するには、適切な判断と経験が必要です。
最終製品がまだ不明な場合は、ビルド/プロトタイピングがすばやくそれを理解するのに役立ちます。そうすれば、アジャイルな方法で反復することが役立ちます。もちろん、永続化の実装に関係者に伝えたよりも時間がかかることをプロセスの後半で発見するなどのリスクが生じます。
最終製品がよく知られている場合、アプリケーションで永続性がどのように機能するかを理解することは、早期に知ることがより重要になる可能性があります。開発プロセスの後半で、製品仕様に関する問題を見つけるリスクがあります。
フラットファイルは単純ではありません。
彼らはストレージを許可し、それがすべてです。データの構造、アクセスパスなどはすべてあなた次第であり、これを誤る多くの方法があります。
データベースが存在する理由はいくつかあり、それらの1つは、開発者にとって物事をより簡単にすることです。
私の開発のほとんどは、大企業内の大規模システム向けに行われています。設計や開発を進める前に、常に完全でよく考え抜かれたデータモデルを用意しています。データモデルは問題の理解に役立ち、クリーンな実装を可能にします。
忘れられたデータ項目、不一致のデータ構造、その他の悪夢はすべて、事前にデータモデルを作成することで回避できます。
データベースモデルの実際の選択は、データモデルの後まで残すことができます。しかし、ほとんどの「持続性」テクノロジーは密接に結びついたプログラミングであり、デザインスタイルでさえあります。リレーショナルデータベースのコードを記述し、後で曇ったキー値に切り替えることにした場合、コードの半分を完全に書き直す必要があります。
フラットファイルから始めてリレーショナルDBに切り替えると、開発者がお粗末なデータベースの実装に時間を浪費してしまうため、おそらくコードの半分を捨ててしまうことになります。