Executando verificação de segurança...
2

Porque diabos coisas "Clean" são vendidas como se fosse algo diferente do padrão?

  • Clean Code
  • Clean Arch
  • Clean ...

Parece que hoje em dia tudo que é relacionado a algo "clean" ou algo "ágil" tem alguma conotação de ser melhor. Talvez seja, mas não é algo a ser endeusado.

Acompanhe o raciocionio.

Um bom software pode ser dividido em três coisas:

  • Velocidade de implementar uma nova feature.
  • Velocidade de melhorar a manutenção dessa feature.
  • Velocidade de corrigir um bug sobre essa feature.

Tirando casos muito isolados onde há riscos extremos e você quer ter certeza absoluta de não ter um Therac-25 no seu custo-jurídico, obviamente você vai adotar algo custoso como Testes a base de prova matemática usando linguagens formais como eu explico no meu post.

Ao mesmo tempo não quero deixar meu software com a aparência de abandonado, um abandonware como a serie de servidores GNU/Hurd para o projeto GNU/Mach.

Então adotamos convenções.

Padronizamos tudo, especificamos como tudo deve funcionar e vamos limpando a casa.

A ideia geral é simples, ambiente organizado é menos custoso para desorganizar e quanto mais desorganizado maior é a complexicidade de fazer algo.

É estranho você olhar assim e pensar nossa que genial, quanto menos coisa eu tiver que organizar antes mais coisa eu consigo fazer depois

Não estou no ponto de falar que são coisas boas ou ruins, se foram criadas por uma razão ou se servem apenas para dar pingos nos i.

Só estou falando que o endeusamento dessas práticas acima de qualquer hábito real é estranho, é danoso e é inteiramente vergonhoso.

Seguir uma ideia de You Aren't Gonna Need It é outro caso, precisou chegar alguém e falar que antes de aprimorar você precisa da necessidade de aprimorar.

Novamente, nenhuma crítica além do endeusamento da prática.

Quanto mais você endeusa uma prática que deveria ser um hábito, mais surge a minha dúvida: um dos males do mundo da programação hoje, o Over-Engineering, é resultado de comodismo, dificuldade de racionalizar ou simplesmente falta de pragmatismo no desenvolvimento?

Sim, não estamos mais em 1970, todo mundo tem um biblioteca para TUDO!!! mas você realmente precisa usar? e aquela nova ferramenta da moda? ou aquele banco super-incrível, vou ser um early-adopter no meu projeto.

Medições e Extremos a parte, contando que você sabe o que está fazendo e isso vale a pena, talvez a reconsideração do pensamento deve sobreviver.

Pense num projeto agora, se ele sobreviver a 5 anos / 10 anos não vai ser sobre a mesma stack. Mas sua stack vai passar de 5 ferramentas para 20/30? ou vai chegar na marca de 7/10 ?

Quantas pessoas você precisaria para manter este projeto? Um pessoal gigante com bastante governança? Um pessoal intermediário? Um pequeno grupo? Você sozinho?

Por que?

Só porque você não precisou limpar a casa correndo e já estava tudo pronto para receber visitas de terceiros.

Mais importante, nada limpo significa performático a performance está na capacidade do programador entregar o mesmo tanto constantemente.

Ele pode entregar 20 features e 40 bugs em uma semana, ou 10 features e 2 bugs, corrigindo constantemente 2 bugs a cada 10 features entregues.

Dá para ter um código limpo? legível? performático.

Críticos diriam que não, mas eu diria que depende de onde você quer sujar. Se for só um pouco nas mãos para passar graxa na engrenagem, talvez consiga extrair mais performance em uma abordagem na borda, mantendo o core limpo.

Depende muito da sua decisão. E bem, este longo post foi só um pensamento das 1 AM que eu tive.

Carregando publicação patrocinada...
2

O nome "Clean" é marketing. Ele não é limpo, mas pegou e as pessoas acham que é a última bolacha do pacote.

Podemos dizer que existem hoje dois tipos de programadores: pessoas com experiência real, que raciocinam e entendem o que estão fazendo e conseguem criar boas soluções em cada caso; e as pessoas que seguem modinhas, que confiam em outras pessoas para decidir o que fazer em qualquer projeto que esteja fazendo, e não importa se a pessoa tem 1, 10 ou dezenas de anos de experiência. Quantidade não quer dizer nada, se a pessoa aprende errado ela treinará esse erro por décadas e brigará com quem diga que ela está errada, afinal ela fez a vida toda e milhões de outras pessoas fizeram o mesmo. Mas isso não significa que a pessoa está fazendo certo.

O erro é normal, mas deve servir de apre3ndizado, começando por identificá-lo logo, o que é difícil quando tem a validação de outras pessoas.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

2

afinal ela fez a vida todo e milhões de outras pessoas fizeram o mesmo

Isso e um grande problema ja perdi a conta de quantas vezes peguei pessoas que vieram com este discurso entendo que a experiencia ajuda e sempre bom ouvir, mas nem sempre vale a pena concordar so por que algo funciona nao quer dizer que está correto.

1

Pois eh, tem muito modismo por aí. Mas essas práticas trazem o benefício de uma linguagem comum que muitos podem falar e se entender melhor. Já ouvi dizer que arquitetura, antes de mais nada, é um esforço de comunicação. Então ao menos tem essa justificativa.