Resumo
Como JacquesB escreve, nem todos concordam com o "código limpo" de Robert C. Martin.
Os projetos de código aberto que você descobriu que estão "violando" os princípios que você espera provavelmente terão outros princípios.
Minha perspectiva
Por acaso eu supervisiono várias bases de código que aderem muito aos princípios de Robert C. Martin. No entanto, eu realmente não afirmo que eles são certos , só posso dizer que eles funcionam bem para nós - e que "nós" é na verdade uma combinação de pelo menos
- o escopo e a arquitetura de nossos produtos,
- o mercado-alvo / expectativas do cliente,
- por quanto tempo os produtos são mantidos,
- a metodologia de desenvolvimento que usamos,
- a estrutura organizacional da nossa empresa e
- hábitos, opiniões e experiências passadas de nossos desenvolvedores.
Basicamente, isso se resume a: cada equipe (seja uma empresa, um departamento ou um projeto de código aberto) é única. Eles terão diferentes prioridades e pontos de vista diferentes e, claro, farão diferentes compensações. Essas compensações e o estilo de código que resultam são, em grande parte, uma questão de gosto e não podem ser provadas como "erradas" ou "certas". As equipes só podem dizer "nós fazemos isso porque funciona para nós" ou "devemos mudar isso porque não funciona para nós".
Dito isso, acredito que para poder manter com sucesso codebases grandes ao longo dos anos, cada equipe deve concordar com um conjunto de convenções de código que eles considerem adequadas para os aspectos mencionados acima. Isso pode significar adotar práticas de Robert C. Martin, de outro autor, ou inventar as suas próprias; pode significar escrevê-las formalmente ou documentá-las "pelo exemplo". Mas eles deveriam existir.
Exemplo
Considere a prática de "dividir o código de um método longo em vários métodos privados".
Robert C. Martin diz que esse estilo permite limitar o conteúdo de cada método a um nível de abstração - como um exemplo simplificado, um método público provavelmente consistiria apenas em chamadas para métodos privados como verifyInput(...)
, loadDataFromHardDisk(...)
, transformDataToJson(...)
e finalmente sendJsonToClient(...)
, e esses métodos teriam os detalhes da implementação.
- Algumas pessoas gostam disso porque os leitores podem obter uma visão geral rápida das etapas de alto nível e escolher quais detalhes desejam ler.
- Algumas pessoas não gostam, porque quando você quer saber todos os detalhes, você tem que pular na classe para acompanhar o fluxo de execução (isso é o que JacquesB provavelmente se refere quando escreve sobre adicionar complexidade).
A lição é: todos eles estão certos, porque têm o direito de ter uma opinião.