O momento em que uma aplicação de negócio começa realmente a revelar a sua solidez
É fácil avaliar uma aplicação de gestão no primeiro dia: os ecrãs estão lá, os dados de demonstração preenchem as tabelas, tudo parece em ordem. A avaliação que realmente conta surge mais tarde, no dia em que a sua atividade já tiver mudado. Uma nova prestação a faturar, um estado que agora exige distinção, uma informação que antes anotava à mão num canto do caderno e que agora merece a sua própria coluna.
É nesse momento que a maioria das ferramentas revela a sua verdadeira natureza. Algumas recusam educadamente: o campo não existe, terá de prescindir dele. Outras aceitam tudo e deixam-no descobrir mais tarde que dados foram sobrescritos em silêncio. Entre estes dois extremos há uma terceira postura: dizer com precisão o que pode ser alterado sem risco e recusar claramente o resto.
Três tipos de alteração, apenas um é isento de consequências
Nem todas as alterações têm o mesmo peso, e são os dados já inseridos que fazem a diferença. O Blueprint Maker classifica cada alteração solicitada em três categorias, antes de tomar qualquer decisão:
- Sem efeito: adicionar um indicador ao painel de controlo, alterar um rótulo, adicionar um campo opcional ou aligeirar uma restrição. Nada do que já foi introduzido é afetado.
- Necessita migração: renomear uma coluna, adicionar um campo obrigatório ou alterar o tipo de um dado. A estrutura muda, mas a informação existente poderia ser preservada.
- Destrutiva: eliminar um campo ou uma entidade, remover um valor de estado ainda em uso ou efetuar um renomeamento ambíguo. Aqui, dados podem desaparecer.
O que pode ser alterado hoje sem afetar os seus dados
A primeira categoria é sempre aceite. Um indicador extra no painel de controlo, um rótulo mais adequado, uma vista reorganizada ou um campo opcional adicionado: a regeneração ocorre e tudo o que já introduziu permanece intacto. Já isto cobre a maior parte das pequenas adaptações que uma estrutura reduzida solicita nos primeiros meses, pois a maioria dos ajustes incide sobre a apresentação e a leitura, não sobre a estrutura dos dados.
Também pode fazer muito trabalho ANTES de a aplicação sequer existir, e este é o fator com maior retorno: o plano gerado a partir da sua descrição é editável antes da construção. Corrigir uma entidade, especificar melhor um valor de estado ou adicionar um campo nessa fase não tem qualquer custo, pois ainda não há dados a preservar.
O que é recusado, e porquê isso é uma boa notícia
Assim que uma única alteração solicitada se enquadre na categoria «necessita migração» ou «destrutiva», a reconstrução é recusada. Essa recusa é calculada no lado do servidor no momento em que a aplica, com base na diferença real entre as duas versões: não é um aviso de interface que possa ignorar, é um bloqueio efetivo.
A recusa não significa que os seus dados seriam necessariamente perdidos. No caso de «necessita migração», eles seriam muitas vezes preserváveis. Significa algo mais honesto: ainda não existe uma ferramenta capaz de os migrar de forma limpa, com um teste em cópia e uma verificação posterior. Enquanto ela não existir, a única posição sustentável é não fingir que o problema não existe.
É o mesmo princípio que rege todo o produto: um valor apresentado não deve poder mentir. Uma ferramenta que aceita tudo e resolve as coisas em silêncio deixa-o descobrir o problema no dia em que procura uma informação que já não está lá. Uma recusa explícita, pelo contrário, é resolvida imediatamente.
As suas alternativas quando a reconstrução é bloqueada
A primeira, e mais simples: partir da sua descrição atualizada e gerar uma nova aplicação. Não está a começar do zero, está a partir do que aprendeu com a utilização da primeira. Esta é frequentemente a resposta certa quando a estrutura muda de forma significativa, porque o que muda então não é um pormenor: é a forma como vê a sua própria atividade.
A segunda, que torna as outras duas possíveis: o código é seu. Exporte-o como arquivo, envie-o para o seu repositório, aloje-o onde preferir. Um programador pode, assim, assumir a aplicação tal como está, adicionar uma coluna, escrever a migração da base de dados adequada e voltar a colocá-la online. Não precisa da autorização de ninguém nem paga um serviço para obter o direito de modificar a sua própria ferramenta.
A terceira é a menos espetacular e a mais frequente: conviver com a situação. Muitas necessidades que, à primeira vista, parecem estruturais resolvem-se com um campo opcional ou uma vista adicional, ambos passam sem dificuldade.
A pergunta a fazer antes de escolher uma ferramenta de gestão
Não é «posso personalizá-la?». Todos respondem «sim». É: «quando pedir uma alteração que a ferramenta não saiba executar, o que acontecerá exatamente?»
Há três respostas possíveis, e elas não têm o mesmo valor. Dizem-lhe «não» e o assunto fica encerrado. Aceitam-na e só descobre os estragos mais tarde. Ou dizem-lhe exatamente o que está a bloquear, deixam os seus dados intactos e entregam-lhe o código para o fazer pessoalmente, caso a necessidade o justifique. Apenas esta terceira opção não depende da boa vontade do seu fornecedor daqui a dois anos.