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

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.

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

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.

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.

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

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.