Como os programadores rápidos e sujos sabem que estão certos?


166

Se você perguntar aos programadores por que eles devem escrever um código limpo, a resposta número um que você obtém é a manutenção. Enquanto estiver na minha lista, meu principal motivo é mais imediato e menos altruísta: não sei dizer se meu novo código está correto se estiver muito sujo. Acho que me concentrei tanto nas funções individuais e nas linhas de código que, quando termino o meu primeiro rascunho e passo para trás para olhar para o cenário geral novamente, às vezes não se encaixa muito bem. Passar uma ou duas horas refatorando para limpeza freqüentemente descobre erros de copiar / colar ou condições de contorno que eram muito difíceis de detectar no rascunho.

No entanto, algumas pessoas acham ocasionalmente aceitável fazer o check-in intencionalmente de códigos sujos no interesse do envio de software, com um plano para "limpá-lo mais tarde". Existe alguma técnica praticável que lhes dê confiança na correção de seu código quando a legibilidade for menor que o ideal? Vale a pena tentar desenvolver uma habilidade? Ou a falta de confiança no código é algo que algumas pessoas acham mais fácil de aceitar?


40
Minha teoria é que todos os codificadores se enquadram em algum lugar entre "memorizadores" e "entendedores", e poucos conseguem fazer as duas coisas bem. Quanto mais porcaria você se lembrar de uma vez, mais bagunçado você pode se dar ao luxo de criar seu código. Quer o código esteja limpo ou não, faça-o funcionar, teste-o!
Job

35
No entanto, algumas pessoas acham ocasionalmente aceitável fazer o check-in intencionalmente de códigos sujos no interesse do envio de software, com um plano para "limpá-lo mais tarde". heh ... Inferno congelou antes que seja " mais tarde " ...
Carlos Campderrós

28
Nem todos os programadores pensam da mesma maneira - recebi um código para manter isso não fazia sentido para mim por meses, até que um dia foi como se um interruptor de luz fosse acionado, quando percebi qual era a estrutura geral da organização e tudo fazia sentido porque eles fizeram isso como eles fizeram. Eu teria feito dessa maneira? Não, mas funcionou.
13131 Joe

12
@joe - +1 - alguns programadores são muito rápidos em descartar códigos que não se encaixam na idéia pessoal de "código bom". Você deve sempre tentar entender o pensamento por trás de um corpo de código e seu estilo de código, frequentemente aprenderá algo útil.
James Anderson

10
How do quick & dirty programmers know they got it right?Porque ele funciona :)
Rachel

Respostas:


100

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

No entanto, isso não importa.

Rápido e sujo pode ser o caminho certo a seguir em situações em que:

  • O código tem uma vida útil curta . Por exemplo, você está transformando um monte de 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 as soluciona, 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, ele só precisa manipular os dados conhecidos que você tem em mãos.

Nessa situação, se os testes de unidade ajudarem você a escrever o código mais rapidamente (esse é o meu caso), use-os. Caso contrário, código rápido e sujo, faça o trabalho. Bugs que não disparam não importam. Os erros que você corrige ou soluciona em tempo real não importam.

O que é absolutamente vital é que você não faça um diagnóstico errado dessas situações. Se você codifica rápido e sujo porque o código será usado apenas uma vez, alguém decide reutilizar o código em algum projeto que mereça melhor código, esse código mereceu mais cuidado.


24
+1 em "o impacto da falha é baixo". Meu cálculo do risco matemático favorito é risco = conseqüência real de falha x probabilidade de falha x percebida consequência de não (Na minha experiência, o risco percebido as partes interessadas muitas vezes ficar preso em)
Trav

7
"O código tem uma vida útil curta. Por exemplo, você está transformando um monte de dados em um formato padrão com um programa ad-hoc". E se a transformação não for feita corretamente, mas discrepâncias nos dados não forem percebidas até muito mais tarde?
Joey Adams

3
@ Grav Então, apenas para confirmar, se a conseqüência real da falha é maciça, mas minha consequência percebida da falha é zero, não há risco algum?
22314 Christian Stewart

3
@ChristianStewart Do ponto de vista puramente matemático, sua afirmação estaria correta. No entanto, na prática, uma percepção de consequência sendo zero não negaria o peso da probabilidade x consequência real. A percepção é colocada na fórmula para explicar os medos organizacionais que freqüentemente influenciam as decisões de mitigação. A falta de tal medo não diminui a probabilidade ou as consequências reais. Assim, deve-se supor que a percepção é sempre pelo menos igual a 1 (uma vez que pode aumentar, mas não negar, de forma alguma, o risco real) #
727 Trav Trav

1
@ Grav Como alternativa, renomeie um. Ou seja, o risco deve ser trocado pelo risco percebido , pois, se acreditarmos que não há conseqüências de falha, provavelmente também acreditamos que não há risco.
Delioth 6/09/17

237

Eles não. Atualmente, estou trabalhando em uma base de código criada por programadores "rápidos e sujos" que "limpariam mais tarde". Eles se foram há muito tempo, e o código continua vivo, abrindo caminho para o esquecimento. Os codificadores de cowboy , em geral, simplesmente não entendem todos os modos de falha em potencial que seu software pode ter e não entendem os riscos aos quais estão expondo a empresa (e clientes).


31
Sempre que eu ouvir "limpar tudo mais tarde" ou "faremos isso quando as coisas desacelerarem um pouco", estou sempre tentado a começar a cantar "amanhã, amanhã, eu vou te amar amanhã. É sempre um dia acordado, todo dia". Isso poderia ser apenas eu, no entanto.
JohnFx

8
Muitos de nós estamos nessa posição bastante infeliz. É muito desanimador legar a dívida técnica de outras pessoas .
Mark Booth

34
O problema real é classificar outros programadores em títulos de cowboy ou quick & dirty ou outros. Todo programador possui alguns modos de falha, e ler o código de outra pessoa é muito difícil, e encontrar suas próprias falhas é muito difícil. Todos estes juntos significa que as pessoas muito facilmente rotular outros programadores como os maus, ao pensar o seu próprio código é perfeito
tp1

3
@ tp1: Bons programadores podem escrever código fácil de ler. Eles fazem isso pedindo que alguém o leia e esclarecendo qualquer coisa que não esteja clara. Com a prática, a parte que não estiver clara na primeira leitura diminuirá.
Kevin cline

9
@ JimThio, você acha mesmo que algum dos programadores mencionados acima intencionalmente escreveu código ruim? Você já leu o código escrito por você mesmo alguns anos atrás? Você achou bom? Provavelmente, você fez o seu melhor naquela época e ainda vê muitas coisas a serem melhoradas nesse código agora.
Péter Török

103

Certo, correndo o risco de ser uma isca completa, vou "defender os diabos" da visão oposta.

Proponho que os desenvolvedores tendam a se preocupar demais com coisas como prática adequada e limpeza de código. Sugiro que, embora essas coisas sejam importantes, nada disso importa se você nunca enviar .

Qualquer pessoa que esteja neste ramo há algum tempo provavelmente concordaria que seria possível mexer com um pedaço de software mais ou menos indefinidamente. Duke Nukem Forever, meus amigos. Chega um momento em que esse recurso interessante ou, oh, que trabalho de refatoração tão urgente deveria ser deixado de lado e a coisa deveria ser chamada de CONCLUÍDA.

Eu lutei com meus colegas sobre isso muitas vezes. SEMPRE há mais um ajuste, outra coisa que "deveria" ser feita para que estivesse "certa". Você sempre pode encontrar isso. Em algum momento, no mundo real, o suficiente é suficiente. Nenhum software de remessa do mundo real é perfeito. Nenhum. Na melhor das hipóteses, é bom o suficiente.


9
Ou talvez, se for usado, duro, por décadas, provavelmente acabará parecendo uma bagunça. Se não for usado (de maneira alguma ou por muito tempo), não terá chance de acumular nenhum lixo.
inútil

7
"Qualquer pessoa que esteja neste ramo há algum tempo provavelmente concordaria que seria possível mexer com um pedaço de software mais ou menos indefinidamente". Seria possível, mas por que fazê-lo? Depois de definir seu padrão de qualidade, você o projeta, implementa, testa, corrige bugs, testa novamente e depois não toca mais. Demora mais do que apenas invadi-lo, mas depois de atingir seu objetivo (a funcionalidade necessária é implementada e testada), é bastante claro que você não deve mais mexer no código. Apenas meus 2 centavos.
Giorgio

7
+1 - no mundo real sempre haverá uma troca entre a qualidade do código e o cumprimento dos prazos. Eu preferiria ter um programador que possa produzir código razoável rapidamente do que um perfeccionista que passa meses angustiado se deveria chamar um método de "serializar" ou "writeToFile".
James Anderson

3
você disse isso. Trabalhei em uma organização na qual, na sala ao lado, havia uma equipe que trabalhava nos requisitos funcionais de um novo sistema nos últimos 5 anos, nunca uma linha de código foi escrita para ele. Muitos codificadores são os mesmos (especialmente os juniores, recém-saídos da faculdade com grandes idéias sobre o código ter que ser bonito e atender a "padrões" específicos, caso contrário é ruim) e, a menos que parem, mexeriam sem parar em algo que estava perfeitamente funcional meses atrás (eu às vezes ainda temos essa tendência, acho que todos temos). Mas no final, o que importa é tirá-lo da porta.
Jwenting

6
@Giorgio: Não concordo com a sua "superstição" de que um trabalho de qualidade leva mais tempo do que apenas cortá-lo. Isso pode ser verdade se você equiparar programação com digitação. Considerando todo o ciclo de vida do software, as coisas ficam muito mais suaves e, portanto, mais rápidas se você se preocupa com a qualidade.
ThomasX

85

Tais programadores quase nunca sabem que acertaram, apenas acreditam nisso . E a diferença pode não ser fácil de perceber.

Lembro-me de como costumava programar antes de aprender sobre o teste de unidade. E lembro-me daquele sentimento de confiança em um nível totalmente diferente depois de executar meu primeiro conjunto decente de testes de unidade. Eu não sabia que esse nível de confiança no meu código existia antes.

Para quem não tem essa experiência, é impossível explicar a diferença. Assim, eles podem continuar desenvolvendo-se no modo de codificar e orar por toda a vida, benevolente (e ignorantemente) acreditando que estão fazendo o melhor possível, considerando as circunstâncias.

Dito isto, de fato pode haver grandes programadores e casos excepcionais, quando alguém realmente consegue manter todo o espaço do problema em sua mente, em um estado completo de fluxo. Eu experimentei momentos raros como este, quando eu sabia perfeitamente o que escrever, o código simplesmente saiu de mim sem esforço, eu podia prever todos os casos especiais e condições de contorno, e o código resultante simplesmente funcionou . Não tenho dúvida de que existem gênios de programação por aí que podem permanecer nesse estado de fluxo por longos períodos ou até a maior parte do tempo, e o que eles produzem é um código bonito, aparentemente sem esforço. Acho que essas pessoas podem não ter necessidade de escrever testes de unidade insignificantes para verificar o que já sabem. E se você é realmente um gênio, pode ser bom (embora, mesmo assim, você não esteja presente nesse projeto para sempre e pense em seus sucessores ...). Mas se não ...

E vamos ser sinceros, é provável que você não esteja. Eu, por mim, sei que não sou. Eu tive alguns raros momentos de fluxo - e inúmeras horas de tristeza 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, portanto desenvolveram conscientemente o hábito de checar suas suposições e escrever esses pequenos testes de unidade, para se manterem seguros. ( "Eu não sou um grande programador - apenas um bom programador com bons hábitos." - Kent Beck.)


8
"benevolentemente (e ignorantemente) acreditando que estão fazendo o melhor possível, considerando as circunstâncias". Resumo perfeito do problema. O número 1 correu por causa de restrições e fez o melhor que pôde. O segundo lugar aparece e herdou o caos, além de novos prazos e também faz o melhor que pode. Todo o caminho até a 20a pobre alma que não poderia fazer o seu melhor se tivesse anos para desfazer o dano. É por isso que pratico a regra dos escoteiros: "deixe-a mais limpa do que você a encontrou". Dê a essa próxima seiva uma chance de lutar - pode ser você.
13131 Steve Jackson

1
Engraçado, sinto o contrário desde que comecei a testar o meu código (no trabalho). É como ficar com preguiça; não há nenhuma razão para realmente entender seu código, pois outro código trará erros para você
Izkata

8
Você escreve testes de unidade em parte para provar que seu próprio código funciona. Mais importante, você escreve testes de unidade para que outros desenvolvedores possam alterar seu código com confiança.
Stephen Gross

4
Donald Knuth: "Cuidado com os bugs no código acima; eu apenas provei que estava correto, não tentei". haacked.com/archive/2007/11/29/…
MarkJ

1
@ Izkata - se você não entende o que está fazendo, os testes de unidade provavelmente estão quebrados e validando que o código tem os mesmos erros que os testes. Além disso, mesmo com 100% de cobertura de decisão e testes de unidade precisos, é possível (embora incomum) ter um bug que o teste não revela.
perfil completo de Steve314

33

Testes unitários . É a única maneira de confiar em qualquer código (sujo ou não).

Em uma nota lateral;

atalhos geram longos atrasos (Pippin)


6
Boa citação, mas não era Gandalf. Foi Pippin, argumentando por que ele, Frodo e Sam não deveriam atravessar o país até o ferry Buckleberry, logo na jornada inicial de Hobbiton.
Daniel Roseman

22
Correção: "Testes de unidade. É a única maneira de ter uma falsa sensação de segurança no código (sujo ou não)". É bom ter testes de unidade, mas eles não garantem nada.
Coder

8
Quando quero descobrir erros ocultos, mostro o aplicativo ao meu chefe. Eu chamo isso de teste do chefe, deve ser feito após o teste de unidade. Ele tem uma aura de magnetismo que atrai todos os tipos de bugs estranhos, além de raios cósmicos diretamente nos registros da CPU.
Mister Smith

8
Enquanto citamos, você também pode gostar de "O teste mostra a presença, não a ausência de bugs" - Edsger Dijkstra
Timothy Jones

2
Os testes -1 não provam que o código está confuso - os testes de unidade não PROVAM nada, eles oferecem uma certa confiança, mas não valem nada além disso. Eles são uma boa medida, apenas não assuma que eles significam mais do que uma pequena subseção de código funciona exatamente como você o escreveu, não diz que você escreveu corretamente ou que irá interagir corretamente com qualquer outra coisa. Embora eles geralmente sejam uma boa medida, mas não ajudam no código de baixa qualidade e, na verdade, pioram, fornecendo mais código para alterar com cada refatorador.
Bill K

15

É 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. Algum grau de caos e vulnerabilidade ao inesperado sempre espreita dentro do código. Isso não significa que não se deva tentar produzir um bom código ou realizar testes de unidade. 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 é a compreensão de qual nível de 'perfeição' precisa ser usado para um projeto específico. Por exemplo, se você estiver escrevendo um aplicativo de registros médicos eletrônicos com um cronograma de projeto de 12 meses, dedicará muito mais tempo aos testes e garantirá a manutenção do seu código do que faria em um aplicativo Web de registro de conferência único 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 ajustando o código.


1
+1 por apontar que as decisões sobre medidas de qualidade devem ser justificadas pelas necessidades da empresa.
Stephen Gross

+1 para * "A habilidade a ser desenvolvida é a compreensão de qual nível de 'perfeição' precisa ser usado para um projeto em particular." ... Defina um padrão mínimo para a quantidade de "ajustes" que sua empresa considera aceitável risco em termos de qualidade e cumpri-lo.
S.Robins

11

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 seu código feio, rápido e sujo faz a coisa certa, pode ser perfeitamente adequado.

Por exemplo, talvez você tenha algum truque hediondo de expressões regulares e desvios de bytes para analisar alguns arquivos provenientes de terceiros. E suponha que você tenha um teste dizendo que o resultado obtido da análise de arquivos de exemplo é o que você espera. Você poderia limpar isso para poder ... Não sei, reagir mais rapidamente quando um terceiro alterar um formato de arquivo? Isso simplesmente não acontece com frequência suficiente. O mais provável é que eles mudem para uma API completamente nova e você jogará fora o analisador antigo e conectará um novo que esteja em conformidade com a mesma API e pronto, pronto.

Onde a rapidez e a sujeira se tornam um problema é quando sua arquitetura é 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 precisar pagar o preço.


1
Por outras palavras - os módulos podem ser de pesquisa e desenvolvimento, mas a arquitetura deve estar adequadamente limpa.
Kromster

9

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

Conheço uma pessoa que considera testes de unidade uma perda de tempo. Depois de muita discussão, ele finalmente escreveu uma. Consistia em um método longo polvilhado com && e || e retornou um booleano para assertTrue. A declaração abrange 20 linhas. Por outro lado, ele escreveu uma classe em que todo método tinha uma linha e o principal tinha mais de 1000 linhas sem espaços em branco. Era uma parede de texto. Quando revi seu código e inseri algumas novas linhas, 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!"

A última vez que conversei com ele, ele codificou um site para uma empresa. Ele estava tentando encontrar um bug. Ele passou os últimos 3 dias fazendo isso durante 8 horas por dia. Um pouco mais tarde, falei com ele novamente, e seu companheiro de equipe mudou o valor de um literal e não o atualizou em nenhum outro lugar. 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, nem todos sabemos como é ficar acordado a noite toda com o depurador, sem dormir por causa de um bug desagradável "Ele acha que isso é algo realmente bom que os programadores fazem e realmente se sente bem com isso.

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


Aqui está um pouco mais.

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


1
+1. Por alguma razão, adoro ler essas histórias. Eles nem me deixam mais triste ou com raiva.
Sam Hocevar

-1 para escrever qualquer tipo de classe _______Manager.
Brian Driscoll

@SamHocevar Executar, não andar, para thedailywtf.com
MAWG

7

Minha lição para evitar sujeira e rapidez foi quando eu tinha seis meses para entregar o que era estimado (subestimado) como um ano de trabalho. 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.

Obtivemos grandes ganhos ao identificar funcionalidades comuns e construir as bibliotecas necessárias para lidar com esses requisitos. Ainda vejo codificadores escrevendo seu próprio código quando há rotinas de bibliotecas disponíveis. Esses codificadores geralmente reescrevem ou, na melhor das hipóteses, recortam e colam o mesmo código quando precisam resolver o mesmo problema posteriormente. As correções de erros invariavelmente capturam apenas algumas cópias do código.

Um desenvolvedor deu uma resposta reveladora 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".


1
Um desenvolvedor ético você chegou lá!
Stephen Gross

6

Em alguns casos, acho que pode haver um grande conjunto de testes de regressão que encontrará "todos" erros e verificará o comportamento, permitindo assim uma técnica de codificação rápida e suja. Mas, principalmente, é apenas uma questão de planejamento ruim do projeto e um gerente que acha mais importante fazê-lo do que fazê-lo corretamente.

E esqueça "limpe depois", isso nunca acontece. Nos raros casos em que isso acontece, 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.


6

O produto é enviado.

O código não existe no vácuo. Sofri incontáveis ​​lutas contra as conseqüências da codificação rápida, suja e de caubói. Mas, às vezes, terminar o produto é a prioridade, não descobrir como escrever o melhor código. Por fim, se o produto for enviado e funcionar bem o suficiente, os usuários e clientes não saberão nem se importarão com o quão "ruim" é o código, e admitirei que houve momentos em que não me importei em "obtê-lo". certo "desde que eu o peguei pela porta.

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


5

Eu não acho que eles possam dizer honestamente que acertaram se não for fácil de manter. Se eles admitirem que precisam "limpá-lo mais tarde", provavelmente haverá algo que não tenham pensado o suficiente. Testá-lo completamente só descobrirá verdadeiramente quaisquer problemas com o código sujo.

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


5

Como eles sabem que acertaram? Testar é a resposta simples.

Se o código deles tiver sido testado exaustivamente 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 deva 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 fazê-lo corretamente. No mundo dos negócios, às vezes 20 minutos é tudo o que está disponível para fazer o trabalho e, quando você enfrenta prazos rápidos e sujos, pode ser a única opção.

Eu já estive nos dois extremos disso, tive que corrigir o código sujo e tive que escrever o meu para contornar as limitações de um sistema em que estava desenvolvendo. Diria que confiava no código que escrevi porque, embora estivesse sujo e um pouco hackeado, às vezes eu tinha certeza de que foi completamente testado e que havia um monte de manipulação de erros, por isso, se algo desse errado, não destruiria o resto do sistema.

Quando olhamos para esses programadores rápidos e sujos, precisamos lembrar de uma coisa: um cliente geralmente não paga até ter o produto, se ele for enviado e eles forem para o teste UAT e encontrarem os bugs do código rápido e sujo. muito menos provável que eles se soltem quando tiverem um produto quase funcionando na frente deles, mas se eles não tiverem nada e você estiver dizendo a eles "você o terá em breve, estamos apenas consertando x" ou "foi adiado porque tivemos que obter y funcionando perfeitamente ", é mais provável que desista e vá com um concorrente.

Obviamente, como esta imagem demonstra, ninguém deve subestimar o perigo de código rápido e sujo! insira a descrição da imagem aqui


4

Acho que você nem deveria começar a seguir esse caminho. Rápido e sujo pode dar a você o benefício temporal de terminar mais rapidamente, mas você sempre paga dez vezes mais por fazer isso no final.


5
Às vezes, você não terá dinheiro se não enviar agora ... mas o envio agora permite que você pague "dez vezes" para limpá-lo, e depois alguns porque você venceu seus concorrentes no mercado e conseguiu reconhecimento da marca primeiro.
CaffGeek

2
Eu peço desculpa mas não concordo. Se o dinheiro já estiver apertado, você gasta a renda no próximo produto e continua fazendo isso até que sua empresa morra ou fique grande o suficiente. Neste último caso e, provavelmente, os desenvolvedores originais não estarão mais lá para corrigir o código antigo.
Raku

Colocar outros no mercado não é garantia de que o público aceitará seu produto. Se um produto contiver muitas falhas, é melhor esperar que você tenha o dinheiro extra para aplicar um bom marketing de fumaça e espelhamento e tenha um relacionamento brilhante e perdoador com sua base de clientes. Esta não é uma posição ou / ou. A chave é equilibrar risco versus recompensa e liberar o produto da mais alta qualidade que você pode fornecer em tempo hábil. Suas habilidades serão julgadas pela qualidade do produto lançado e o dano que um software defeituoso pode causar à sua imagem pode ser irreparável.
31711

1
Implore para diferir como quiser, mas a história está cheia de exemplos em que estar lá no momento certo, disponível para quem quisesse, era mais importante do que ser o melhor produto possível. Sempre há um custo de oportunidade, sempre sempre.
Warren P

1
Warren, era basicamente o que eu estava dizendo. A meu ver, o custo de oportunidade de recuperar o código para manutenção aumenta, exponencialmente, quanto mais você o atrasa. Se sua empresa está em uma posição em que pode sobreviver ao desastre de insustentabilidade, porque as vendas foram bem e o código não estava muito sujo, bom, mas e se não?
Raku

4

Na minha opinião, aprender a julgar o código de Q&D pela correção não é uma habilidade que vale a pena desenvolver, porque é apenas uma má prática. Aqui está o porquê:

Eu não acho que "rápido e sujo" e "melhores práticas" 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 o resultado da fluência do escopo combinada com um prazo cada vez mais próximo. Eu sabia que o código que estava verificando era sugado, mas cuspia as saídas adequadas, dado um conjunto de entradas. Muito importante para as partes interessadas, enviamos a tempo.

Uma olhada no CHAOS Report original deixa bem claro que Q&D não é uma boa ideia e reduzirá o orçamento mais tarde (em manutenção ou durante a expansão). Aprender a julgar se o código de Q&D está correto é uma perda de tempo. Como Peter Drucker disse: "Não há nada tão inútil quanto fazer com eficiência aquilo que não deve ser feito".


3

Não sei dizer se meu novo código está correto se estiver muito sujo.

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

O código sujo é frágil - você pode testá-lo e saber que funciona agora , mas é uma aposta muito boa que ele quebre em algum momento no futuro (ou então force todos a andar com casca de ovo por medo de quebrá-lo).


3

Correndo o risco de parecer um pouco polêmico, eu argumentaria que ninguém SABE realmente que seu código é 100% correto e 100% sem erros. Mesmo quando você tem uma cobertura de teste realmente boa e aplica rigorosamente boas práticas de BDD / TDD, ainda é possível desenvolver código que contém erros e sim que podem até conter efeitos colaterais!

Escrever um código e supor que ele funcione implica em excesso de confiança por parte do senso do desenvolvedor sobre as próprias habilidades do desenvolvedor e que, quando surgirem problemas (o que inevitavelmente o farão), o esforço para depurar e manter o código será caro, especialmente se outro desenvolvedor precisar para manter o código posteriormente. A diferença real é feita aplicando boas práticas de engenharia de software, que garantem que você possa ter confiança real de que seu código provavelmente funcionará a maior parte do tempo e que, se encontrar um erro, é mais provável que seja mais fácil depurar e muito menos dispendioso para alterar e manter, independentemente da pessoa que trabalha nesse código posteriormente.

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


2

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


2

Bons programadores (Rápido e Sujo ou não) não têm a arrogância de assumir que estão certos. Eles assumem que todos os grandes sistemas têm bugs e falhas, mas que em algum momento podem ser testados e revisados ​​o suficiente para ter um risco suficientemente baixo ou um custo de falha suficientemente baixo que o código possa fornecer.

Então, por que esses programadores, chamados de Quick & Dirty, existem? Minha hipótese é a seleção darwiniana. Os programadores que enviam códigos viáveis ​​rapidamente, ocasionalmente enviam antes que a competição seja lançada, ou o orçamento acabe, ou a empresa vá à falência. Portanto, suas empresas ainda estão no negócio, empregando novos programadores para reclamar da bagunça que precisa ser limpa. Os chamados códigos limpos também são fornecidos, mas não diferentemente o suficiente para levar os codificadores Quick & Dirty à extinção.


Isso é verdade. Eu vi pelo menos um produto que foi capaz de enviar devido ao código Quick & Dirty, warts e tudo. Aconteceu que alguns dias contra um mês adiantado significou um salto de dois meses na competição. O produto passou a ser um sucesso e o código Quick & Dirty acabou sendo substituído por um código melhor. Desde que tento fazer um trabalho melhor, visualizando a qualidade do meu código, não apenas do ponto de vista da engenharia, mas também do ponto de vista comercial / competitivo. Nota: a interface do referido código era boa, era a implementação que era superficial.
J Trana

0

Provavelmente, pode-se pensar que uma parte não ideal de um código não faria diferença, devido à curta vida útil, pouco impacto nos negócios ou pouco tempo para fazê-lo. A resposta correta é que você realmente não sabe. Toda vez que ouço alguém dizendo que "esse é um recurso pequeno" ou "vamos torná-lo o mais rápido e simples possível" e gasto tempo insuficiente pensando no design certo, as duas únicas coisas que realmente ocorrem estão:

1-) O projeto aumenta e a motivação da equipe diminui, trabalhando no código cheio de "pontos". Nesse caso, o projeto provavelmente passará rapidamente para o caos.

2-) O projeto se torna conhecido como uma solução não ótima e seu uso começa a ser desencorajado, em favor de uma nova solução ou de 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 tiver tempo suficiente, explique por que precisa de mais. Não se arrisque com trabalhos mal feitos. Seja sempre um profissional melhor. Ninguém pode puni-lo por isso, se você for razoável. Se o fizerem, não é onde você deveria trabalhar.


0

Discuta com o idoso e avalie o impacto das falhas, se houver. Por exemplo, uma situação em que você pode corrigir problemas leva 1 dia e um código robusto requer alterações de design e arquitetura, que podem levar de 4 a 6 meses + tempo de validação adicional para validar completamente todos os fluxos de trabalho que foram impactados com a alteração de design.

Temos que tomar uma decisão com base no Tempo + Capacidade + Prioridades na lista também. Uma boa discussão na equipe com idosos ou pessoas com maior experiência pode ajudar a chegar a uma decisão que melhor se adapta à equipe e à sua entrega.

O código limpo é a primeira e principal abordagem em que, como código sujo, para salvar as escalações, decisões de aprovação / não aprovação dos clientes, exibição de rolhas, reputação da organização em jogo e muito mais, onde o código sujo entra no código limpo.


4
este não parece oferecer nada substancial sobre os pontos feitos e explicado em antes 23 respostas
mosquito
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.