Demonstra código ruim para o cliente?

Não-técnicos não são idiotas (na maioria das vezes). Eles podem entender um argumento técnico se você mantiver um nível alto o suficiente. Escolha uma tarefa que você acha que deveria ser simples e mostre a ela por que não é.

I expected this change to be one word in one file. The most likely place to change it seemed to be here, but when I changed it there, it only worked in one place, and it broke these 7 other places. When I fixed one, it broke two more places, causing a domino effect, so a change I thought should have taken 10 minutes ended up taking 2 hours. That's just one example. There are a lot more unexpected 2 hour tasks in there.

Estrutura de código, estilo, dívida técnica são uma coisa que - pelo menos inicialmente, até que o cliente confie em você - você precisará viver com isso.

As vulnerabilidades de segurança são outro assunto.

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 levantaria as implicações de segurança separadamente: fazer uma demonstração de um hack no banco de dados para direcionar o ponto para casa durante uma reunião.

Eu tive uma grande alegria ao fazer isso com um cliente anterior com um sistema de cartão de presente de lealdade quando eu coloquei £ 5.000 no "meu" cartão e pedi que ele verificasse o cartão na sua conta.

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

Importante bandeira vermelha aqui!

Se o cliente pedir que você não faça alterações além daquelas com as quais concordou (HTML e CSS), aprovarei esse projeto e retirarei meu lance.

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

Você pode perder muito mais do que ganha.

Explicar e possivelmente demonstrar a falha em Quando é a sua palavra contra a dele, tudo o que você diz pode ser apenas ar quente, tanto quanto eles estão preocupados. Depois de mostrar a eles como o aplicativo pode ser abusado por meio de injeção de SQL, de repente você é uma pessoa confiável. Você vai precisar de credibilidade para renegociar. E isso é o suficiente para mudar o jogo para você.

Seja caridoso com relação ao seu antecessor
Isso não significa fingir que os erros não estão lá, 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 como se você fosse o "cara bom" lhe dará muito mais margem de manobra nas negociações. E "mocinhos" nunca dizem coisas ruins. Ao explicar erros de segurança existentes (como vulnerabilidades de injeção de SQL) ao cliente, prefiro dizer algo assim:

Web application security is a rapidly-evolving field. Many of the development tools and techniques that people learn even today evolved before most of these exploits were well-understood. In order to stay ahead of security developments, you have to follow the field very closely and occasionally even change your whole development style. Most programmers don't do this.

Lá vamos nós. Nem uma palavra de mal falada sobre o desenvolvedor; ele é apenas "a maioria dos programadores", o que significa que ele está em boa companhia. E agora você demonstrou que não são "a maioria dos programadores", o que lhe dá um pouco mais de credibilidade e talvez um motivo para eles pagarem mais dinheiro.

Negociar um novo acordo
Uma vez que o cliente entenda que seu aplicativo está aberto a abusos do público, ele vai querer que ele seja consertado. Você é provavelmente a pessoa que ele vai pedir para consertá-lo. Você pode ou não querer esse emprego, então pense bem antes de falar com eles.

No mínimo, você quer mais tempo para terminar o trabalho que eles já lhe deram. Você configurou o suficiente desprevenido com o material de vulnerabilidade que provavelmente não vai lhe dar a estimativa original. Mas certifique-se de que o cliente saiba o que você é e não vai consertar como parte desse arranjo.

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 vai querer algo que possa manter seus negócios funcionando até que o novo aplicativo seja criado. Isso significa que mesmo que você esteja começando de novo, provavelmente ainda terá que atualizar um pouco o aplicativo antigo.

Eu comecei isso como um comentário, porque no começo eu pensei que fosse um aparte, mas provavelmente não é.

Eu documentaria totalmente 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 para corrigir o problema. Eu seria particularmente meticuloso com qualquer coisa que você perceba como um risco de segurança.

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

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

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

Assim sendo, uma vez que o cliente perceba os riscos, sorria e agüente se eles disserem para fazer o trabalho de qualquer maneira, ou ir embora.

Lembre-se de que o cliente está lhe pedindo ajuda para manter seu aplicativo. É seu trabalho como profissional apontar quaisquer problemas que você encontrar em seu aplicativo. O cliente provavelmente não tem idéia de que esses problemas existem e eles devem ser informados sobre eles. Explique essas questões de uma maneira que elas possam entender e deixe que elas decidam como querem prosseguir.

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

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

Eu gosto de usar analogias com as quais o cliente pode se relacionar. A quantidade de trabalho que eu coloco na frente para ganhar o emprego dependeria da quantidade de dinheiro que o cliente estava pretendendo gastar (US $ 100 é muito diferente de US $ 20.000). Repare que eu disse "pretendendo". Sua estimativa pessoal do valor envolvido não significa muito se você não conseguir 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 vão para um lado e sai outro, tudo parece bom e limpo e simples ". "Isto é o que você acha que o software se parece por dentro" e, em seguida, desenhe uma terceira linha conectando as duas linhas dentro da caixa.

Então eu 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á o que o software realmente parece dentro da caixa agora". e então 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 diria: "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 teria que fazer isso ... "e desenhar um tornado que parece um tipo de espiral em torno da linha e continuar ..." para contornar tudo isso ... "e apontar para o espaguete no outra caixa.

Eu acho que isso levaria a questão 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?

É 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, é 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 resto de uma página HTML e como a alteração afeta ou não o resto da página. Talvez esse mesmo código compilado renderize a marcação depois de aplicar alguma regra de "negócios". Mostre a diferença.

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

Seja honesto e direto.

Mas o mais importante, não aceite um trabalho que não atenda às suas expectativas. A maioria das pessoas não percebe que um empreiteiro pode demitir um cliente, eles podem e devem se o trabalho é mais problema do que vale a pena.

Aqui está uma analogia que eu usei (embora eu não confirme sua eficácia): imagine que o website deles é uma máquina física, como uma prensa mecânica que de alguma forma aceita entrada.

Eles provavelmente pensam que a máquina tem componentes X e outra Y. Na verdade, são aproximadamente 20 máquinas similares. Alguns deles não fazem mais nada, todos tentam executar as funções que os outros já fizeram e ninguém além do consultor anterior já viu algo parecido com eles antes.

"See this gizmo here that parses the post variables and then sends this component down a rabbit-hole of if-elses? There isn't just one of these, there is one of these in every page (or whatever), some of them sanitize the input and some don't (or all don't) and without reading the entire thing I can't know which."

Um ponto ainda não mencionado é que você pode simplesmente estar extrapolando o que seu cliente realmente quer de você neste caso. Overachieving é ótimo e pode dar-lhe muita satisfação no trabalho. Mas se o cliente simplesmente não se importar, acha que o desempenho atual é "bom o suficiente" e quer apenas algumas atualizações menores, pode ser impossível persuadi-los a fazer um grande investimento em você para reformular a base de código.

Nesse ponto, você provavelmente precisará decidir se deve se basear em princípios e se recusar a aceitar um emprego que o force a anexar seu bom nome a uma confusão de códigos embaraçosos ou se você pode segurar seu nariz, entrar, o trabalho feito com fita adesiva, e saia com o seu pagamento.

Se você decidir prosseguir com o trabalho de fita adesiva, certifique-se de documentar, documentar, documentar e ser o mais transparente possível. A última coisa que você quer é ser culpado por algo que está errado no futuro, que é resultado de uma falha de aplicativo da qual você avisou 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 já disseram, você deve ser capaz de demonstrar aos perigos disso para eles de uma forma que mostre os riscos sem realmente fazer algo destrutivo na produção. Mas, novamente, se eles o vêem e não se importam o suficiente para pagar a você para consertá-lo, você fez sua diligência de boa fé neste caso.

É molho noob entrar em um projeto e sugerir uma reescrita em primeiro lugar, executar um pequeno subconjunto das modificações e usá-las para ilustrar o quão mais simples e barato poderia ter sido. Então você tem um caso demonstrável sobre por que o aumento do custo de desenvolvimento mais limpo levará a menores custos de manutenção e desenvolvimento mais rápido a longo prazo, dado um pequeno custo de fonte.

Nunca esqueça que fundamentalmente você está pedindo para que eles paguem para facilitar sua vida, na mente deles, a única necessidade de encontrar 'o cara' que pode ter recursos X e aumentar a complexidade do seu projeto pode elimine a oportunidade para você. É um caminho difícil quando você passa um mês na reescrita e se encontra com o desenvolvedor original apenas para perceber que o aplicativo inteiro foi escrito em uma janela extremamente contratada por um desenvolvedor que entendeu completamente todos os compromissos que foram feitos. Se o aplicativo parece horrível internamente, mas funciona externamente bem, como você diz, é bem provável que esse seja 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 contraindo as coisas ... eles provavelmente ainda não estão falando sério sobre manutenção.

Estou apenas dizendo

Dito isso, vou tentar resolver os problemas para você ponto por ponto:

• Injeções SQL . OK, então eu acho que o programador estava usando concatenações de string 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 muita diferença com isso.
• HTML está sendo gerado na lógica de negócios e seria um pesadelo para resolver . OK, cara, esse é um daqueles em que você me dá mais detalhes. A menos que você esteja usando MVC, isso é uma tendência a acontecer ... mas não é necessariamente uma coisa ruim ... é uma daquelas coisas em que a maioria dos programadores diria " goto é ruim; nunca use "mas você sabe o que? Eu usei goto onde fazia sentido! Então, você tem certeza de que eles não estão usando classes auxiliares que estão compartilhando o mesmo namespace que o código de negócios DLL? Mais uma vez, não é tão difícil de isolar.
• A lógica de negócios é distribuída por todo o aplicativo, há muita duplicação e código sem saída que não faz nada. . E? O cliente está apenas pedindo para você alterar o HTML / CSS. Por que você se importaria com essas questões?
• continua lançando exceções que estão sendo sufocadas, então o site parece rodar sem problemas . Mais uma vez, muito vago. Exceções são normais em qualquer aplicativo, e é por isso que temos cláusulas try / catch em nosso código. A menos que eles explodam na interface do usuário e arruínem a experiência do usuário (como exibir desnecessariamente o HTTP 500), eu não acho que isso é algo com o qual você deve se preocupar, também.

Então, em suma, eu aconselho você a tomar o caminho mais alto. Se você acha que não vale a pena e quer reescrevê-lo às custas do seu cliente, saia do trabalho. Sério, no final, o cliente paga pelo seu tempo para fazer a coisa toda funcionar com a menor quantidade de $ $.

Em meus muitos anos de experiência no campo, eu sempre digo que os melhores programadores com quem eu me deparei são aqueles que podem tornar um sistema estável ao escrever a menor quantidade de código , não reescrevendo a coisa toda .

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

Certamente, os ataques de injeção de SQL e outras falhas funcionais no aplicativo têm precedência, mas você também pode "demonstrar" práticas e práticas de código incorretas. 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 custo para futuras alterações e correção de bugs. Eu não estou familiarizado com o ambiente do .net, mas tenho certeza de que existem vários para escolher.