Demonstrar código incorreto para o cliente?

129

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.

jtiger
fonte
97
Demonstrar um ataque de injeção SQL?
Austin Henley
30
This application was not written well. At all.Eles quase nunca são. :)
haylem
15
Além de demonstrar os problemas, como diz Austin. não subestime o poder de um quadro branco e de uma caneta marcadora. A maioria das pessoas responde bem a um design ruim explicado quando está na forma de imagem.
Sirex
3
se não é grande - reescrevê-lo, se é grande - não levá-lo
ren
4
Cliente diz redesenhar e eles pensam HTML / CSS. Eu usaria os termos "falta de modularidade" e enfatizaria o "design lógico" vs "apresentação". Metáforas da construção civil são úteis. To make a change in the look of the living room, I had to go into the air-conditioning system.Em um bom design modular, essas coisas não acontecem.
Fuhrmanator 14/11/2012

Respostas:

144

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á.

Karl Bielefeldt
fonte
10
Dado o conteúdo de tantos relatórios de bugs, "ele quebrou __ mais lugares", de fato, parece ser a melhor maneira de descrever o efeito dominó ...
Izkata
4
Certo, eu faria mais uma conexão entre tempo e custo. Mostre a eles quanto você esperava que uma mudança custasse versus quanto uma mudança acabou custando. Na minha experiência, os clientes raramente prestam atenção, a menos que você possa argumentar que está gastando o dobro, o triplo ou mais do que pagaria de outra forma.
Tim O'Brien
87

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.

Michael
fonte
38
+1 na demonstração de quão ruim pode ser o ataque de injeção de SQL. Faça na frente deles. Se possível, grave suas reações em vídeo.
Philip
40
@ Phillip: ... a demonstração deve estar preferencialmente em um ambiente de desenvolvimento isolado para o aplicativo. A eliminação do banco de dados de produção provaria o ponto, mas pode perder seu contrato (e ganhar uma ação judicial).
FrustratedWithFormsDesigner
19
@FrustratedWithFormsDesigner se eles ainda têm um ambiente dev disponível ...
catraca aberração
3
@FrustratedWithFormsDesigner: é claro que não é recomendável limpar o banco de dados, por mais fácil e dramático que seja. Mas pode ser igualmente surpreendente (para eles) extrair dados particulares e depois (cuidadosamente) alterar alguns valores (como o saldo de um cartão-presente, como é feito por @ Michael). Para obter pontos extras, torne óbvio que você realmente não precisa ver o código; comece despejando uma lista de tabelas, escolha alguns nomes interessantes, despeje o conteúdo. Não é preciso muito para aprofundar a questão de que é tão vulnerável.
Javier
76

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.

Steve
fonte
14
+1 para ver a imagem mais ampla. Se você trabalhar nisso e disser que terminou, poderá ser responsabilizado por bugs e problemas de segurança, mesmo que você os tenha herdado apenas. Se alguém manipulado meus freios, e um mecânico reparado minha moto e apenas deu de ombros o problema fora, eu também pode considerar processá-los ...
sleske
2
+1 Esta é uma lição que o consultor leva muito tempo para aprender (e, reconhecidamente, é um conceito difícil de prosseguir durante uma economia difícil). O valor do seu especialista é tanto uma função do trabalho que você faz quanto uma função do trabalho que você recusa.
amigos estão dizendo sobre tim O'Brien
2
+1 Esta é uma lição que aprendi da maneira mais difícil e meu primeiro negócio quase fracassou por causa disso. Freqüentemente, nesses casos, o custo de listar todos os 'defeitos' e de citar para corrigi-los exige mais esforço do que o cliente está disposto a pagar.
Catharz
30

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.

tylerl
fonte
8
+1 por nunca ser condescendente. Apenas deixar que os fatos falam por si ...
sleske
4
+1 em "Seja caridoso em relação ao seu antecessor".
msanford
19

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.

Wonko, o são
fonte
Vamos torcer para que eles estejam realmente usando o controle de origem.
12123 Bernard
6
Ótima resposta. Mas, como alguém que foi a tribunal por uma situação semelhante que incluía documentação completa e aprovação de um cliente, ainda me custou muito dinheiro e dor de cabeça.
Steve
5
Boa ideia em princípio - no entanto, observe que isso pode dar muito trabalho. Esta é, provavelmente, apenas prático para grandes trabalhos, caso contrário, você vai gastar 50 horas documentando problemas para um trabalho onde você só pode factura 20.
sleske
@ sleske: concordou que vai dar muito trabalho, mas espero que também ajude você se o pior caso possível acontecer e houver uma violação de segurança. No mínimo, você precisa de algo que indique que vê riscos à segurança e que não deseja ser responsabilizado por esses riscos pré-existentes.
Wonko the Sane
2
@WonkotheSane: Verdade, mas apenas se você aceitar o projeto . Se os problemas forem grandes e o trabalho planejado for pequeno, talvez seja melhor recusar o projeto. Obviamente, você ainda deve documentar suas preocupações (segurança e outras), mas se você nunca trabalhou no projeto, não deve haver risco de responsabilidade. Por fim, você terá que avaliar se seu cliente está disposto a pagar o custo da limpeza.
sleske
14

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.

Bernard
fonte
3
Isso não é nada como um carro quebrado, a menos que o carro tenha sido construído a partir de peças aleatórias por um mecânico amador. É como uma garagem construída por um empreiteiro incompetente, e o proprietário deseja que o OP coloque um abridor de porta automático. O OP descobre que a garagem não é segura e precisa de grandes retrabalhos imediatamente.
kevin Cline
2
Imagine um carro quebrado que usa fita adesiva para manter as peças unidas e impede que o painel exiba alertas ou avisos ao motorista, enquanto o volante pode cair a qualquer momento. É preciso alguma criatividade, mas é possível usar analogias diferentes para ilustrar um problema.
Bernard
Ou observe o cabo do acelerador de barbante personalizado que você pode amarrar ao console para acelerar a operação manual. A tecnologia 'fly by wire' é barata. Praticamente tudo o que eles fizeram no Red Green Show pode se aplicar. O que eles têm 'funciona', mas não é bonito, e parece que uma inspeção superficial é frágil e aumenta o risco de qualquer alteração.
JustinC
1
Se eu pudesse adicionar votos extras a isso, gostaria apenas de 'Lembre-se de que o cliente está pedindo ajuda para manter a aplicação deles'.
Daniel Hollinrake
7

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.

Prisioneiro 13
fonte
6

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.

Joey Guerra
fonte
6

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.

Michael
fonte
3

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. "

bem-vindo
fonte
"Imagine que o site deles seja uma máquina física, como uma impressora mecânica" - e está imprimindo dinheiro! Mas, porque é quebrado, não é imprimir tanto dinheiro quanto ele poderia ... que deve ligá-los, -)
MAWG
2

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.

skelly
fonte
0

É 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'

Khrome
fonte
0

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. ;-)

Dexter Legaspi
fonte
-1

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.

Uberto
fonte
Por que o voto negativo sobre isso? Claro, o cliente pode não ser técnico, mas as métricas de código produzem números e todos podem entender isso. Especialmente se há um bem documentado, não muito techy, explicação sobre o que significam esses números
MAWG