Atualmente, estou fazendo um estágio em uma grande corporação e eles estão passando por muitas mudanças na estrutura de entrega de software (passando para o Agile).
Nos últimos dois meses, notei esse apego religioso às Clean Codepráticas e o livro como uma Bíblia para os desenvolvedores.
Agora, uma das características mais importantes do código limpo é o código auto-explicativo, que se baseia em nomes compreensíveis e em recálculo rigoroso. Isso é seguido pela no commentingregra.
Entendo que esse código limpo é um investimento de longo prazo que facilitará a manutenção e a melhoria do código, mas ... isso realmente vale a pena?
Alguém compartilharia sua experiência no Clean Code e qualquer opinião sobre se eu sou muito conservador ou se é apenas uma tendência temporária.
fonte
CalculateFoonicityMetric()informa exatamente o que está fazendo, e um código bem escrito mostra como ... mas nenhum deles explica o porquê . O código pode ser óbvio no que (multiplique isso por isso, divida pela outra coisa, acrescente o quadrado, adicione este bit ...), mas não fique claro por que (fator = a * b / c; quadrado para explicar o resultado negativo, ajuste para deriva ...). Agradeço um comentário rápido que explica o porquê.Respostas:
Absolutamente.
Claro, mas considere que a grande empresa provavelmente tem anos ou décadas de código incorreto para limpar. Vai levar muito tempo e esforço para fazer isso.
A principal coisa a perceber é que vocês dois estão certos. "código limpo" é muito importante e o Código Limpo é uma maneira universalmente respeitada de chegar lá. Desde que a empresa acabou de começar o caminho, eles estarão mais devendo ao livro do que um grupo que tem mais experiência. Depois de fazer isso por um tempo, eles começarão a aprender o que funciona e o que não funciona. Depois que entenderem isso melhor, eles (espero) seguirão uma abordagem mais pragmática e natural que mantém o código limpo, mas não leva a 70 nomes de funções de caracteres.
fonte
Eu estava originalmente escrevendo um comentário. Vou tentar dar menos resposta do que perspectivas a considerar. No entanto, eu absolutamente recomendo práticas de "Código Limpo", como nomeação e refatoração compreensíveis.
Eu sempre não gostei das regras de não comentar , pois há casos em que os comentários são necessários para evitar quebras de código futuras. Eles normalmente devem ser restritos ao que está sendo feito e por quê. Use-os com moderação quando o código estiver fazendo algo inesperado ou se for necessário substituir um algoritmo.
Considere a produtividade ao ler ou manter código. Durante a vida útil do código, isso pode ser mais importante que a produtividade ao escrever o código. Essas práticas ajudarão a produtividade nessas tarefas?
Com a experiência, essas práticas devem se tornar arraigadas e menos prejudiciais à produtividade. A escolha do nome correto pode levar mais tempo, pois você está esclarecendo o que o código precisa fazer. (Esse esclarecimento pode tornar a codificação e a depuração mais rápidas.) Isso resulta em código que faz apenas o que é necessário ou tem menos bugs? Que efeito isso tem sobre a produtividade?
O tempo gasto na escolha do nome correto do método provavelmente será recompensado imediatamente, para melhor entender qual é o objetivo do método. Compare os nomes dos métodos "iterateOverCustomers" com "LocateActiveCustomers". Qual transmite a intenção da função? Qual será mais fácil de refatorar, se necessário?
fonte