Como você lida com o código feio que você escreveu? [fechadas]

88

Assim, o seu cliente pede que você escreva algum código, então você faz. Ele então muda as especificações de você, como esperado, e você implementa diligentemente seus novos recursos como um bom rapazinho. Exceto ... os novos recursos entram em conflito com os recursos antigos, então agora seu código está uma bagunça. Você realmente quer voltar e consertar, mas ele continua pedindo coisas novas e toda vez que você termina de limpar alguma coisa, acaba tudo de novo.

O que você faz? Pare de ser um maníaco pelo TOC e aceite que o seu código vai acabar bagunçado, não importa o que você faça, e apenas continue com os recursos dessa monstruosidade? Salvar a limpeza para a versão 2?

    
por Mark 27.11.2010 / 08:29
fonte

17 respostas

41

Arranje outro emprego e deixe outras pessoas lidarem com isso. Muahahahhahahaa

.....

Apenas brincando. :)

Mas com toda a seriedade: preenchimento de estimativas é seu amigo. Eu geralmente faço uma estimativa realista decente, depois do dobro. Isso pode parecer excessivo, e às vezes é, mas é melhor superestimar um pouco e até parecer um pouco lento às vezes - do que deixar impressões ruins criando código com bugs e sempre extrapolando suas estimativas. E, claro, você incorrerá em débito técnico ao permitir que o codebase seja hacky.

Outra dica (relacionada): Sempre calcule tarefas aparentemente minúsculas, sem problemas para um bloco de tamanho decente. Digamos, por exemplo - um item que você tem quase certeza que será apenas uma linha simples de 30 segundos - dê 1 hora (ou talvez o menor bloco de tempo no seu quadro de horários ou sistema CR, por exemplo 15 minutos / 0.25 horas) . E dê blocos de meio dia ou de um dia para os itens um pouco maiores, mas ainda relativamente triviais.

A razão para isso é principalmente psicológica: eu acho que se você adquirir o hábito de hackear rapidamente pequenas mudanças, o trabalho se apressa, e você nunca acaba se sentando, fazendo um balanço e refatorando coisas que precisam ser feitas. refatorado. Além disso, em um nível prático: pequenas, mas não triviais, as mudanças às vezes se apagam, e você não quer estar constantemente sentindo que está atrasado e apagando os incêndios de bug. É parte e parcela do motivo pelo qual as bases de código são hackeadas ao longo do tempo.

Por fim, lembre-se sempre de que as pessoas não precisam saber que você está preenchendo suas estimativas. Contanto que você seja um desenvolvedor competente e esteja trabalhando em um ritmo decente, esse preenchimento não será perceptível. ou seja, não diga ao PHB "Minha estimativa inicial é que levará duas horas, mas me dê meio dia". Diga a ele: "Acho que levará cerca de meio dia". e deixa lá.

    
por 26.11.2010 / 01:26
fonte
66

Suprima deliberadamente o tempo necessário para seus próximos recursos. Use esse tempo extra para limpar.

Você nunca será capaz de justificar a manutenção, e o cliente precisa disso independentemente, então dê a eles o remédio amargo (um pouco mais para os próximos recursos) para que eles possam melhorar.

    
por 26.11.2010 / 01:03
fonte
11

Tente fazer uma reformulação adequada ao integrar novos recursos. Não há mais tarde. Sem o novo design, você está constantemente adicionando mais e mais atrito para novas alterações e novos recursos.

Em algum momento você chegará a um ponto de parada onde tudo parece levar séculos. A maioria das empresas provavelmente vai para a grande reescrita neste ponto, a versão 2. Ela tem uma economia muito ruim e é um bom momento para o seu cliente tentar uma festa de desenvolvimento diferente se eles se sentirem inclinados.

Redesenho / refatoração adequadas podem proteger o investimento de seus clientes e manter as coisas sustentáveis. Você precisa construir isso. Otimize a mudança, leve a viagem.

    
por 26.11.2010 / 00:01
fonte
6

Com todos os comentários sobre a superestimativa, acho que há uma quantidade modesta de pontos (oportunidade boa) perdidos.

Não se trata de estimar o tempo gasto fazer a mudança (apenas) e, em seguida, adicionar alguns, é sobre a estimativa do tempo necessário para modificar o código (refatorar!) para trazê-lo a um ponto onde a mudança pode ser feita com segurança e então faça a mudança (provavelmente um pouco juntos). Ok, isso equivale à mesma coisa ... mas não há dúvida de falsificação ou alongamento ou superestimativa, é simplesmente uma questão de dizer que, para fazer isso, eu primeiro preciso fazer isso e isso é quanto tempo levará no total. A chave aqui é que você trabalha naquelas partes do sistema das quais a mudança é dependente e não mais - se houver um código horrível em outro lugar ... difícil, pegue quando você estiver lá.

Para voltar à questão original um pouco - depois de muitos anos, isso se resume a isso para mim, quando você implementa algo a menos que você conheça (não acredita, não espera (suspeito?) , não pense, mas saiba ) que coisas adicionais também são necessárias, então você deve fazer o que precisa para implementar essa exigência e não mais de forma tão arrumada e elegante quanto possível.

Quando você chega para implementar a próxima coisa - algum tempo depois - você toma as medidas necessárias para trazer a base de código (e o banco de dados e o que for) ao estado necessário para implementar essa funcionalidade de forma tão elegante e elegante quanto você posso. Essa refatoração é onde você lida com a confusão que surge naturalmente à medida que um projeto evolui - e esperamos evitar criar mais confusão (ou pelo menos manter o nível consistente).

Uma das áreas de discussão aqui é "Dívida Técnica" - é como um cheque especial, você tem que pagar de volta e quanto mais você deixar, mais juros (neste caso, o tempo necessário para corrigir) você acumulará - o que dá você é um bom argumento para gastar parte do seu tempo minimizando a dívida técnica.

Este é também o local onde testes de unidade e outros testes automatizados começam a aparecer (se eu pudesse fazer tão bem quanto eu digo que tenho certeza de que seria uma pessoa mais feliz!) combinados com um servidor de compilação adequado pelo menos alguns de seus testes). Combinados com aqueles - mas de valor em si - são padrões como injeção de dependência e inversão de controle (nunca muito certo quanto os "mesmos" são dois) porque eles facilitam a mudança do encanamento e, portanto, lidam com mudanças isolamento.

Finalmente, lembre-se, se não estiver quebrado, não conserte. Arrumar seu código puramente por uma questão de arrumar ele pode ser satisfatório, mas também é uma oportunidade para introduzir erros, embora possa ser doloroso se você não precisar alterá-lo e não estiver construindo sobre ele. pode ser melhor deixar alguns pedaços sozinho - a oportunidade de consertar ou substituir irá rolar eventualmente!

    
por 26.11.2010 / 10:06
fonte
4

1) O controle adequado de alterações é seu amigo

Se o cliente alterar a especificação, tudo bem, é um direito seu, no entanto, é uma alteração e precisa ser cobrado (ou custeado de qualquer maneira que seja apropriado à estrutura / relação do projeto).

A estimativa para essa mudança deve incluir o custo da refatoração necessária . O cliente pode resistir ao que parece ser um custo alto, mas nesse ponto você precisa explicar a ele que, como o código já está parcialmente escrito, há elementos que precisam ser reescritos para garantir que ele seja robusto e suportável no futuro. se não for feito, é provável que ele tenha problemas no futuro com suporte futuro ou mudanças se tornando ainda mais caras.

2) A refatoração deve ser feita de modo a proporcionar um benefício genuíno de longo prazo ao cliente

Ao considerar a refatoração, você sempre precisará considerar o que é realmente necessário e o que é importante e garantir que o trabalho de refatoração forneça um valor genuíno de longo prazo para o dinheiro.

Afinal de contas, devemos fazer essas coisas para que o código permaneça extensível e suportável a médio / longo prazo para garantir que o investimento do cliente permaneça válido, e não fora de qualquer impulso, para a perfeição teórica. O trabalho de refatoração (e as estimativas correspondentes) deve ser feito com isso como o escopo, e não apenas porque agora você acha que pode haver uma maneira um pouco melhor de fazê-lo.

    
por 26.11.2010 / 11:26
fonte
3

Alguns programadores sugerem que uma maneira de controlar esse problema com clientes é fazer com que o cliente assine e autorize a especificação inicial. ENTÃO, quando solicitam uma alteração de requisito que não esteja na especificação inicial, você diz que precisa passar pelo contrato e pelo cronograma do projeto para calcular os custos adicionais e os atrasos de tempo e, em seguida, anexar ao contrato. Aparentemente, faz maravilhas ao impedir que os clientes insistam em novos recursos (sem previsão).

    
por 26.11.2010 / 00:06
fonte
3

Eu tenho o seguinte comentário em uma base de código em que estou trabalhando atualmente:

/*
 * Every time I see this function, I want to take a shower.
 */

Eu sei muito bem a situação que você está descrevendo. O que eu faço é tentar (meu melhor) esperar até que as coisas se acalmem e qualquer tipo de 'rastejamento' tenha 'rastejado' tudo o que vai fazer. A essa altura, você provavelmente tem algo útil liberado, e você pode levar algum tempo para limpar as coisas e implementar coisas um pouco diferentes.

Você não pode correr limpando muitas pequenas bagunças repetidamente. Isso apenas triplica seu trabalho e sua frustração. Espere que se torne uma bagunça maior, mas dificilmente em movimento, e então você pode fazer algo sobre isso.

    
por 26.11.2010 / 07:57
fonte
2

Minha preferência é evitar essa situação em primeiro lugar.

Tudo depende de como você leu a especificação. É fácil pensar neles como tabletes de pedra, mas na realidade a maioria das especificações muda. Ao projetar seu código, veja como é provável que cada parte da especificação seja alterada. Com o tempo, você ficará muito bom em prever isso.

Tendo entrado na bagunça, a experiência e o julgamento são muito importantes. Você está escrevendo novos bugs por causa desse código espaguete? está demorando mais para implementar? estes apontariam para fazer um refator tático.

para o futuro, parece que você precisa trabalhar em parceria com seu cliente. Dizendo a eles: "Veja que este produto está expandindo significativamente além das especificações originais. Embora o design original tenha sido bom para esse nível, expandi-lo na direção X e direções Y precisam de alguma reestruturação no design". cliente para pagar por isso.

    
por 25.11.2010 / 23:59
fonte
2

Carregue por hora e se ele quiser mudanças, diga que está tudo bem, mas incorpore o tempo necessário para escrever um bom código na equação. Lembre-se também de que escrever código mais limpo compensa a longo prazo quando você precisa mantê-lo. Economizar tempo agora pode custar mais tarde.

    
por 26.11.2010 / 00:05
fonte
1

Acho que o software de escrita precisa andar de mãos dadas com as necessidades de negócios. Se é um projeto descartável (como um protótipo que precisa ser construído em uma semana, com novas entradas chegando todos os dias), então não há necessidade de se preocupar com manutenção de código e outras coisas - o tempo é crucial e você só precisa empurre seu código para fora da porta o mais rápido que puder.

Mas se você está escrevendo um aplicativo de longo prazo, faz sentido considerar tudo isso, porque há um impacto considerável no tempo necessário para criar novos recursos, corrigir erros existentes, integrar-se a outros aplicativos e outros coisas - e isso se traduz em impacto nos negócios (por causa do tempo necessário mais tarde e mais custo).

Portanto, é melhor sensibilizar o tomador de decisão para os custos reais de não refatorar o código sempre que necessário - na minha experiência, se os custos e o impacto temporal de ambas as opções forem explicados em termos mensuráveis ao proprietário da decisão, então a decisão pode ser um acéfalo. Não espere que as pessoas lhe digam 'sim, vá em frente, escreva um código bonito, mesmo que demore o dobro do tempo e não me dê nenhum benefício extra'. Isso simplesmente não funciona dessa maneira.

    
por 27.11.2010 / 08:48
fonte
1

Faça parte do seu processo, eu chamo de "refatoração extrema" e vai ser grande! ;) Basta fazer coisas rapidamente e quando novos recursos suficientes foram adicionados que há cicatrizes, refatoração. Continuamente pergunte a si mesmo "Agora, se eu tivesse começado do zero, como eu teria feito isso"

As pessoas que pensam que podem projetar e pensar sobre tudo na frente é principalmente se enganando, você (e seu cliente) sempre aprendem as coisas conforme você progride. Use essas lições.

Como você é um bom programador, você poderá refatorar rapidamente e, à medida que o fizer, o código começará a usar a "forma adequada", o que significa que se tornará mais flexível com menos dependências.

Os clientes podem ser ofendidos se soubessem que você estava "perdendo tempo" retrabalhando coisas, por isso não ajuda perguntar / contar e ser realmente rápido com relação a isso.

O código desenvolvido dessa maneira economizará bastante tempo no final e tornará cada vez mais fácil adicionar novos recursos.

Eu também diria que uma das maiores razões para o código ruim é o medo que alguns programadores têm de fazer uma refatoração estrutural maior, e quanto mais você espera, pior fica.

    
por 06.01.2011 / 07:29
fonte
1

Confie em um poder superior

Eu não quero dizer orando. Quer dizer, certifique-se de que existe um executivo (ie gerente de projeto ou equivalente) que você possa colocar como preenchimento entre você e o cliente. Se o cliente está exigindo demais, deixe o executivo colocar o pé no chão e estar pronto para empunhar o "é capaz de fazer, mas não tenho certeza se isso se encaixa no escopo da especificação, veja [business guy]". / p>

Em um fluxo de projeto normal, a especificação geral deve ser congelada antes que ocorra um desenvolvimento sério.

Muitos clientes continuarão a impulsionar alterações / aprimoramentos / melhorias, desde que você os permita. Muitos abusarão dessa capacidade ao máximo, porque isso faz com que eles sintam que estão obtendo o máximo de seu dinheiro (mesmo sabotando seu projeto).

Tenha uma pessoa dedicada a aperfeiçoar e congelar a especificação antecipadamente e aplicá-la posteriormente.

Não há nada de errado em fazer um pouco mais de um bom karma com o cliente, mas esteja pronto para adotar um poder maior quando ele ficar fora de controle. Se a especificação exigir uma quantidade ridícula de mudanças, talvez seja hora de voltar ao ciclo de negócios e reavaliar o contrato e / ou adicionar adições ao contrato (com compensação monetária justa).

O fato de você ter esse problema tem pouco a ver com o código. É um sinal de que seu gerente de projeto está subutilizado no projeto (seja sua culpa, sua falha ou ambos).

Como outros disseram em muitas respostas, adicionar um buffer de tempo para contingências também é necessário em qualquer projeto, mas determinar que deve ser decidido a portas fechadas antes que a especificação seja congelada e entregue ao cliente pelo PM.

    
por 14.01.2011 / 06:47
fonte
0

O design inicial adequado não pode ajudar a evitar o problema. E é quase impossível (ou muito difícil) considerar todos os futuros requisitos "talvez". Então, depois de algum tempo, o Big Re-factoring chegará. E a melhor solução é reescrever tudo.

Em poucas palavras: em vez de colocar uma torre na Ferrari vermelha, reconsidere os requisitos e construa um tanque.

    
por 26.11.2010 / 10:11
fonte
0

Mate-o com fogo.

Aka refatorar o mais rápido possível: por exemplo, quando o código feio vem correndo para um prazo, eu refatoraria após o prazo porque você não pode (ou não deveria pelo menos) adicionar mais recursos até que o código existente seja sustentável, caso contrário, será muito mais difícil depurar códigos futuros.

    
por 06.01.2011 / 07:37
fonte
0

Escreva testes unitários para seus projetos que testam o estado atual e depois refatore quando tiver tempo, dessa forma você evita quebrar seu projeto enquanto está tentando limpá-lo.

    
por 06.01.2011 / 14:19
fonte
0

Resposta mais simples. Eu pararia de codificar de qualquer tipo, até que ele tenha uma especificação final para exatamente o que ele deseja a partir de agora.

Em seguida, eles precisam priorizar essa lista de recursos, etc., para confirmar quais itens devem ter agora e quais podem ser feitos mais tarde ...

Usando suas experiências para determinar o tempo / custo de cada recurso e, em seguida, informando a eles, se eles quiserem, isso levará x quantidade de tempo & dinheiro.

Você está lidando com o grande crime de escopo de recursos, e eles vão continuar adicionando infinitos recursos, até que nada seja feito ou seja feito tão mal.

Diga a eles quando tiver uma lista final, que você fará modificações futuras, como preferir, mas precisa se concentrar nos 15/20 mais altos que eles devem ter agora.

Em seguida, com base no tempo até a conclusão, diga a eles que depois que isso for liberado, você estará aberto para discutir / debater a próxima versão.

Após a decisão final sobre o que deve ser feito para a versão atual, todas as discussões / ideias / sugestões devem ser interrompidas em 100%.

Se ele conseguir as idéias sem parar, diga a ele / ela para anotá-las em sua lista de recursos para a próxima versão e deixe que você se concentre em fornecer os recursos mais importantes que deseja no momento.

Se eles continuarem a perder seu tempo, continuem mudando de ideia. Então eu simplesmente pararia de trabalhar no projeto e trabalharia em outros projetos, até que eles tivessem finalizado suas decisões.

É difícil de fazer, mas o escopo do recurso é tão destrutivo de tempo, energia, motivação e pensamento claro.

    
por 03.03.2011 / 15:38
fonte
0

Da perspectiva completa de um projeto:

Aprenda com o código com sua equipe, veja o que pode ser refatorado e reutilizado na próxima vez e depois tome uma cerveja.

De uma perspectiva em desenvolvimento:

Pacientemente, explique por que o desenvolvimento parou e explique por que ele não pode continuar até que todas as especificações estejam na mesa e compreendidas. Então, vá tomar uma cerveja.

De uma perspectiva de planejamento:

Solicite todas as especificações e trabalhe com todos para ter uma compreensão clara do caminho do desenvolvimento. Envolva o cliente / partes interessadas o mais próximo possível para garantir que todos estejam na mesma página. Mais tarde naquela noite, pegue todas as cervejas. Amanhã, comece o projeto.

    
por 03.03.2011 / 15:45
fonte