A decisão mais lamentável de design ou programação que você tomou? [fechadas]

Eu gostaria de ouvir que tipo de decisões de design você tomou e como elas saíram pela culatra. Por causa de uma má decisão de design, acabei tendo que apoiar essa má decisão para sempre (também participei). Isso me fez perceber que um único erro de design pode assombrá-lo para sempre. Quero aprender com as pessoas mais experientes que tipo de erros eles experimentaram e o que eles aprenderam com eles.

Tenho certeza de que isso ajudará muito outros programadores, ajudando-os a não repetir essas decisões.

Obrigado por compartilhar sua experiência.

Ignorando YAGNI , de novo e de novo ...

"Farei isso mais tarde"
"Mais tarde" nunca chega.

C ++, herança múltipla virtual em forma de diamante . Você entendeu a ideia.

A configurabilidade em um aplicativo é boa. Muita configurabilidade é um pesadelo para usar e manter.

Com um dos meus erros, aprendi que a normalização do banco de dados não deve ser seguida cegamente. Você pode e, em algumas situações, DEVE achatar suas mesas.

Acabei gerenciando cargas de tabelas (via modelos) e o desempenho não foi tão bom quanto poderia ser com um pouco de achatamento para tabelas.

Usando um único caractere nos bancos de dados para status, etc. Não adianta nada, a sobrecarga do uso de um char () ou nvarchar2 () mais longo é minúscula em comparação com a rede e a análise incorrida por qualquer chamada SQL, mas os caracteres sempre terminam um pouco ofuscado ou acabando (não para status, mas outras coisas). É muito melhor colocar apenas a versão legível por humanos e também ter no seu modelo Java (no meu caso) uma enumeração com valores correspondentes.

Eu acho que essa é uma forma de otimização desnecessária e cega prematura. Como se usar um único caractere salvasse o mundo hoje em dia. Além de booleanos Y / N em bancos de dados que não suportam booleanos / bits.

Não desenvolvendo uma camada de acesso a dados adequada e tendo sql em todo lugar no meu código, apenas para obter algo "rápido" em funcionamento. Mais tarde, quando o projeto começou a se expandir e os requisitos mudaram, tornou-se um pesadelo. Eu não sabia o que era um DAL na época.

... feliz por ter passado disso, embora ainda veja programadores com mais de 20 anos de "experiência" fazendo isso.

Pensando que eu poderia ser Arquiteto, Desenvolvedor e PM, todos no mesmo projeto.

2 meses dormindo 3 horas por noite me ensinaram que você simplesmente não pode fazê-lo.

Escolhendo o Microsoft Foundation Classes (MFC) para escrever um IDE Java.

Não foi minha decisão (entrei na empresa um pouco mais tarde), mas em algum lugar em que trabalhei levei o i18n um pouco longe demais, incluindo a tradução de todas as mensagens de log.

Resultados:

• Mais doloroso ao adicionar novo log
• Mais custo para tradução
• Logs são mais difíceis de ler depois

Opa

Reinventando a roda

Fazendo muito design . Criando muitos diagramas UML, particularmente diagramas de sequência para cada operação, muitos dos quais acabaram sendo inúteis. No final, verificou-se que uma quantidade significativa de tempo poderia ter economizado pulando o design / diagramas desnecessariamente detalhados e iniciando a codificação diretamente.

Os clientes que acreditam acreditam no que querem e depois fazem muito antes de verificar com eles.

Minha pior decisão de design? Na década de 1980, eu estava trabalhando em um projeto em que tivemos a brilhante idéia de criar um tipo de modelo para nossas telas de entrada de dados que seria interpretado em tempo de execução. Não é uma decisão ruim: facilitou o design das telas de entrada. Basicamente, basta criar um arquivo que se assemelhe à tela de entrada de dados, com alguns códigos especiais para identificar o que era um rótulo versus o que era um campo de entrada e para identificar se os campos de entrada eram alfa ou numéricos. Decidi adicionar mais códigos especiais a esses arquivos para identificar quais validações deveriam ser executadas. Em seguida, adicionei mais códigos para permitir a criação condicional da tela, o campo X incluído apenas quando alguma condição era verdadeira etc. Depois, adicionei mais códigos para fazer um processamento simples das entradas. Etc etc. Eventualmente, transformamos nosso modelo de tela em uma nova linguagem de programação, completa com expressões, estruturas de controle e uma biblioteca de E / S. E para que? Fizemos muito trabalho para reinventar o FORTRAN. Tínhamos uma prateleira cheia de compiladores para idiomas melhor projetados e testados. Se tivéssemos dedicado tanto esforço à criação de produtos onde realmente possuímos alguma experiência, essa empresa ainda estaria no mercado hoje.

A aplicação excessivamente zelosa do YAGNI (que é denominado Design por Enumeração em Armadilhas do Desenvolvimento Orientado a Objetos ) em um ambiente em que qualquer pessoa sensata poderia dizer que os requisitos definitivamente mudariam. E mude repetidamente.

Se você codificou tudo ( exatamente ) exatamente para os requisitos atuais - enquanto reprimia alguém que dissesse "isso não poderia ser mais genérico?" com seu martelo YAGNI - e os requisitos mudam drasticamente (mas de uma maneira que poderia ter sido razoavelmente antecipada), essa pode ser a diferença entre levar duas semanas para se adaptar e levar 20 minutos.

ATUALIZAÇÃO: Para esclarecer, aqui está um exemplo fictício que não está muito longe do que aconteceu. O Stack Overflow foi projetado para oferecer suporte a emblemas, mas suponha que eles só pensassem em quatro emblemas no início. Apenas quatro, um número tão pequeno, então eles codificaram o suporte para exatamente quatro emblemas em toda a lógica do site. No banco de dados, nas informações do usuário, em todo o código de exibição. Porque "Você não vai precisar" de nenhum crachá que você não consegue pensar, certo? Suponha que o site seja publicado e as pessoas comecem a sugerir novos crachás. Cada cracháleva até duas semanas para adicionar, porque há muito código para ajustar em todo o lugar. Ainda assim, "Você não precisará" de mais crachás do que a lista de hoje, portanto, nunca há refatoração para oferecer suporte a uma coleção genérica de crachás. Uma coleção tão genérica levaria mais tempo com antecedência? Não muito, se houver.

O YAGNI é um princípio valioso, mas não deve ser (ab) usado para desculpar design inadequado e codificação incorreta. Existe um equilíbrio e, com a experiência, acredito que estou me aproximando.

Recursos humanos incompetentes

Tentando fazer algo certo e ótimo com pessoas erradas!
Mesmo se eles estiverem no papel de um gerente de ego supérfluo (o que é bastante comum, especialmente em grandes empresas onde sua incompetência pode durar mais tempo).

Toda vez que eu crio dívidas técnicas, escrevo código processual, pulo testes de escrita etc. porque estou correndo. Quase inevitavelmente, acho que isso cria dor para mim no caminho.

Usando o SQL Server Intergration Services (SSIS).

Eu não desejo isso no meu pior inimigo.

Após criar vários pacotes SSIS nos últimos dois meses, apenas para descobrir que os pacotes que desenvolvi não são distribuíveis e não podem ser implementados. Especificamente em um ambiente licenciado não Web e não SQL Server.

É uma situação muito ruim, quando você tem menos de 48 horas para reescrever seus pacotes SSIS no código POCO .NET puro ou perde o prazo previsto.

Surpreende-me que eu pude reescrever três pacotes SSIS (que levaram dois meses para testar e desenvolver), dentro de 12 horas em código .NET puro, com adaptadores OLEDB e adaptadores SQL.

O SSIS não é distribuível e não executará pacotes de uma máquina cliente se não tiver uma licença do SQL Server instalada (especificamente o DTSPipeline.dll). Seria ótimo saber de antemão. Agora vejo o aviso (em letras miúdas) no MSDN. Isso não é bom quando você tem um exemplo de código em toda a Internet usando apenas o código SQL-LICENSED da máquina. Basicamente, você precisa criar um serviço da Web que conversará com seu servidor SQL para executar seus pacotes SSIS programaticamente. Você não pode executá-los a partir do código .NET puro, a menos que tenha uma licença SQL instalada na máquina em execução. Quão irreal é isso? A Microsoft realmente espera que o SSIS seja usado em máquinas que exigem instalação do servidor SQL? Que desperdício completo de dois meses.

Minha empresa nunca mais utilizará o SSIS por causa dessa pequena impressão "pegadinha".

Não definindo o mecanismo / modelo de implantação o mais cedo possível.

Jogando alguns ovos de páscoa 'engraçados' em algum código que escrevi antes de sair de férias por 2 semanas. Eu pensei que seria a única pessoa a lê-lo quando voltasse, isso me deixaria rindo e pronta para recodificá-lo.

Escusado será dizer que meu chefe não ficou impressionado quando o revisou enquanto eu estava fora, e ficou ainda menos impressionado quando um dos 'ovos de páscoa' estava envolvendo seu rosto, engraçado, caricaturado em ASCII.

Mmmmmm ...

O uso de Temas ASP.Net quando apenas uma pasta CSS normal seria muito bem.

Pegar o caminho rápido para que algum código funcione, em vez do caminho certo (um pouco geral, mas chamaremos de abstração e, portanto, de resposta 'certa').

Minha empresa possui um modelo de desenvolvimento em cascata, no qual nossos usuários e analistas de negócios definirão requisitos para projetos. Em um dos nossos "grandes" projetos, recebemos uma pilha de requisitos e notei que vários requisitos continham detalhes de implementação , especificamente informações relacionadas ao esquema do banco de dados usado pelo nosso sistema de contabilidade.

Comentei para os usuários de negócios que a implementação é o meu domínio, que não deve estar contido nos requisitos. Eles não estavam dispostos a mudar seus requisitos porque, afinal, são o NEGÓCIO, e só faz sentido para os contadores projetar software de contabilidade. Como um desenvolvedor humilde que está muito longe na pesquisa de totens, sou pago para fazer em vez de pensar . Por mais que eu lutei, não consegui convencê-los a reescrever os requisitos - há muita papelada e burocracia em torno das mudanças que são muito complicadas.

Então, eu dei a eles o que eles pediram. No mínimo, meio que funciona , mas o banco de dados é estranhamente projetado:

• Muita normalização desnecessária. Um único registro contendo 5 ou 10 campos é dividido em 3 ou 4 tabelas. Eu posso lidar com isso, mas eu pessoalmente gostaria de ter todos os campos 1: 1 reunidos em uma única tabela.

• Muita desnormalização inadequada. Temos uma tabela que armazena dados da fatura que armazena mais que dados da fatura. Armazenamos vários sinalizadores diversos na tabela InvoiceData, mesmo que o sinalizador não esteja logicamente relacionado à tabela InvoiceData, de modo que cada sinalizador tenha um valor de Chave Primária codificado e mágico e todos os outros campos anulados na tabela InvoiceData. Como a bandeira é representada como um registro na tabela, sugeri puxar a bandeira para sua própria tabela.

• Muito mais desnormalização inadequada. Certos sinalizadores de todo o aplicativo são armazenados como colunas em tabelas inadequadas, de forma que a alteração do sinalizador de um aplicativo exija a atualização de todos os registros da tabela.

• As chaves primárias contêm metadados, de modo que, se uma chave primária varchar terminar com "D", calculamos faturas usando um conjunto de valores, caso contrário, calculamos com outro conjunto. Seria mais útil extrair esses metadados para uma coluna separada ou extrair o conjunto de valores para calcular em outra tabela.

• As chaves estrangeiras costumam ir para mais de uma tabela, de modo que uma chave estrangeira que termina com "M" pode ser vinculada à nossa tabela de contas hipotecárias, enquanto uma chave estrangeira que termina com "A" pode ser vinculada à nossa tabela de contas automáticas. Seria mais fácil dividir os dados em duas tabelas, MortageData e AutoInsuranceData.

Todas as minhas sugestões foram abatidas com muito choro e ranger de dentes. O aplicativo funciona como projetado e, embora seja uma grande bola de barro, todos os hacks desagradáveis, casos especiais e regras de negócios estranhas são sarcasticamente e humoristicamente documentados no código-fonte.

Aderindo à tecnologia mais antiga, porque parece muito aborrecido permitir que seus clientes atualizem para uma nova versão do .NET framework, mas na verdade levará mais tempo de desenvolvimento para criar o software, porque você não pode utilizar alguns componentes (que economizam tempo) do versão mais recente do framework.

De volta à universidade, eu estava trabalhando no meu projeto de design sênior. Outro cara e eu estávamos escrevendo um sistema de rastreamento de bugs baseado na Web. (Nada de inovador, mas nós dois queríamos ter alguma experiência na Web.) Fizemos a coisa com servlets Java, e funcionou razoavelmente bem, mas por algum motivo bobo, em vez de optar por usar Exceptions como nosso mecanismo de tratamento de erros, escolhemos para usar códigos de erro.

Quando apresentamos nosso projeto para uma série e um dos professores perguntou ao inevitável: "Se você tivesse que fazer de novo, o que faria de diferente?" Eu soube instantaneamente a resposta: "Eu usaria exceções, é para isso que elas existem".

Não é minha escolha de método, mas criei um XSLT para converter um arquivo XML baseado em linha em um relatório HTML baseado em coluna.

Só funcionou no IE, era completamente impossível decodificar como funcionava. Toda vez que precisávamos expandi-lo, era impossivelmente difícil e levava idades.

No final, substituí por um pequeno script C # que fazia a mesma coisa.

tentando usar todas as novas tecnologias (para aprender novas tecnologias), mesmo que isso não exija ..

Não levei tempo suficiente para avaliar o modelo de negócios. Fiz o que o cliente pediu, mas 6 a 12 meses depois, chegamos à conclusão de que deveria ter sido diferente.

Projetando sem uma especificação.

Eu implementei uma subseção de um aplicativo de acordo com os requisitos.

Acontece que os requisitos foram inchados e banhados a ouro, e meu código foi superprojetado. Eu deveria ter projetado minha subseção para trabalhar apenas com o que estava adicionando no momento, mas planejo adicionar todas as outras coisas sem incluir o suporte genérico desde o início.