アジャイル開発では、データベースの前にフラットファイルで永続化を試みる必要がありますか？

アジャイル開発では、ポリシーとアプリケーションロジックは永続化メソッドなどの詳細よりも重要であるため、最後に永続化の決定を下す必要があると誰かが説明してくれました。したがって、この方法の弱点が明らかになるまでフラットファイルなどのより単純な永続性から始めてから、リレーショナルデータベースなどを使用して永続性を変更することをお勧めします。

これは本当ですか、それともコンセプトを誤解しましたか？これはアジャイルチームが通常どのようにアプリケーションを構築するのですか？その理由は何ですか？また、このアプローチを採用すべきではないのはいつですか？

伝えられている概念は、間違いなく機敏で関連性のあるものであり、物事を最後の責任ある瞬間に押しやるという考えです。

ただし、実際の例では、最初は完全に誤った仮定に基づいています。

RDBMSを使用するよりもフラットファイルデータベースを実装する方が簡単/少ない作業です。- しばしば完全に偽

例は次のとおりです。永続層は、不適切であると判断されるまで、可能な限り単純な実装に維持されます。

多くの開発チームにとって、これを行うためにデータベースを立ち上げるのは1〜2時間（ORMを使用する小規模なデータベースの場合は15分）ですが、フラットファイルデータベースを調整する必要はありません。データベースがUIでテーブルを作成し、いくつかの列を追加し、ORMですべてを生成するのと同じくらい簡単な場合、すべてのシークおよびデータテーブル構築タイプのコードを手動で手書きする必要があるため、非常に苦痛と迷惑です他に必要です。

さらに、永続化レイヤーがわからない場合は、チームがよく知っている一般的なRDBMSから始めるのがさらに適切な行為であり、後でフラットファイルからRDBMSへの変更を行うのははるかに大きいあるRDBMSから別のRDBMSに変更する。ほとんどの一般的なRDBMSから他の同様のRDBMSに変換するための多くのツールがあります。また、それはよく行き届いたパスなので、ヒントなどがあります。フラットファイルから特定のRDBMSに変換するためのツールはほとんどありません。フラットファイルには、独自のライブラリとは別にツールがこれまでに作成されていない独自の形式があります。

要約すると 、概念は正確かつ正確ですが、この例は非常に大きく、多くの場合（ほぼ常に）不正確な仮定に基づいています。

DBを使用することを知っているので、フラットファイルを処理するコードを書くことはあまり意味がありません。読み取り専用のCSVを使用して何度か繰り返しを行うこともできますが、すぐに捨てることがわかっているコードを書いていることにすぐ気付くでしょう。

SQLite（ファイルに保存されているサーバーレスSQLデータベースを提供するライブラリ）のようなものを使用して、初期の複雑さを単純化するためにできることの1つ。柔軟な型システムを備えているため、スキーマに真剣に取り組む必要はありません。DBを構成/接続および再構築するサーバーは、ファイルを削除するのと同じくらい簡単です。また、必要に応じて、バージョン管理のコードとともにDBイメージを含めることができます。

これは、概念そのものではなく、概念を示すために使用される例です。

コンセプトは、最後の責任ある瞬間までアーキテクチャ上の決定を下さないが、それ以降はしないということです。しかし、実際には、非常に早い段階で使用するデータベースを決定することがよくあります。それは完璧ではないかもしれませんが、それは事実です。

その決定が下されると、あなたは積極的にそれを避けません。既存のデータベースに何かを保存することは、多くの場合、フラットファイルに保存するのと同じくらい簡単です。

しかし、LinuxのMySqlからWindowsのSQL Serverへの変更は、どこからでもフラットファイルからWindowsのSQL Serverに変更するほど簡単ではないかもしれません。それが本当のポイントです。そのため、最終的な解決策については疑問がありますが、可能な限り単純なオプションを採用し、変更を考慮してください。決定が下されたら、それに固執します。

何をしているの？

私はアジャイルチームに所属しており、1つのアプリケーションについて、ほとんどすべてをデータベースに保持しています。気を付けてください。そうしないと、このアプリケーションで実行できることはあまりありません。データベースへの永続化は、その存在理由の大部分です。

だから：あなたは何を持続し、あなたのアプリケーションは何をしますか？アプリケーションがデータの保存場所を実際に気にしていない場合は、フラットファイルとデータベースの決定（その決定はどこかの設定ファイルに保存できます）を行う小さなレイヤーを書くことができます。私はあなたがそれがデータベースの永続性に時間を投資するあなたの特定のケースでは理にかなっている場合は、あなたのアプリケーションとデータを評価して決定する必要があると思うか、単に読み/（フラットファイル書き込みますおそらく開発期間の面でより速いことを）。

多くの人々は、アジャイルの側面を、将来の機能について前もって計画するべきではないという意味であると誤解しています。真実と違うことがあってはならない。していないことは、将来の機能を計画して、今すぐ顧客に価値を提供するのを遅らせることです。

永続性などにどのように適用されるかは、アプリケーションによって大きく異なります。私の現在の趣味のプロジェクトの1つは電卓です。最終的には、ユーザー定義の定数と関数を保存し、プログラムを閉じたときに状態を保存できるようにしたいと思います。それには永続性が必要ですが、私はそれがどのような形をとるかについても考え始めていません。私のプログラムは永続化することなく非常に使いやすくなり、今すぐ追加すると最初のリリースに大幅な遅延が発生します。私はそれが完璧になるのを待っている間に、まったく機能していない機能よりも機能が少ない機能的な計算機を持っています。

私のもう1つの趣味のプロジェクトは、ビデオと写真の色補正です。このアプリケーションは、進行中の作業を保存することなく完全に使用できなくなり、そのために必要なコードはプログラム全体に広まっています。最初から正しく理解していないと、変更するのが非常に難しくなる可能性があるため、事前に永続化にかなりの労力を費やしました。

ほとんどのプロジェクトはその中間に位置しますが、今は余分な労力をほとんど、またはまったく追加しなければ、将来の機能の計画について悪く感じることはありません。データベースは複雑かもしれませんが、その複雑さのほとんどは、しっかりした、十分にテストされたインターフェースの背後に隠れています。データベースが無料で提供するすべての機能により、アプリケーションで実行する必要がある作業は、フラットファイルよりもデータベースの方がはるかに少ない場合があります。データベースサーバーの手間をまだ処理したくない場合は、SQLiteのような「ハイブリッド」オプションがあります。

あなたは間違った価値に焦点を合わせていると思います。アジャイルでは、ビジネス価値に焦点が当てられています。一部のエンドユーザーにビジネスバリューを提供するために製品を作成します。

永続化レイヤーを遅く作成するか、途中で構成する場合は、顧客にビジネス価値を提供するための戦略です。「アジャイル」という用語自体が、どちらを実行すべきかを決定するとは思わない。

データストレージ戦略の延期に関する観点は、このプレゼンテーションでRobert C. Martin（アジャイルマニフェストの著者の1人）によって提唱されています。

これは非常に良いプレゼンテーションです。視聴することをお勧めします。

しかし、私はそれに同意しません！少なくともある程度まで。

ユーザーストーリーに永続化する必要があるデータが含まれており、実際に永続性を実装していない場合、ユーザーストーリーを「完了」と呼ぶことはできないと思います。

製品の所有者が、今が本番の時期であると判断した場合、それを行うことはできません。また、プロジェクトの後半までパーシステンスの実装を開始していない場合、パーシステンスレイヤーの実装にかかる時間に関する情報も得られないため、プロジェクトリスクが大きくなります。

私が取り組んだアジャイルプロジェクトは、データアクセス戦略を延期していません。しかし、それは切り離されており、途中で変更することができます。また、データベーススキーマ全体は事前に設計されていません。テーブルと列は、最終的にビジネス価値を提供する保存されたユーザーを実装するために必要な方法で作成されます。

新しいプロジェクトに着手するときに最初に答える必要がある質問を確認するには、適切な判断と経験が必要です。

最終製品がまだ不明な場合は、すぐにビルド/プロトタイピングすることでそれを把握できます。また、アジャイルな方法で反復することが役立ちます。もちろん、プロセスの後半で、永続化の実装には、利害関係者に伝えた時間よりも時間がかかることを発見するなどのリスクが伴います。

最終製品がよく知られている場合、アプリケーションで永続性がどのように機能するかを理解することは、早い段階で知ることが重要です。リスクは、開発プロセスの後半で製品仕様に関する問題を見つけることです。

フラットファイルは単純ではありません！

ストレージを許可し、それがすべてです。データの構造、アクセスパスなどはすべてあなた次第であり、これを誤解させる方法は数多くあります。

データベースが存在する理由はいくつかありますが、そのうちの1つは開発者にとって物事を簡単にすることです。

私の開発の大部分は、大企業内の大規模システム向けに行われています。設計や開発を進める前に、常に完全で熟考されたデータモデルがあります。データモデルは、問題の理解に役立ち、クリーンな実装を可能にします。

忘れられたデータ項目、データ構造の不一致、その他の悪夢はすべて、データモデルを事前に作成することで回避できます。

データベースモデルの実際の選択は、データモデルの後まで残すことができます。しかし、ほとんどの「永続性」技術は、密接に結びついたプログラミングであり、設計スタイルですらあります。リレーショナルデータベースのコードを作成し、後でクラウドキー値に切り替える場合は、コードの半分を完全に書き直す必要があります。

フラットファイルから始めてリレーショナルDBに切り替えると、開発者が小便の悪いデータベースの実装に時間を浪費するため、おそらくコードの半分を捨ててしまうでしょう。

データベースの前にフラットファイルで永続化を試みる必要がありますか？

はい、試してみてください。特に、これまで試したことがないなら。どんなに結果が変わっても、何かを学びます。