As práticas de “Código Limpo” são realmente limpas e úteis? [fechadas]

Fechado . Esta questão é baseada em opiniões . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela possa ser respondida com fatos e citações editando esta postagem .

Fechado há 6 anos .

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.

programming-practices agile clean-code

— Arturs Vancans
fonte

Muitas boas perguntas geram algum grau de opinião com base na experiência de especialistas, mas as respostas a essa pergunta tendem a ser quase inteiramente baseadas em opiniões, e não em fatos, referências ou conhecimentos específicos.

— mosquito

Eu não tenho uma opinião muito alta desse livro (apesar do autor). Em geral, vale a pena não ser muito dogmático. A maioria das recomendações de programação é porque eles demonstraram funcionar na prática, mas não são a verdade absoluta; portanto, não se preocupe muito. Continue lendo e siga o que você acha mais correto, mas também não reinvente a roda. As chances são de que alguém mais inteligente do que nós já tenha descoberto soluções melhores que as nossas.

— DPM

Um método com um nome de 70 caracteres provavelmente faz mais de uma coisa. Violação SRP estou certo ?!

— Tombatron

Aqui está outro pensamento: daqui a 5 ou 10 anos, quando você for desenvolvedor de uma empresa que se preocupa menos com código limpo, você realmente apreciará esse exercício dogmático.

— Tombatron

Tendo trabalhado (brevemente) sob "sem comentários", prefiro muito que seja uma orientação forte do que uma regra. Há momentos em que são necessários comentários - geralmente em lógica comercial obscura. Um método chamado 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ê.

— Anaximander

Respostas:

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?

Absolutamente.

A re-fatoração é muito importante, mas gastar 75% do seu tempo movendo os métodos e gastar muito tempo para decidir seu título apropriado não parece ser tão produtivo.

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.

— Telastyn
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?

— BillThor
fonte

Gostaria de salientar que a regra "sem comentários" que as pessoas gostam de atribuir ao livro Código Limpo não está realmente em nenhum lugar do livro. Pelo contrário, há um capítulo inteiro sobre comentários, cuja primeira metade é gasta descrevendo muitos tipos de "bons comentários", seguidos pela seção "maus comentários". As opiniões do autor sobre o assunto são realmente muito mais razoáveis do que muitos lhe dão crédito.

— Eric King

Eu estava comentando as regras "sem comentários" em geral. Eu trabalhei em idiomas nos quais houve propostas para remover comentários da definição de idioma. Nenhum comentário é bom ou ruim. Naquela época, tínhamos um comentário em um bloco de código em que era desejável entrar em detalhes em alguns casos. Houve um comentário avisando que esse era o caso e não adicionar novos blocos de código naquele momento.

— BillThor

Sim, isso parece muito extremo para mim.

— Eric King