No desenvolvimento ágil, devo tentar a persistência no arquivo simples antes do banco de dados?

Alguém me explicou que, como no desenvolvimento ágil, a política e a lógica do aplicativo devem ser mais importantes do que detalhes como o método de persistência, a decisão de persistência deve ser tomada no final. Portanto, pode ser uma boa idéia começar com persistência mais simples, como arquivos simples, até chegarmos ao ponto em que a fraqueza desse método se torna aparente e somente então alteramos a persistência, por exemplo, usando banco de dados relacional.

Isso é verdade ou eu não entendi o conceito? É assim que a equipe ágil geralmente cria aplicativos? Quais são as razões para isso e quando não devo adotar essa abordagem?

O conceito que está sendo transmitido é definitivamente parte de uma abordagem ágil e relevante, a idéia de levar as coisas ao último momento responsável.

No entanto, o exemplo usado na verdade se baseia em uma suposição completamente falsa para começar:

que é mais fácil / menos trabalhoso implementar um banco de dados de arquivo simples do que usar um RDBMS. - Frequentemente completamente falso

O exemplo deve ser: A camada de persistência é mantida na implementação mais simples possível até que seja tomada uma decisão de que ela é inadequada.

Para muitas equipes de desenvolvimento, obter um banco de dados para fazer isso é uma questão de uma ou duas horas (ou 15 minutos para um banco de dados pequeno com ORM), enquanto um banco de dados de arquivo simples com o qual eles não precisam se meter pode ser uma enorme sofrimento e aborrecimento, porque eles precisam escrever manualmente todo o código de tipo de construção de tabela de busca e de dados manualmente, quando um banco de dados pode ser tão simples quanto criar uma tabela em uma interface do usuário, adicionar algumas colunas e depois fazer com que um ORM gere tudo mais você precisa.

Além disso, se você não conhece sua camada de persistência, é um ato ainda mais apropriado começar com um RDBMS comum que sua equipe conheça bem, pois a alteração posterior de arquivo simples para RDBMS é muito maior que mais tarde mudando de um RDBMS para outro. Existem muitas ferramentas para converter da maioria dos RDBMS comuns para outras, e dicas e dicas porque é um caminho bem percorrido. Existem extremamente poucas ferramentas para converter de um arquivo simples para um RDBMS específico, em que o arquivo simples possui algum formato proprietário para o qual as ferramentas não foram escritas anteriormente, além de suas próprias bibliotecas.

Em resumo: o conceito é correto e preciso, mas o exemplo é baseado em uma suposição terrivelmente grande e frequentemente (quase sempre) imprecisa .

Como você sabe que usará um banco de dados, não faz muito sentido escrever código para manipular arquivos simples. Você pode realizar algumas iterações usando alguns CSVs somente leitura, mas rapidamente se encontrará escrevendo código que sabe que vai jogar fora.

Uma coisa que você pode fazer para simplificar a complexidade inicial usando algo como SQLite (uma biblioteca que fornece um banco de dados SQL sem servidor armazenado em um arquivo). Ele possui um sistema de tipos flexíveis, para que você não precise se comprometer seriamente com um esquema, nenhum servidor para configurar / conectar-se e reconstruir seu banco de dados é tão simples quanto excluir um arquivo. Ele também permite que você simplesmente inclua a imagem do banco de dados junto com o código no controle de versão, se necessário.

É um exemplo, usado para demonstrar um conceito, em vez de um conceito por si só.

O conceito é que você não toma uma decisão arquitetônica até o último momento responsável , mas não depois. Mas, na realidade, muitas vezes você tem uma decisão sobre o banco de dados que usará muito cedo. Isso pode não ser perfeito, mas é um fato.

Depois que a decisão é tomada, você não a evita ativamente. Armazenar algo em um banco de dados existente costuma ser tão fácil quanto armazená-lo em um arquivo simples.

Mas mudar do MySql no Linux para SQL Server no Windows pode não ser tão simples quanto mudar de um arquivo simples em qualquer lugar para o SQL Server no Windows. Esse é o ponto real. Portanto, embora haja dúvidas quanto à solução final, escolha a opção mais simples possível, considerando as mudanças. Depois que uma decisão for tomada, cumpra-a.

O que você está persistindo?

Estou em uma equipe ágil e, para um aplicativo, persistimos quase tudo no banco de dados. Lembre-se, se não o fizéssemos, não haveria muito o que fazer com esta aplicação - persistir no banco de dados é uma grande parte de sua razão de ser .

Então: o que você está persistindo e o que seu aplicativo faz? Se o aplicativo não se importar com a persistência de seus dados, você pode escrever uma pequena camada que toma a decisão (essa decisão pode ser armazenada em um arquivo de configuração em algum lugar) de arquivo simples vs. banco de dados. Acho que você precisa para avaliar a sua aplicação e seus dados e decidir se faz sentido no seu caso específico de investir tempo na persistência de banco de dados, ou apenas ler / escrever arquivos simples (que irá provavelmente ser mais rápido em termos de tempo de desenvolvimento).

Muitas pessoas interpretam mal esse aspecto do ágil como significando que não devem planejar com antecedência recursos futuros. Nada poderia estar mais longe da verdade. O que você não faz é permitir que o planejamento de recursos futuros adie a entrega de valor aos seus clientes agora.

Como isso se aplica a algo como persistência depende muito do seu aplicativo. Um dos meus projetos atuais de hobby é uma calculadora. Eventualmente, eu gostaria de poder armazenar constantes e funções definidas pelo usuário e salvar o estado ao fechar o programa. Isso requer persistência, mas eu nem comecei a pensar sobre que forma isso tomaria. Meu programa será muito utilizável sem persistência, e adicioná-lo agora adicionará um atraso significativo ao meu primeiro lançamento. Prefiro ter uma calculadora funcional com menos recursos do que nenhuma enquanto espero que seja perfeita.

Outro projeto meu de hobby é a correção de cores de vídeo e fotografia. Este aplicativo será completamente inutilizável sem poder salvar meu trabalho em andamento, e o código necessário para isso é generalizado em todo o programa. Se eu não entender direito desde o início, a alteração pode ser proibitivamente difícil, por isso dediquei bastante esforço à persistência.

A maioria dos projetos fica em algum lugar no meio, mas você nunca deve se sentir mal com o planejamento de recursos futuros, se isso adicionar pouco ou nenhum esforço extra agora. Os bancos de dados podem ser complexos, mas a maior parte dessa complexidade está oculta por trás de uma interface sólida e bem testada. O trabalho que você terá que fazer no seu aplicativo pode muito bem ser menor para um banco de dados do que para um arquivo simples, devido a todos os recursos que um banco de dados oferece gratuitamente. Existem opções "híbridas" como o SQLite, se você ainda não quiser lidar com o incômodo de um servidor de banco de dados.

Eu acho que você está colocando o foco nos valores errados. No ágil, o valor do negócio está em foco. Você cria um produto para fornecer valor comercial a alguns usuários finais.

Se você criar a camada de persistência com atraso ou inventar ao longo do caminho, é sua estratégia para agregar valor comercial ao cliente. Não acredito que o próprio termo "ágil" dite se você deve fazer um ou outro.

O ponto de vista sobre o adiamento da estratégia de armazenamento de dados é defendido nesta apresentação por Robert C. Martin (um dos autores do manifesto ágil).

É uma apresentação muito boa, recomendo que você assista.

Mas eu discordo disso! Pelo menos até certo ponto.

Não acredito que você possa chamar uma história do usuário para "Concluído", se a história do usuário envolver dados que devem ser persistentes e você não tiver realmente nenhum tipo de persistência implementado.

Se o proprietário do produto decidir que agora é a hora de entrar no ar, você não poderá fazer isso. E se você não começou a implementar persistência até o final do projeto, também não tem informações sobre quanto tempo levaria para implementar a camada de persistência, deixando-o um grande risco de projeto.

Os projetos ágeis em que trabalhei não adiaram a estratégia de acesso a dados. Mas foi dissociado, permitindo-nos alterá-lo ao longo do caminho. E todo o esquema do banco de dados não foi projetado com antecedência. Tabelas e colunas são criadas ao longo do caminho, conforme necessário, para implementar o usuário armazenado que, no final, gera valor comercial.

É preciso bom senso e experiência para ver quais perguntas precisam ser respondidas primeiro ao iniciar um novo projeto.

Se o produto final ainda for desconhecido, a criação / criação de protótipos rapidamente ajudará você a descobrir isso, e sim, a iteração de maneira ágil ajudará. É claro que isso apresentará riscos, como descobrir no final do processo que a implementação da persistência levará mais tempo do que você comunicou às partes interessadas.

Se o produto final for bem conhecido, será mais importante saber desde o início como a persistência funcionará em seu aplicativo. Existe o risco de encontrar problemas com a especificação do produto posteriormente no processo de desenvolvimento.

Arquivos simples não são simples!

Eles permitem armazenamento e isso é tudo. A estrutura dos dados, caminhos de acesso etc. depende de você e existem várias maneiras de errar.

Existem razões pelas quais os bancos de dados existem e uma delas é tornar as coisas mais simples para os desenvolvedores.

A maior parte do meu desenvolvimento é feita para grandes sistemas dentro de grandes empresas. Sempre temos um modelo de dados completo e bem pensado antes de prosseguir com qualquer projeto ou desenvolvimento adicional. Um modelo de dados ajuda a entender o seu problema e permite uma implementação limpa.

Itens de dados esquecidos, estruturas de dados incompatíveis e outros pesadelos podem ser evitados através da produção de um modelo de dados antecipadamente.

Você pode deixar sua escolha real da tecnologia de banco de dados até depois do modelo de dados. Mas a maioria das tecnologias de "persistência" está intimamente ligada à programação e até aos estilos de design. Se você codificar para um banco de dados relacional e depois decidir mudar para um valor de chave nublado, precisará reescrever completamente metade do seu código.

Se você começar com arquivos simples e alternar para um banco de dados relacional, provavelmente acabará jogando metade do seu código, já que seus desenvolvedores perderão seu tempo implementando um banco de dados irritante.

Você deve tentar persistência em um arquivo simples antes do banco de dados?

Sim, você deveria tentar. Especialmente se você nunca experimentou antes. Não importa como, você aprenderá alguma coisa.