Como as pessoas conseguem escrever e manter códigos extremamente complexos e difíceis de ler? [fechadas]

Ler o código fonte do SQLite é uma missão IMO impossível. No entanto, é um software utilizável e bastante complexo (afinal de contas, é um banco de dados incorporado completo) que pode ser baixado, compilado e usado a partir de outros códigos e é constantemente atualizado.

Como as pessoas conseguem escrever e manter códigos tão complexos e difíceis de ler?

Há uma grande diferença entre Complexo e Complicado. O link a seguir sobre resume. :)

http://codebetter.com/blogs/dru.sellers/archive/2009/09/25/complex-vs-complicated.aspx

Em uma nota mais pessoal, trabalho em uma base de código de mais de 1 milhão de linhas de código. Eu estive nele da linha 1 para o seu estado atual. Quanto mais farmilar você é (leia mais tempo no código), mais fácil ele se torna. Não sei dizer o que cada linha faz, mas posso dizer que você deve começar a procurar uma determinada tarefa ou bug. Apenas vem naturalmente.

A moral da história é que, como qualquer coisa no mundo da programação, leva tempo. Se você espera examinar o SQLite e apenas conhece e entende, está se enganando. Vai levar tempo para descobrir como tudo funciona juntos. A diferença entre código bom e código ruim é quanto tempo esse processo leva.

Por fim, alguns desenvolvedores não têm a capacidade de pular para uma base de código e começar a descobrir. Muitos se sentirão sobrecarregados com o tamanho ou a arquitetura da base de código. Outros não terão nenhum problema apenas pulando nele. Tudo depende dos pontos fortes dos desenvolvedores.

No caso específico do SQLite, a principal ferramenta que eles escolheram para uso no desenvolvimento e manutenção é o teste automatizado. Eles se orgulham de uma cobertura de 100% (cobertura de agência, e não de declaração) em seu conjunto de testes. Segundo eles, é um dos produtos de software mais testados do mundo. Portanto, eles sabem imediatamente quando algo que eles adicionaram ou alteraram causa uma regressão e podem se desenvolver sem medo como resultado disso.

http://sqlite.org/testing.html

Números bastante surpreendentes - eles têm cerca de 640 vezes mais linhas de código de teste do que o código de produção.

EDIT: Esta questão foi levantada dentre os mortos, parece! E pouco mais de um ano depois, a mesma página informa que eles têm 1177 vezes mais linhas de código de teste que a produção!

• funcionalidades evolui com o tempo.
  • novas funcionalidades são impulsionadas por novos requisitos do cliente.
  • O código antigo foi escrito de uma maneira que permite que futuras funcionalidades a serem implementadas sejam adicionadas sem quebrar o código antigo.
• especialistas em domínio (neste caso, banco de dados é um domínio bem conhecido em Ciência da Computação.)
• feedback da comunidade
  • insetos
• A curva acentuada de aprendizado não foi um problema para os bem preparados e perseverantes. Pode levar 6 meses, 1 ano ou mais para ficar confortável, e é isso que algumas pessoas conseguem suportar.
• motivações comerciais. sem apoio monetário, pouquíssimas pessoas podem investir tempo e energia na íngreme curva de aprendizado.

Você não precisa ter uma compreensão íntima de todo o projeto para poder mantê-lo. Geralmente, com softwares grandes e complexos, as pessoas têm suas "áreas" particulares que cuidam e só têm um conhecimento "passageiro" do restante do sistema.

O SQLite é relativamente pequeno na escala de "grandes projetos de software", mas se você olhar algo como o sistema operacional Windows, terá pessoas que apenas trabalham no kernel, pessoas que apenas trabalham no shell, pessoas que apenas trabalham no Internet Explorer, pessoas que simplesmente trabalham no gerenciador de janelas, etc. Alguém que trabalha no "shell" não conseguirá consertar um bug no kernel com um simples toque.

Há também o benefício de que esses projetos evoluem ao longo do tempo: eles nem sempre começam tão complicados. Isso significa que um novo desenvolvedor geralmente pode ser "treinado" por desenvolvedores mais experientes.

Quando você ingressa em uma grande equipe de desenvolvedores, recebe um aspecto específico do projeto para trabalhar (talvez um bug ou um novo recurso) e solicita que outro desenvolvedor seja seu "amigo" nas primeiras iterações. Seu amigo terá um bom entendimento da área em que está trabalhando e pode ajudá-lo a encontrar o caminho.

Para projetos de código aberto como SQLite, na verdade é um pouco mais difícil, porque não há motivação para os desenvolvedores existentes "treinarem" novos desenvolvedores. Então, você descobrirá que está sozinho um pouco mais. Mas você ainda pode encontrar ajuda em fóruns de desenvolvedores ou listas de discussão (por exemplo, apenas postando uma pergunta como "Gostaria de implementar esse recurso", ou "Encontrei o bug XYZ, por onde começo a procurar?" E é provável que você obtenha alguma forma de ajuda.

Há uma diferença entre projeto difícil de ler e complexo. Se uma pessoa não entende profundamente o idioma em que o projeto foi escrito ou o domínio do projeto, isso não significa que o código está mal escrito.

Meu conselho:

• Certifique-se de entender o idioma do projeto. Não basta conhecer o idioma.
• Aprenda todos os detalhes sobre o domínio antes de colocar o código em mãos.

Para mim, o SQLite está longe de ser complexo e nada complicado. O domínio deste projeto exige um entendimento profundo sobre conceitos amplos.

Uma coisa não mencionada nas outras respostas é "Isso vem naturalmente para elas". A maioria das pessoas deseja escrever código bom, mas está sintonizada para escrever código ruim. Alguns dos programadores que conheci são naturalmente pensadores LINEARES + algumas vezes, com muita inteligência, eles apresentam soluções complexas. A maioria dessas pessoas não gasta tempo lendo ou aprendendo com o livro que aprende como e quando o trabalho exige.

Como as pessoas conseguem escrever e manter códigos tão complexos e difíceis de ler?

Se eles são os codificadores originais, e continuam mantendo-os, eles não o veem como "complexo e difícil de ler". Eles provavelmente vêem isso como "simples e fácil de ler", já que eles mesmos escreveram.

Qualquer código leva tempo para entendê-lo. É que alguns demoram mais que outros :)

Você pode entender qualquer base de código se tiver - perseverança, paciência e uma abordagem metódica - mas principalmente perseverança :-)

O gerenciamento se torna muito mais fácil se houver sempre a mesma coisa. Não conheço o código SQLite, mas estou trabalhando em um ambiente em que existem vários projetos. Além de entender o business case (eq logic), como tudo é basicamente feito da mesma maneira em todos os lugares (acesso ao banco de dados etc.), é relativamente fácil começar a trabalhar em outro projeto. Texto breve: As diretrizes de codificação - de maneira apropriada - tornam a vida e esse código muito mais fáceis. Este poderia ser um dos auxiliares dos codificadores SQLite.

• Se você é o autor original do software e trabalha com ele há mais de 10 anos, e é um gênio, pode ser possível entender tudo. Grandes partes de software complexo (como SQLite ou o kernel Linux) geralmente têm exatamente um autor original com uma compreensão completa e profunda, mesmo que outras pessoas tenham contribuído.
• Se a arquitetura do software é sã (alta coesão, baixo acoplamento), entender tudo não é um pré-requisito para fazer acréscimos e modificações úteis.
• A compreensão de um RDBMS ou SO é um caso especial, exigindo um entendimento profundo dos princípios subjacentes do CS. Não é assim com aplicativos de software "comuns".

Eles tentam escrever de uma maneira simples, mas não de uma maneira simplista.

Ser o mais simples possível torna as coisas mais rápidas de entender / ler, mesmo que demore algum tempo.

O algoritmo que está sendo implementado define um limite mais baixo de quão simples o código para uma implementação pode ser. Se uma descrição abstrata do algoritmo a ser implementado for extremamente complicada e exigir que várias partes diferentes de dados sejam acopladas, o código que implementa o referido algoritmo não poderá ser simples, não importa quem o esteja escrevendo.

Em outras palavras, uma razão pela qual às vezes escrevo código inescrutável é porque, dado o algoritmo que quero implementar, não tenho escolha.