Como grandes bibliotecas de código aberto são mantidas enquanto o código está longe das práticas de “código limpo”?

Boa resposta aqui já, mas deixe-me dizer uma palavra sobre o seu

Os princípios estabelecidos em "Código Limpo" nem sempre são geralmente acordados. A maior parte é senso comum, mas algumas das opiniões do autor são bastante controversas e não compartilhadas por todos.

Em particular, a preferência por métodos curtos não é aceita por todos. Se o código em um método mais longo não for repetido em outro lugar, extrair parte dele para um método separado (para obter vários métodos menores) aumenta a complexidade geral, pois esses métodos agora são visíveis para outros métodos que não devem se preocupar com eles. Portanto, é um trade-off, não uma melhoria objetiva.

O conselho no livro é também (como todos os conselhos) voltado para um tipo específico de software: aplicativos corporativos. Outros tipos de software, como jogos ou sistemas operacionais, têm restrições diferentes do software corporativo, portanto, padrões e princípios de design diferentes estão em jogo.

A linguagem também é um fator: o Código Limpo pressupõe Java ou uma linguagem similar - se você usa C ou Lisp, muitos dos conselhos não se aplicam.

Quanto aos projetos de código aberto, a qualidade do código varia de abismal a brilhante. Afinal, qualquer pessoa pode publicar seu código como código aberto. Mas se você olhar para um projeto de código aberto maduro e bem-sucedido com vários colaboradores, pode ter certeza de que eles decidiram conscientemente um estilo que funciona para eles. Se esse estilo está em contradição com alguma opinião ou orientação, então (para ser franco) é a diretriz que é errada ou irrelevante, já que o código de trabalho supera as opiniões.

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.

Muitas bibliotecas de código aberto sofrem, de fato, de práticas de codificação inadequadas e são mantidas com dificuldade por um pequeno grupo de colaboradores de longo prazo que lidam com a má legibilidade porque estão muito familiarizados com as partes do código que elas mantêm com mais frequência. Refatorar o código para melhorar a legibilidade depois do fato é frequentemente um esforço hercúleo porque todos precisam estar na mesma página, não é divertido e não paga, porque nenhum novo recurso é implementado.

Como outros já disseram, qualquer livro sobre código limpo declarando qualquer coisa necessariamente contém conselhos que não são universalmente aceitos. Em particular, quase qualquer regra pode ser seguida com zelo excessivo, substituindo um problema de legibilidade por outro.

Pessoalmente, evito criar funções nomeadas se não tiver um bom nome para elas. E um bom nome tem que ser curto e descrever fielmente o que a função faz para o mundo exterior. Isso também está ligado à tentativa de ter o menor número possível de argumentos de função e nenhum dado globalmente gravável. Tentar reduzir uma função muito complexa em funções menores geralmente resulta em listas de argumentos muito longas quando a função é realmente complexa. Criar e manter código legível é um exercício em equilíbrio entre regras de senso comum mutuamente conflitantes. A leitura de livros é boa, mas apenas a experiência ensinará como encontrar falsa complexidade , que é onde os ganhos reais de legibilidade são obtidos.

A maioria dos projetos de código aberto é mal gerenciada. Obviamente existem exceções, mas você encontrará muito lixo no mundo do código aberto.

Esta não é uma crítica de todos os proprietários / gerentes de projetos cujos projetos eu estou falando, é simplesmente uma questão de tempo usada. Essas pessoas têm coisas melhores para fazer com seu tempo, como o emprego que pagam.

No começo, o código é o trabalho de uma pessoa e provavelmente é pequeno. E um código pequeno não precisa estar limpo. Ou melhor, o esforço necessário para tornar o código limpo é maior do que o benefício.

Conforme o tempo passa, o código é mais uma pilha de correções de muitas pessoas diferentes. Os criadores de patches não sentem a propriedade do código, eles querem apenas que esse recurso seja adicionado ou que esse bug seja corrigido da maneira mais fácil possível.

O proprietário não tem tempo para limpar as coisas e ninguém mais se importa.

E o código está ficando grande. E feio.

À medida que fica cada vez mais difícil encontrar o caminho do código, as pessoas começam a adicionar recursos no lugar errado. E, em vez de corrigir bugs, eles adicionam soluções alternativas em outros lugares no código.

Neste ponto, não é só que as pessoas não se importam, elas já não ousam limpar, pois têm medo de quebrar coisas.

Eu tenho pessoas descrevendo bases de código como "punição cruel e incomum".

Minhas experiências pessoais não são tão ruins assim, mas eu vi algumas coisas muito estranhas.

Parece-me que você está perguntando como essas coisas funcionam mesmo se ninguém está fazendo o que é Deveria estar fazendo. E se funcionar, então por que deveríamos fazer essas coisas

A resposta, IMHO, é que funciona "bom o suficiente" , também conhecido como " pior é melhor " filosofia . Basicamente, apesar da história acidentada entre o código aberto e o Bill Gates, ambos de fato adotaram a mesma idéia, que a maioria das pessoas se preocupa com a idéia de que a características, não bugs .

Isso, é claro, também nos leva a " normalização do desvio " que leva a situações como Heartbleed , onde, precisamente como se respondesse à sua pergunta, um enorme, overgrown pilha de espaguete de aberto código-fonte chamado OpenSSL foi " não limpo " para algo como dez anos , terminando com um enorme que afeta milhares de milhões de pessoas .

A solução foi para inventar um novo sistema chamado LibreSSL , que era vai usar código clean-ish , e é claro quase ninguém usa .

Então, como grandes projetos de código aberto mal codificados são mantidos? A resposta está na pergunta. Muitos deles não são mantidos em um estado limpo. Eles são corrigidos aleatoriamente por milhares de pessoas diferentes para cobrir casos de uso em várias máquinas estranhas e situações que os desenvolvedores irão nunca tem acesso para testar. O código funciona "bom o suficiente" até isso não acontece , quando todos entram em pânico e decidem .

Então, por que você deveria se preocupar em fazer algo ' o caminho certo ' se ninguém mais estiver?

A resposta é que você não deveria. Você faz ou não , e o independentemente, porque natureza humana não muda na escala de um humano vida . Pessoalmente, eu só tento escrever código limpo porque gosto do jeito que ele faz.

O que constitui um bom código depende do contexto, e livros clássicos que o guiam são, se não muito antigos para discutir open-source, pelo menos parte de uma tradição travada pela guerra interminável contra bases de código internas ruins. Portanto, é fácil ignorar o fato de que as bibliotecas têm objetivos completamente diferentes e estão escritas de acordo. Considere os seguintes problemas, sem nenhuma ordem específica:

• Quando eu importo uma biblioteca, ou de uma biblioteca, provavelmente não sou especialista em sua estrutura interna para saber exatamente qual pequena fração de seu kit de ferramentas eu preciso para o que quer que eu esteja trabalhando, a menos que eu seja copiando o que uma resposta do Stack Exchange me disse para fazer. Então eu começo a digitar from A import (se é em Python, por exemplo) e vejo o que aparece. Mas isso significa que o que eu vejo listado precisa refletir as tarefas lógicas que precisarei tomar emprestado, e é isso que tem que estar na base de código. Inúmeros métodos auxiliares que diminuem o tempo vão apenas me confundir.
• Bibliotecas estão lá para o programador mais inexperiente tentando usar algum algoritmo que a maioria das pessoas só ouviu falar vagamente. Eles precisam de documentação externa, e isso precisa espelhar precisamente o código, o que não pode ser feito se continuarmos refatorando tudo para fazer com que os adeptos do método curto e do tipo "faça-uma-coisa" sejam felizes.
• Cada método de biblioteca que as pessoas emprestam pode quebrar o código em todo o mundo com consequências desastrosas se for removido ou mesmo renomeado. Claro, eu gostaria que a sklearn corrigisse o erro de digitação em Calinski-Harabasz , mas que poderia causar outro incidente no bloco de esquerda . De fato, na minha experiência, o maior problema com a evolução da biblioteca é quando eles tentam muito adotar uma nova "melhoria" de bom código para como eles estruturam tudo.
• Internamente, os comentários são, na melhor das hipóteses, um mal necessário, por todas as razões pelas quais não preciso regurgitar (embora esses pontos exagerem um pouco). Um bom comentário diz por que o código funciona, não como. Mas as bibliotecas sabem que seus leitores são programadores competentes que não poderiam, digamos, escrever álgebra linear como se estivessem saindo de uma sacola de papel. Em outras palavras, tudo precisa de comentário re: por que funciona! (OK, isso é outro exagero.) Então é por isso que você vê a linha de assinatura, bloco de comentário de 100 linhas, uma linha de código que poderia literalmente ter entrado na linha de assinatura (se a linguagem permitir, é claro).
• Digamos que você atualize algo no Github e espere para ver se seu código será aceito. Deve ficar claro por que sua alteração de código funciona. Eu sei por experiência própria que a refatoração para tornar o acampamento mais limpo, como parte de um commit funcional, muitas vezes significa muita economia de linha, rearranjo e renomeação, o que dificulta o trabalho do revisor, e causa outros problemas.

Tenho certeza de que pessoas com mais experiência do que eu podem mencionar outros pontos.

Já existem muitas boas respostas - quero dar a perspectiva de um mantenedor de código aberto.

Minha perspectiva

Sou mantenedor de muitos desses projetos com menos de um ótimo código. Às vezes, até sou impedido de melhorar esse código por causa das preocupações de compatibilidade, já que as bibliotecas são baixadas milhões de vezes por semana.

Isso torna a manutenção mais difícil - como membro principal do Node.js, há partes do código que tenho medo de tocar, mas há muito trabalho a ser feito e as pessoas usam a plataforma com sucesso e se divertem. O mais importante é que funcione.

Em código legível

Quando você diz:

I found the code in many of them to be far from the principles addressed to write clean code – e.g methods containing hundreds of lines of code.

Linhas de código não são uma boa medida de quão legível isto é. No estudo que eu associei ao kernel do linux foi analisado e uma pesquisa de programadores encontrou um código "regular" (código que as pessoas esperam basicamente) e um código consistente para ser melhor que o código "limpo" na compreensibilidade. Isso também se alinha com minha experiência pessoal.

Alguns projetos de código aberto não são muito acolhedores

Linus "notoriamente" disse que o Linux não deveria ter um depurador integrado porque as pessoas que usam depuradores não são bons o suficiente para trabalhar no linux e ele não quer atrair mais deles.

Pessoalmente, eu discordo totalmente de sua posição lá - mas também é algo que as pessoas fazem.

Software de código aberto não significa necessariamente que vários autores estejam envolvidos. Quando um software (ou unidade de software) é escrito por um único autor, as funções longas aparecem com frequência.

Isso vem da natureza do processo de desenvolvimento. Um método simples é estendido ao longo do tempo, novos recursos estão sendo adicionados e corrigidos.

Os métodos longos reduzem drasticamente a compreensão da funcionalidade para novos autores. No entanto, com um único autor isso raramente é um problema e o problema tende a ser negligenciado. Outra natureza do software livre é o fato de que muitos softwares não são desenvolvidos ativamente, portanto, não há trabalho de refatoração que, por exemplo, divida métodos complexos em múltiplos métodos simples.

Você não mostrou nenhum exemplo, mas pelo que entendi, isso também é freqüentemente conectado à linguagem de desenvolvimento. Algumas linguagens aplicam regras de lintagem rígidas desde o início e testes de unidade pesada (ou mesmo TDD). Ambos os testes de lintagem e unidade geralmente evitam esse problema (é difícil unificar métodos complexos / longos).

Em geral, é mais difícil limpar o código se o software for desenvolvido por um único autor, e outros contribuidores apenas corrigem pequenos problemas.