Como os programadores rápidos e sujos sabem que acertaram?

O código provavelmente não está certo.

No entanto, isso pode não importar.

Rápido e sujo pode ser o caminho certo para ir em situações onde:

• O código tem um tempo de vida curto . Por exemplo, você está transformando vários dados em um formato padrão com um programa ad-hoc.
• O impacto negativo da falha é baixo :
  • Os dados que você está transformando não são críticos e os erros podem ser facilmente corrigidos
  • O usuário final é um programador compreensivo, que raciocina sobre mensagens de erro e trabalha em torno delas, digamos, massageando a entrada.

Às vezes, não é importante que o código seja robusto e lide com todas as entradas concebíveis. Às vezes, só precisa lidar com os dados conhecidos que você tem à mão.

Nessa situação, se os testes de unidade ajudarem você a escrever o código mais rápido (esse é o caso para mim), use-os. Caso contrário, código rápido e sujo, faça o trabalho. Bugs que não são acionados não importam. Bugs que você conserta ou trabalha ao redor não importa.

O que é absolutamente vital é que você não diagnostique mal essas situações. Se você codificar rápido e sujo, porque o código só vai ser usado uma vez, então alguém decide reutilizar o código em algum projeto que merece um código melhor, esse código merecia mais cuidado.

Eles não. Atualmente, estou trabalhando em uma base de código criada por programadores "rápidos e sujos" que "limpariam mais tarde". Eles já se foram há muito tempo e o código continua vivo, rompendo seu caminho para o esquecimento. Codificadores Cowboy , em geral, simplesmente não entendem todos os possíveis modos de falha que seu software pode ter, e don ' • compreender os riscos a que estão expostos a empresa (e clientes).

Ok, correndo o risco de ser uma isca completa, eu vou aos "diabos defenderem" a visão oposta.

Proponho que nós, desenvolvedores, tenhamos uma tendência a nos preocupar demais com coisas como a prática adequada e a limpeza do código. Eu sugiro que, enquanto essas coisas são importantes, nada disso importa se você nunca enviar .

Qualquer um que esteja neste negócio há algum tempo provavelmente concordaria que seria possível mexer com um software mais ou menos indefinidamente. Duke Nukem Forever, meus amigos. Chega um momento em que aquele recurso interessante ou aquele trabalho de refatoração tão urgente deveria ser posto de lado e a coisa deveria ser chamada DONE.

Eu lutei com meus colegas sobre isso muitas vezes. Há sempre mais um tweak, algo mais que "deveria" ser feito para que seja "certo". Você sempre pode encontrar isso. Em algum momento, no mundo real, basta ter que ser bom o suficiente. Nenhum software de navegação real, real, é perfeito. Nenhum. Na melhor das hipóteses, é bom o suficiente.

Esses programadores quase nunca sabem acertam, apenas acreditam . E a diferença pode não ser fácil de perceber.

Eu me lembro de como costumava programar antes de aprender sobre o teste de unidade. E lembro-me desse sentimento de confiança e confiança em um nível completamente diferente depois que executei meu primeiro conjunto decente de testes unitários. Eu não sabia que esse nível de confiança no meu código já existia antes.

Para alguém que não tem essa experiência, é impossível explicar a diferença. Assim, eles podem até continuar desenvolvendo-se no modo de código e oração durante toda a vida, com benevolência (e ignorância) acreditando que estão fazendo o melhor possível, considerando as circunstâncias.

E vamos encarar isso, é provável que você não seja. Eu, por mim mesmo, sei que não sou. Eu tive alguns raros momentos de fluxo - e incontáveis horas de pesar e tristeza, geralmente causadas por meus próprios erros. É melhor ser honesto e realista. De fato, acredito que os maiores programadores estão plenamente conscientes de sua própria falibilidade e erros passados, de modo que conscientemente desenvolveram o hábito de checar duplamente suas suposições e escrever aqueles pequenos testes unitários, para se manterem no lado seguro. ( "Eu não sou um ótimo programador - apenas um bom programador com grandes hábitos". - Kent Beck.)

Testes de unidade . É a única maneira de ter confiança em qualquer código (sujo ou não).

Em uma nota lateral;

short cuts make for long delays (Pippin)

É bom aprender a aceitar que nenhum sistema de software de complexidade razoável será perfeito, independentemente da quantidade de testes de unidade e ajustes de código realizados. Algum grau de caos e vulnerabilidade ao inesperado sempre se escondem no código. Isso não significa que não se deve tentar produzir um bom código ou realizar testes unitários. Estes são, obviamente, importantes. Há um equilíbrio que precisa ser buscado e isso varia de projeto para projeto.

A habilidade a ser desenvolvida é uma compreensão de qual nível de "perfeição" precisa ser usado para um projeto em particular. Por exemplo, se você estiver escrevendo um aplicativo de registros médicos eletrônicos com uma linha do tempo de projeto de 12 meses, dedique muito mais tempo para testar e garantir que seu código seja passível de manutenção do que para um aplicativo único de registro na conferência. que deve ser implantado até sexta-feira. Os problemas chegam quando alguém que faz o aplicativo EMR fica desleixado ou o aplicativo de registro não é implantado a tempo porque o programador está muito ocupado com o código de ajustes.

Rápido e sujo está perfeitamente bem dentro de um subsistema . Se você tem uma interface bem definida entre sua porcaria e o resto do sistema, e um bom conjunto de testes de unidade que verificam se o seu código feio, rápido e sujo, faz a coisa certa, pode estar perfeitamente bem.

Por exemplo, talvez você tenha um hediondo hack de expressões regulares e offsets de bytes para analisar alguns arquivos provenientes de terceiros. E suponha que você tenha um teste dizendo que o resultado obtido ao analisar os arquivos de exemplo é o que você espera. Você poderia limpar isso para que você pudesse ... Eu não sei, reagir mais rapidamente quando um terceiro altera um formato de arquivo? Isso não acontece com freqüência suficiente. É mais provável que eles mudem para uma API completamente nova e você jogue fora o antigo analisador e conecte um novo que esteja de acordo com a mesma API, e voila, pronto.

Onde rápido e sujo se torna um problema é quando sua arquitetura está rápida e suja. Seu objeto de domínio principal precisa ser bem pensado e suas interfaces, mas as bordas do seu sistema geralmente podem ser confusas sem nunca ter que pagar o piper.

Aqui está uma história sobre um programador rápido e sujo que eu conheço.

Eu conheço uma pessoa que considera os testes de unidade uma perda de tempo. Depois de muita discussão, ele finalmente escreveu um. Consistia em um método longo polvilhado com & & e || e retornou um booleano para asseverar True. A declaração abrange 20 linhas. Então, novamente, ele escreveu uma aula em que cada método tinha uma linha e uma principal tinha mais de 1000 linhas sem espaços em branco. Era uma parede de texto. Quando revi seu código e inseri algumas linhas novas, ele perguntou "por que". Eu disse 'Por causa da legibilidade'. Ele suspirou e os apagou. Ele colocou um comentário no topo "Não toque, funciona!"

Da última vez que falei com ele, ele codificou um site para uma empresa. Ele estava tentando encontrar um bug. Ele passou os últimos 3 dias fazendo isso por 8 horas por dia. Um pouco mais tarde, conversei com ele novamente, e o companheiro de equipe dele mudou o valor de um literal e não o atualizou mais onde. Não foi uma constante. Então ele mudou os outros literais também para que seu bug fosse corrigido. Ele reclamou do código de espaguete de seu companheiro de equipe. Ele me disse: 'Haha, não sabemos como é ficar acordado a noite inteira com o depurador, sem dormir por causa de um problema desagradável?' Ele acha que isso é algo que os programadores realmente bons fazem e ele realmente se sente bem com isso.

Além disso, ele acha que ler livros de programação e blogs é inútil. Ele diz: "apenas comece a programar". Ele fez isso por 12 anos e acha que é um excelente programador. / facepalm

Aqui está mais um pouco.

Outra vez, estávamos escrevendo uma classe DatabaseManager para nosso aplicativo da web. Ele colocou todas as chamadas do banco de dados nele. Era uma aula de Deus com mais de 50 métodos para todas as coisas imagináveis. Eu sugeri que dividíssemos em subclasses, porque nem todo controlador precisa saber sobre cada método de banco de dados. Ele discordou, porque era 'fácil' ter apenas uma classe para o banco de dados inteiro e era 'rápido' adicionar um novo método sempre que precisássemos de um. No final, o DatabaseManager tinha mais de 100 métodos públicos de autenticação do usuário para a classificação de locais arqueológicos.

Minha lição em evitar rápido e sujo foi quando eu tinha seis meses para entregar o que era estimado (subestimado) em um ano de trabalho. Eu decidi pesquisar metodologias antes de começar o trabalho. No final, investi três meses de pesquisa e consegui entregar nos três meses restantes.

Temos grandes ganhos ao identificar funcionalidades comuns e criar as bibliotecas necessárias para lidar com esses requisitos. Ainda vejo codificadores que escrevem seu próprio código quando há rotinas de biblioteca disponíveis. Esses codificadores geralmente reescrevem ou, quando muito, recortam e colam o mesmo código quando precisam resolver o mesmo problema mais tarde. As correções de bugs invariavelmente captam apenas algumas das cópias de código.

Um desenvolvedor deu uma resposta quando lhe pedi para usar o código da biblioteca: "Isso não é trapaça? Eu tive que escrever todo o meu próprio código na escola."

Em alguns casos, acho que pode haver um grande conjunto de testes de regressão que encontrarão "todos" bugs e verificarão o comportamento, permitindo assim uma técnica de codificação rápida e suja. Mas, na maioria das vezes, é apenas uma questão de mau planejamento de projeto e um gerente que acha mais importante realizá-lo do que fazê-lo da maneira certa.

E esqueça "limpar depois", isso nunca acontece. Nos casos raros, o programador terá esquecido a maior parte do código tornando o trabalho muito mais caro do que se ele tivesse feito certo da primeira vez.

O produto é enviado.

O código não existe no vácuo. Eu sofri incômodo incansável de luto as conseqüências de codificação rápida e suja e vaqueiro. Mas às vezes terminar o produto é a prioridade, não descobrir como escrever o melhor código. Por fim, se o produto for lançado e funcionar bem o suficiente, os usuários e clientes não saberão como o código interno está "ruim", e admito que houve momentos em que eu não me importei com "conseguir" certo "contanto que eu tenha saído pela porta.

Sim, isso em uma questão organizacional e "nunca deveria acontecer". Mas se você estiver escrevendo código em uma organização mal gerenciada e altamente orientada a prazos, no nível individual do programador as opções são limitadas.

Eu não acho que eles possam honestamente dizer que acertaram, se não for fácil de manter. Se eles admitirem que precisam "limpar mais tarde", provavelmente há algo em que não pensaram o suficiente. Testá-lo completamente só revelará verdadeiramente qualquer problema com código sujo.

Eu pessoalmente não pretendia desenvolver a habilidade de "escrever código sujo" e ter confiança em sua correção. Eu prefiro escrever o código correto na primeira vez.

Como eles sabem que estão certos? O teste é a resposta simples.

Se o código deles tiver sido testado por uma boa equipe de controle de qualidade e for aprovado, eu diria que eles acertaram.

Escrever código rápido e sujo não é algo que deve ser feito como um hábito, mas ao mesmo tempo há ocasiões em que você pode gastar 20 minutos escrevendo código que pode ser classificado como sujo ou 4 horas refatorando muito código para fazer certo. No mundo dos negócios, às vezes 20 minutos é tudo o que está disponível para fazer o trabalho e quando você enfrenta prazos de entrega rápidos e sujos pode ser a única opção.

Eu já estive em ambas as extremidades disso, tive que consertar o código sujo e tive que escrever o meu próprio, a fim de contornar as limitações de um sistema que eu estava desenvolvendo. Eu diria que eu tinha confiança em o código que eu escrevi porque, embora estivesse sujo e um pouco hackeado, às vezes eu me certificava de que ele era completamente testado e tinha muito erro de manipulação, então se algo desse errado, não destruiria o resto do sistema.

Quando desprezamos esses programadores rápidos e sujos, precisamos nos lembrar de uma coisa: um cliente geralmente não paga até ter o produto, se ele é enviado e eles entram no teste da UAT e encontram os bugs de código rápido e sujo. é muito menos provável que eles saiam quando têm um produto quase em funcionamento na frente deles, mas se eles não têm nada e você está dizendo "você vai tê-lo em breve, estamos apenas fixando x" ou "foi adiada porque nós tinha que começar a trabalhar perfeitamente "eles são mais propensos a desistir e ir com um concorrente.

Claro que como esta imagem demonstra, ninguém deve subestimar o perigo de código rápido e sujo!

Eu não acho que você deva começar a ir por esse caminho. Rápido e sujo pode dar-lhe o benefício temporal de terminar mais rápido, mas você sempre paga dez vezes por fazer isso no final.

Na minha opinião, aprender a julgar o código Q & D por correção não é uma habilidade que merece ser desenvolvida porque é apenas uma prática ruim. Aqui está o porquê:

Eu não acho que "rápido e sujo" e "melhor prática" andem juntos. Muitos codificadores (inclusive eu) criaram códigos rápidos e sujos como resultado de uma distorção nas restrições triplas . Quando eu tive que fazer isso, geralmente era um resultado do escopo do escopo combinado com um prazo cada vez mais próximo. Eu sabia que o código que eu estava checando, mas cuspia saídas adequadas, dado um conjunto de entradas. Muito importante para os nossos stakeholders, nós enviamos a tempo.

Uma análise do relatório do CHAOS original deixa bem claro que as perguntas e respostas não são uma boa ideia e matará o orçamento mais tarde (seja em manutenção ou durante a expansão). Aprender como julgar se o código Q & D está correto é uma perda de tempo. Como Peter Drucker disse: "Não há nada tão inútil quanto fazer eficientemente aquilo que não deveria ser feito de jeito nenhum".

I can't tell if my new code is correct if it's too dirty.

"Sujo" significa coisas diferentes para pessoas diferentes. Para mim, significa principalmente confiar em coisas que você sabe que você provavelmente não deveria confiar, mas que você também sabe que pode esperar trabalhar a curto prazo. Exemplos: supondo que um botão tenha 20 pixels de altura em vez de calcular a altura; codificação rígida de um endereço IP em vez de resolver um nome; contando com uma matriz para ser ordenada porque você sabe que é, mesmo que o método que fornece a matriz não garanta isso.

O código sujo é frágil - você pode testá-lo e saber que ele funciona agora , mas é uma boa aposta que ele irá quebrar em algum ponto no futuro (ou então forçar todos a ande em cascas de ovos por medo de quebrá-las).

Correndo o risco de soar um pouco controverso, eu diria que ninguém realmente SABE que seu código é 100% correto e 100% sem erro. Mesmo quando você tem uma cobertura de teste realmente boa e está aplicando rigorosamente boas práticas de BDD / TDD, ainda é possível desenvolver código que contenha erros, e sim, isso pode até conter efeitos colaterais!

Apenas escrever código e supor que funciona implica excesso de confiança por parte do desenvolvedor das próprias habilidades do desenvolvedor, e que quando problemas surgem (o que eles inevitavelmente farão) o esforço para depurar e manter o código será caro, especialmente se outro desenvolvedor precisa manter o código mais tarde. A diferença real é feita aplicando boas práticas de engenharia de software, que garantem a confiança real de que seu código provavelmente funcionará na maior parte do tempo e que, se você encontrar um erro, é mais provável que seja mais fácil depurá-lo. e muito menos dispendioso para mudar e manter, independentemente da pessoa que trabalha com esse código mais tarde.

O ponto importante é que código bem fatorado e bem testado permitirá que OTHERS confiem em seu código, o que na maioria dos casos é mais importante do que sua própria confiança.

Se o código sujo for bem testado, pode ser confiável. O problema é que esse código sujo de teste de unidade é geralmente muito difícil e pesado. É por isso que o TDD é tão bom; revela e remove sujeira e cheiros. Além disso, o teste de unidade é muitas vezes a primeira coisa a sofrer de tempo de lazer. Então, se o cara mais limpo já fez o código mais limpo que já fez, eu ainda não confiaria nem um pouco, se ele omitisse os testes de unidade devido à segurança do tempo.

Bons programadores (Quick & Dirty e outros) não têm a arrogância para assumir que acertaram. Eles assumem que todos os grandes sistemas têm falhas e defeitos, mas que em algum momento podem estar suficientemente testados e revisados para ter um risco suficientemente baixo ou um custo de falha suficientemente baixo que o código possa enviar.

Então, por que esses, chamados Quick & Sujos, programadores existem? Minha hipótese é a seleção darwiniana. Programadores que enviam códigos viáveis rapidamente, ocasionalmente enviam antes dos navios de competição, ou o orçamento acaba, ou a empresa vai à falência. Portanto, suas empresas ainda estão empregando novos programadores para reclamar da bagunça que precisa ser limpa. O chamado código limpo também é enviado, mas não diferentemente o suficiente para impulsionar o Quick & Codificadores sujos em extinção.

Provavelmente, pode-se pensar que uma parte não ideal de um código não poderia fazer diferença, por causa da vida curta, do pouco impacto nos negócios ou do pouco tempo para fazê-lo. A resposta correta é que você realmente não sabe. Toda vez que eu escuto alguém dizendo que "este é um pequeno recurso", ou "vamos fazer isso da maneira mais rápida e simples que pudermos" e gastar tempo insuficiente pensando no design certo, as duas únicas coisas que realmente ocorrem são:

1-) O projeto fica maior e a motivação da equipe menor, trabalhando em código cheio de "pontos". Nesse caso, o projeto provavelmente será rápido para o caos.

2-) O projeto torna-se conhecido por ser uma solução não ideal e seu uso começa a ser desencorajado, em favor de uma nova solução ou uma refatoração que é tão cara quanto uma nova solução.

Tente sempre fazer o melhor código possível. Se você não tem tempo suficiente, explique por que você precisa de mais. Não se coloque em risco com o trabalho mal feito. Seja sempre um profissional melhor. Ninguém pode puni-lo por isso, se você for razoável. Se o fizerem, não é onde você deve se importar em trabalhar.

Discuta com o idoso e avalie o impacto das falhas, se houver. Por exemplo, uma situação em que você pode consertar tarefas sujas por 1 dia e um código robusto requer design e alteração de arquitetura, o que pode levar de 4 a 6 meses + tempo de validação adicional para validar completamente todos os fluxos de trabalho afetados pela alteração no design.

Precisamos tomar uma decisão baseada no Tempo + Capacidade + Prioridades na lista também. Uma boa discussão na equipe com idosos ou pessoas com maior experiência pode ajudar na tomada de decisão que melhor se adapte à equipe e à sua entrega.

O código limpo é a primeira e mais importante abordagem, como código sujo para salvar as escalações, decisões de ir / não aos clientes, mostrar rostos, reputação da organização na estaca e muito mais onde o código sujo facilita a limpeza código.