É melhor usar más práticas pré-existentes ou boas que não se encaixam bem no código antigo?

Eu estava pensando nisso porque estava tentando escrever uma extensão para um software de terceiros existente, e seu banco de dados é horrivelmente desnormalizado. Eu precisava usar as tabelas existentes e adicionar vários novos campos.

Eu tinha a opção de criar novas tabelas em seu estilo de design (que consiste em quase todas as propriedades em uma grande tabela) ou criar um novo conjunto de tabelas no total e usar algo extra, como Triggers, para sincronizar dados entre os novos e os novos. mesas antigas.

Acabei optando pela primeira opção de usar o estilo de design ruim existente, mas fiquei com a seguinte pergunta: É melhor usar más práticas pré-existentes ou implementar boas práticas que não sejam compatíveis com o código existente? Há algumas situações em que devo escolher uma sobre a outra?

NOTA: Até agora, muitas respostas têm a ver com refatoração lenta do código incorreto, no entanto, não consigo fazer isso. O código não é nosso e é frequentemente atualizado pelo fornecedor. Eu só posso construir sobre isso.

Você deve escolher um design melhor se:

1. Você assumirá grande parte da codificação futura

2. Um design melhor não é mais caro para o cliente a longo prazo. Por exemplo, testemunhei "refatorações" de vários meses para projetos que foram descontinuados até o final do ano.

Você deve escolher "o mesmo estilo ruim" se:

1. Você está apenas ajudando. Não é realista pensar que você pode pegar um grupo existente e levá-lo a padrões mais altos de design, se você for apenas um meio-período no projeto. Um design melhor é subjetivo e quase sempre tem uma curva de aprendizado. Se esse novo design não for aprendido pelo resto da equipe, o projeto terminará com uma mistura de estilos, e seu código melhor projetado poderá acabar na pilha de coisas que ninguém muda porque eles não conseguem entender isto. No seu exemplo acima, o que acontece se houver atualizações para o software de terceiros?

2. Sacrificar um design "melhor" proporcionará uma vantagem comercial tangível. Como adicionar mal o recurso X, você receberá um contrato grande, mas perder o prazo fará com que você acabe com nada. É aqui que entra o conflito histórico entre a gerência e a equipe técnica. Como reformar uma casa, alguém precisa decidir quando pagar. Você pode pagar a dívida inicialmente vivendo sem eletricidade ou encanamento por um ano. Ou você pode pagar 3x mais com o benefício de ter esses utilitários.

A longo prazo, é melhor usar boas práticas. Isso economizará tempo e esforço, pois as mudanças levarão menos tempo para serem implementadas.

Se possível, execute pequenas etapas para refatorar as boas práticas (por exemplo: no SQL, isso estaria quebrando tabelas desnoramlized para normalizadas e usando visualizações com os nomes das tabelas antigas).

Você notará que eu disse a longo prazo - o triângulo "qualidade, tempo, dinheiro" se aplica aqui também (ou seja, escolha dois). Se você não tiver tempo, poderá ter que seguir práticas antigas, mas isso significa que você está aumentando o problema e que seu design também precisará ser corrigido.

Se você continuar trabalhando e adicionando código de design incorreto, nunca terminará com uma base de código que utiliza um bom design. Tanto quanto possível, tente usar um bom design e refatorar para um bom design.

Bem, acho que depende muito de cada caso. Se o desempenho e o design permitirem, é melhor usar boas práticas. Mas se, por exemplo, se a tabela for de alto acesso, a criação de um gatilho para sincronização poderá ter um impacto negativo no desempenho.

Agora, seu cliente não verá que você usou um design melhor, ele apenas verá que sua solução tornou o sistema mais lento. Esse tipo de decisão deve ser tomada caso a caso, e você deve usar sua experiência e critérios para decidir.

Eu acho que você provavelmente fez a escolha certa.

Na medida do possível, você deve isolar o código do aplicativo do design de dados ruim.

Você está atualizando as tabelas deles? Caso contrário, crie visualizações SQL para apresentar essas tabelas de maneira conveniente para o seu aplicativo. As visualizações SQL são relativamente fáceis de escrever e muito mais fáceis de testar do que o código do aplicativo.

Se você precisar atualizar as tabelas herdadas, considere escrever procedimentos armazenados para gerenciar as atualizações. Eles são um pouco mais complexos de escrever, mas podem ser testados instantaneamente.

Manter o código antigo sincronizado quando você normaliza um banco de dados com gatilhos é uma boa solução, se for temporário. O objetivo deve ser alterar o código antigo, mas ao lidar com terceiros, isso pode não funcionar. Você terá que ficar por dentro das mudanças de esquema.

A inserção de mais e mais recursos no código incorreto criará problemas contínuos. Soluções alternativas tornam-se a norma. Os usuários ficarão frustrados porque as alterações levarão muito tempo e provavelmente introduzirão outros bugs ou limitações. Quem quer ser o programador para dizer que não podemos fazer isso em vez de não devemos fazer isso?

Algum código pode ser deixado sozinho; nem sempre temos esse luxo.

Você está lidando com dívida técnica aqui. Em suma, a dívida técnica implica juros, que você precisa pagar com o tempo e, em algum momento, precisa reembolsá-la.

O tempo de Develloper custa dinheiro, então a dívida técnica pode ser vista como a dívida real e custa dinheiro real.

Você tem basicamente duas soluções principais e muitas soluções no meio. Você pode decidir que não deseja reembolsar essa dívida agora e continuar pagando juros. Obviamente, isso custará mais a longo prazo, mas permitirá que você obtenha resultados agora. Você também pode optar por reembolsar essa dívida, para não avançar mais enquanto não a reembolsar, mas, no final, estará livre de juros.

Normalmente, você tem prazos para entrega, e a falta de um prazo causa desconfiança do seu cliente e, eventualmente, você o perde. Esse pode ser um motivo válido para anular a dívida técnica: você considera que o que ganha com o cliente vale a despesa extra da dívida tecnocal.

Você sabe que, no final, você precisa adotar a nova metodologia, caso contrário, obterá mais e mais dívidas e acabará falindo (você agora, quando as pessoas decidem começar do zero ou quando o projeto falha mal).

Você precisa planejar como alterar a base de código existente e fazer a transição para novas práticas ao longo do tempo, além de distribuir as alterações diariamente, pouco a pouco. Em algum momento, quando essa refatoração levar a outras perdas, considere qual perda é pior e vá para a melhor.

O custo da não refatoração aumentará com o tempo (esses são os interesses da dívida tecnocal). Portanto, isso se tornará a escolha mais cara.

Certifique-se de que seu chefe entenda o conceito de dívida técnica. Mesmo com precaução, você criará dívida técnica. Em algum momento, dinheiro a ser usado para reembolsá-lo. Quando você cria uma dívida técnica de propósito, precisa ter um motivo válido para isso e vê a dívida como um investimento (assim como a dívida real). Em qualquer outro caso, apenas NÃO DÊ DÍVIDA técnica de propósito.

Você pode estar interessado em metodologias para evoluir o banco de dados e implantar essas evoluções: http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

A propósito, essa é uma tarefa difícil, boa sorte. Vale a pena!

Este é um problema típico de: "Preciso colher os benefícios do meu trabalho agora ou mais tarde?" e acho que nunca haverá uma solução genérica para essa resposta. Somente você conhece todos os fatores (técnicos e humanos) envolvidos em tal decisão.

No entanto, seu problema levanta uma questão interessante:

A refatoração automática de código está fazendo avanços suficientes para que a uniformidade do código seja mais valorizada?

Por fim, um design ruim deve mudar ou morrer. Ou então, não é um design ruim. A verdadeira questão aqui é sobre o custo da refatoração. Parece claro de sua pergunta que você (ou seu empregador) não está disposto a pagar o preço agora e, no estado atual da tecnologia, provavelmente não desejará.

No entanto, a automação da refatoração de código está fazendo alguns avanços. Se os compiladores podem otimizar binários hoje, quem pode dizer que não otimizarão o código amanhã? Em algum momento, alguma ferramenta será lançada, permitindo que desenvolvedores e designers refatem seu código com muita facilidade, para se adaptarem aos requisitos mais recentes. Afinal, lidar com código legado é um dos maiores desafios da atualidade.

Se uma ferramenta desse tipo existir (eu não ficaria surpreso que ela já exista), seria bom levar isso em consideração ao tomar essa decisão.

Boas práticas sempre superam as pobres. Se a sua base de código estiver repleta de códigos da maneira errada, você não deve apenas cultivar suas próprias coisas da mesma maneira, deve escrever o código corretamente e tentar educar todos os outros da maneira correta.