Demonstrar código incorreto para o cliente?

Um cliente me pediu para fazer um redesenho de seu site, um aplicativo ASP.NET Webforms que foi desenvolvido por outro consultor. Parecia um trabalho relativamente simples, mas depois de analisar o código, fica claro que não é o caso.

Este aplicativo não foi escrito corretamente. Em absoluto. É extremamente vulnerável a ataques de injeção de SQL, a lógica de negócios está espalhada por todo o aplicativo, há muita duplicação e código de beco sem saída que não faz nada. Além disso, ele continua lançando exceções que estão sendo sufocadas, portanto o site parece funcionar sem problemas.

Meu trabalho é simplesmente atualizar o HTML e CSS, mas grande parte do HTML está sendo gerada na lógica de negócios e seria um pesadelo para resolver. Minha estimativa sobre o redesenho é maior do que o cliente estava buscando. Eles estão perguntando por que tanto tempo.

Como posso explicar ao meu cliente o quão ruim é esse código? Na sua opinião, o aplicativo está ótimo e o redesenho deve ser rápido. É a minha palavra contra o consultor anterior. Como posso dar exemplos simples e concretos que um cliente não técnico entenderá?

Atualizar

Obrigado por todas as respostas. A demonstração do ataque de injeção SQL faz sentido e eu demonstrarei isso em um ambiente de teste. Essa é apenas uma parte de muitos problemas neste aplicativo. Eu estava procurando maneiras de explicar por que outras partes (como html sendo gerado na camada de dados) precisariam ser substituídas por práticas recomendadas para que a atualização de html e css ocorra. Há muitas boas sugestões aqui, que vou juntar quando falar com meu cliente.

Os não-técnicos não são idiotas (na maior parte). Eles podem entender um argumento técnico se você o mantiver alto o suficiente. Escolha uma tarefa que você acha que deveria ser simples e acompanhe-a por que não é.

Eu esperava que essa alteração fosse uma palavra em um arquivo. O lugar mais provável para mudar parecia estar aqui, mas quando eu mudei lá, ele só funcionou em um lugar e quebrou esses outros 7 lugares. Quando eu consertei um, ele quebrou mais dois lugares, causando um efeito dominó, então uma mudança que eu pensei que deveria ter levado 10 minutos acabou levando 2 horas. Esse é apenas um exemplo. Existem muito mais tarefas inesperadas de 2 horas lá.

Estrutura de código, estilo e dívida técnica são algo que, pelo menos inicialmente, até que o cliente confie em você, você precisará conviver.

Vulnerabilidades de segurança são outra questão.

Pessoalmente, eu faria uma estimativa com base no trabalho necessário usando a estrutura e o estilo existentes, deixando claro que há problemas significativos com a base de código. Eu aumentaria as implicações de segurança separadamente: faça uma demonstração de um hack no banco de dados para levar o ponto para casa durante uma reunião.

Fiquei muito contente ao fazer isso com um cliente anterior, com um sistema de cartão-presente de fidelidade, quando coloquei £ 5000 no cartão "meu" e ele fez o check no cartão no caixa.

Algumas ótimas sugestões aqui sobre como transmitir e comunicar isso ao cliente. Espero que eles paguem por você.

Grande bandeira vermelha aqui!

Se o cliente solicitar que você não faça nenhuma alteração além do que você concordou (HTML e CSS), repito esse projeto e retiro minha oferta.

Mesmo com uma visão geral escrita e bem comunicada de todas as falhas e problemas de segurança, a responsabilidade potencial é grande demais para que eu me sinta confortável. Mesmo que o cliente nunca tenha tomado medidas legais ou exigido correções após um hack ou violação; seu nome e reputação ainda estão ligados ao trabalho!

Você pode muito bem perder muito mais do que ganha.

Explique e, eventualmente, demonstre a falha
Quando é sua palavra contra a dele, tudo o que você diz pode ser apenas ar quente no que diz respeito a eles. Depois de mostrar a eles como o aplicativo pode ser abusado via injeção SQL, de repente você é uma pessoa confiável. Você precisará de credibilidade para renegociar. E isso é suficiente para mudar o jogo para dar a você.

Seja caridoso em relação ao seu antecessor
Isso não significa fingir que os erros não existem, mas se você se deparar com condescendência, perderá credibilidade. Não diga uma palavra sobre o programador, exceto talvez para lhe dar o benefício da dúvida. Concentre-se no código, não no codificador. Fazê-los sentir que você é o "cara legal" lhe dará muito mais margem de manobra nas negociações. E "mocinhos" nunca dizem coisas más. Ao explicar erros de segurança existentes (como vulnerabilidades de injeção SQL) ao cliente, prefiro dizer algo como isto:

A segurança de aplicativos da Web é um campo em rápida evolução. Muitas das ferramentas e técnicas de desenvolvimento que as pessoas aprendem até hoje evoluíram antes que a maioria dessas explorações fosse bem compreendida. Para se manter à frente dos desenvolvimentos de segurança, você deve seguir o campo de muito perto e, ocasionalmente, até mudar todo o seu estilo de desenvolvimento. A maioria dos programadores não faz isso.

Aqui vamos nós. Nenhuma palavra do mal falada sobre o desenvolvedor; ele é apenas "a maioria dos programadores", o que significa que ele está em ótima companhia. E agora você demonstrou que você não "a maioria dos programadores", que lhe dão um pouco mais de credibilidade e talvez uma razão para eles a pagar-lhe mais dinheiro.

Negocie um novo acordo
Quando o cliente entender que seu aplicativo está aberto a abusos pelo público, ele desejará que ele seja corrigido. Você provavelmente é a pessoa que ele vai pedir para consertar. Você pode ou não querer esse trabalho, então pense cuidadosamente antes de falar com eles.

No mínimo, você quer mais tempo para terminar o trabalho que eles já lhe deram. Você os deixou desprevenidos o suficiente com os itens de vulnerabilidade que provavelmente não o manterão em sua estimativa original. Mas verifique se o cliente sabe o que você é e não vai consertar como parte desse acordo.

Normalmente, o desenvolvedor (você) prefere refazer tudo do zero. E em casos como esse, isso pode até ser uma opção. Mas, mesmo assim, o cliente desejará algo que possa manter seus negócios funcionando até que o novo aplicativo seja construído. Isso significa que, embora você esteja começando de novo, provavelmente ainda precisará atualizar um pouco o aplicativo antigo.

Comecei isso como um comentário, porque a princípio pensei que fosse um aparte, mas provavelmente não é.

Eu documentaria completamente tudo o que você acha que deveria ser redesenhado, e por quê (o que acontece se eles não fizerem a alteração) e uma estimativa sobre como corrigir o problema. Eu seria particularmente meticuloso com qualquer coisa que você considere um risco à segurança.

Eu faria isso antes de tocar em qualquer código e certifique-se de que seu cliente tenha uma cópia deste relatório, de preferência com algum tipo de carimbo de data / hora. Pode levar algum tempo, mas também o cobrirá se um desses riscos à segurança surgir. Ainda melhor se você conseguir assinar algo que diz que recebeu o documento.

Claro, você pode apontar para o controle de origem do código original que herdou, se isso acontecer, mas será muito mais fácil apontar para este documento e dizer, de uma maneira mais profissional: "Está vendo? Eu te disse."

Este documento pode ser o ponto de partida de discussões adicionais e pode até ser usado pelo seu cliente para obter as "pessoas certas" para dar permissão para fazer algumas ou todas as alterações.

Dito isto, uma vez que o cliente compreenda os riscos, sorria e aceite-o se ele disser para fazer o trabalho de qualquer maneira ou se afastar.

Lembre-se de que o cliente está pedindo ajuda para manter sua aplicação. É seu trabalho como profissional apontar quaisquer problemas encontrados com a aplicação deles. O cliente provavelmente não tem idéia de que esses problemas existem e eles devem ser informados deles. Explique esses problemas de uma maneira que eles possam entender e permita que eles decidam como desejam prosseguir.

Use exemplos do mundo real para ilustrar esses problemas, como um carro quebrado ou uma máquina de lavar que precisa de reparos. Apontar é usar exemplos com os quais eles já estão familiarizados. Para explicar a injeção de SQL, eu simplesmente demonstraria o que é isso e por que é um problema.

No final, você deseja transmitir que se importa com o sucesso do aplicativo em que está sendo solicitado a trabalhar.

Eu gosto de usar analogias com as quais o cliente pode se relacionar. A quantidade de trabalho que eu dediquei ao ganhar o cargo dependeria da quantidade de dinheiro que o cliente pretendia gastar (US $ 100 é muito diferente de US $ 20.000). Observe que eu disse "pretendendo". Sua estimativa pessoal do valor envolvido não significa muito se você não receber o que está pedindo.

Na sua situação - novamente dependendo do dinheiro - eu poderia desenhar uma caixa com uma linha saindo de cada lado e dizer ao cliente "É assim que você visualiza o software agora. Os dados entram por um lado e saem pelo outro, tudo parece agradável, limpo e simples ". "É assim que você acha que o software é por dentro" e depois desenhe uma terceira linha conectando as duas linhas dentro da caixa.

Depois, desenhava outra caixa como a primeira com as linhas de entrada e saída do lado de fora, exceto que desta vez eu diria "Aqui está como o software realmente se parece dentro da caixa agora". e então para conectar as duas linhas dessa vez eu desenharia uma pilha aleatória de bagunça de espaguete, possivelmente com pausas, junções e rabiscos.

Finalmente, eu dizia: "Agora, o que você está me pedindo para fazer é isso ..." e desenhe uma forma simples dentro da primeira caixa, talvez um pequeno semicírculo tocando a linha e depois diga "mas, para fazer isso, eu ' eu tenho que fazer isso ... "e desenhar um tornado com um formato de espiral em torno da linha e continuar ..." para contornar tudo isso ..... "e apontar para o espaguete na outra caixa.

Eu acho que isso levaria o ponto para casa em cerca de 2 minutos. Se eles insistirem que você faça isso de qualquer maneira, documente-o como os outros mencionam acima.

Como posso explicar ao meu cliente o quão ruim é esse código?

Talvez você possa usar uma analogia como o encanamento de uma casa que, com o tempo, após reparos e remodelações, se torne tão inconstante e acoplado que, ao consertar uma coisa, afete e possivelmente quebre outra coisa que precisa ser consertada e simplesmente não há como você saber todos os lugares em que isso ocorrerá.

É minha palavra contra o consultor anterior, então como posso realmente dar exemplos simples e concretos que um cliente não técnico entenderia?

Você está certo, é uma palavra contra qualquer visual que o consultor anterior tenha criado em suas cabeças. Minha sugestão é fazer exatamente o que você está pedindo, dar exemplos simples e concretos. Como esse é um novo design, mostre como um fragmento HTML definido no código compilado é exibido com o restante de uma página HTML e como a alteração que afeta ou não, no restante da página. Talvez esse mesmo código compilado processe a marcação depois de aplicar alguma regra "comercial". Mostre a diferença.

Este é um problema difícil e MUITO comum. Boa sorte com isso.

Seja honesto e seja direto.

Mas o mais importante é não aceitar um trabalho que não atenda às suas expectativas. A maioria das pessoas não percebe que um contratado pode demitir um cliente, ele pode e deve se o trabalho for mais problemático do que vale a pena.

Aqui está uma analogia que eu usei (embora eu não ateste sua eficácia): Imagine que o site deles seja uma máquina física, como uma impressora mecânica que de alguma forma aceita informações.

Eles provavelmente pensam na máquina como tendo um componente que faz X e outro que faz Y. Na realidade, são 20 ou mais máquinas semelhantes. Alguns deles não fazem mais nada, todos tentam executar as funções que os outros já fazem e ninguém além do consultor anterior jamais viu algo exatamente como eles antes.

"Veja este dispositivo aqui que analisa as variáveis ​​de postagem e envia esse componente para um buraco de coelho de if-elses? Não há apenas um deles, há um em cada página (ou o que for), alguns deles higieniza a entrada e algumas não (ou nem todas) e sem ler a coisa toda, não sei qual. "

Um ponto ainda não mencionado é que você pode simplesmente estar ultrapassando o que seu cliente realmente deseja de você nesse caso. Superar o desempenho é ótimo e pode oferecer muita satisfação no trabalho. Mas se o cliente simplesmente não se importa, acha que o desempenho atual é "bom o suficiente" e quer apenas algumas atualizações menores, pode ser impossível convencê-lo a fazer um grande investimento em você para revisar a base de código.

Nesse ponto, você provavelmente precisará decidir se deve seguir os princípios e se recusar a aceitar um emprego que forçaria você a atribuir seu bom nome a uma bagunça embaraçosa em código ou se você pode segurar o nariz, entrar, fazer o trabalho com fita adesiva e pague o seu pagamento.

Se você decidir prosseguir com o trabalho de fita adesiva, certifique-se de documentar, documentar e documentar e ser o mais transparente possível. A última coisa que você quer é ser responsabilizado por algo dar errado no futuro, resultado de uma falha no aplicativo sobre a qual você alertou o cliente, mas que o cliente decidiu que não era importante o suficiente para lidar no momento.

No que diz respeito aos riscos de injeção de SQL, como outros disseram, você deve ser capaz de demonstrar os perigos a eles de uma maneira que mostre os riscos sem fazer nada destrutivo na produção. Mas, novamente, se eles o veem e não se importam o suficiente para pagar você para consertá-lo, você fez sua diligência de boa fé nesse caso.

É noob sauce para entrar em um projeto e sugerir uma reescrita, executar um pequeno subconjunto das modificações e usá-las para ilustrar o quanto mais simples e barato poderia ter sido. Você tem um exemplo demonstrável de por que o aumento do custo de desenvolvimento mais limpo levará a custos de manutenção mais baixos e desenvolvimento mais rápido a longo prazo, devido a um pequeno custo de fonte.

Nunca se esqueça de que, fundamentalmente, você está pedindo que eles paguem para tornar sua vida mais fácil, na mente deles, a única necessidade de encontrar 'o cara' que pode X destacar recursos a um custo Y e aumentar a complexidade do seu projeto podem apenas eliminar a oportunidade para voce. É um caminho difícil quando você reescreve um mês e se reúne com o desenvolvedor original apenas para perceber que o aplicativo inteiro foi gravado em uma janela extremamente contratada por um desenvolvedor que entendeu completamente todos os compromissos que foram feitos. Se o aplicativo parecer horrível internamente, mas funcionar externamente bem, como você diz, é bem provável que seja esse o caso. Muitas vezes, a dívida técnica dentro de uma base de código é um produto das restrições de recursos em que o código foi desenvolvido e, se eles não estão construindo uma equipe e estão contratando coisas ...

Estou só a dizer'

Vou interpretar o advogado do diabo aqui (um pouco como o @khrome está dizendo: "você não está pagando clientes para facilitar sua vida"). Eu diria até que o caso que você apresentou é muito unilateral porque você descreveu o caso de maneira geral. A maioria dos consultores entrantes em um novo projeto lançaria uma luz negativa ao anterior ... Não estou dizendo que é o que você está fazendo aqui, mas até vermos exemplos, não posso simplesmente aceitar sua palavra.

Dito isto, vou tentar resolver os problemas para você ponto a ponto:

• Injeções de SQL . OK, acho que o programador estava usando concatenações de strings em vez de consultas parametrizadas e / ou procedimento armazenado. Isso é muito fácil de corrigir, especialmente no ADO.NET ... Eu pessoalmente mencionaria isso para o cliente, mas não faria muito disso.
• O HTML está sendo gerado na lógica de negócios e seria um pesadelo para resolver . OK, cara, este é um daqueles onde você me dá mais detalhes. A menos que você esteja usando o MVC, essa é uma tendência a acontecer ... mas não é necessariamente uma coisa ruim ... é uma daquelas coisas em que a maioria dos programadores diria " ir para o mal; nunca usá-lo", mas você sabe? Eu usei ir aonde fazia sentido! Então, você tem certeza de que eles não estão usando classes auxiliares que compartilham o mesmo espaço de nome que a DLL do código comercial? Novamente, não é tão difícil de isolar.
• a lógica de negócios está espalhada por todo o aplicativo, há muita duplicação e código de beco sem saída que não faz nada. . E? O cliente está apenas solicitando que você altere HTML / CSS. Por que você se importaria com esses problemas?
• ele continua lançando exceções que estão sendo sufocadas, portanto o site parece funcionar sem problemas . Mais uma vez, muito vago. Exceções são normais em todos os aplicativos, é por isso que temos cláusulas try / catch em nosso código. A menos que eles surjam na interface do usuário e arruinem a experiência do usuário (como exibir HTTP 500 desnecessariamente), não acho que isso seja algo com o qual você deva se preocupar.

Então, em resumo, eu aconselho você a pegar a estrada. Se você acha que não vale o seu tempo e deseja reescrevê-lo às custas do seu cliente, afaste-se do trabalho. Sério, no final, o cliente paga pelo seu tempo para fazer a coisa toda funcionar com a menor quantidade de $$$.

Nos meus muitos anos de experiência no campo, sempre digo que os melhores programadores que encontrei são aqueles que podem tornar um sistema estável escrevendo a menor quantidade de código , não reescrevendo tudo .

Edit: Eu já vejo que minha resposta não é a mais popular (eu já esperava isso), mas mantenho a minha resposta. Eu editei isso para torná-lo menos irritante. ;-)

Certamente, os ataques de injeção de SQL e outras falhas funcionais no aplicativo tiveram precedência, mas você também pode "demonstrar" a qualidade e as práticas incorretas do código. Com as ferramentas de métricas de código, você pode demonstrar claramente o quão ruim é o código e mostrar a ele quanto isso aumentará em custos para futuras alterações e correção de erros. Não estou familiarizado com o ambiente .net, mas tenho certeza de que há vários para escolher.