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.