ti-enxame.com

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

Ler SQLite código fonte é 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?

27
sharptooth

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 posso 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.

19
Tony

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 tantas linhas de código de teste quanto de 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!

31
Dan Ray
  • as funcionalidades evoluem 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 funcionalidades futuras ainda a serem implementadas sejam adicionadas sem quebrar o código antigo.
  • especialistas em domínio (nesse 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.
7
rwong

Você não precisa ter uma compreensão íntima do projeto inteiro para poder mantê-lo. Geralmente, com softwares grandes e complexos, as pessoas têm suas "áreas" particulares que cuidam e possuem apenas 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 apenas trabalham no gerenciador de janelas etc. etc. Alguém que trabalha no " O Shell "não será capaz de consertar um bug no kernel logo de cara.

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 em 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.

4
Dean Harding

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 profundo entendimento sobre conceitos amplos.

4
Maniero

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.

3
Geek

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-o, não o veem como "complexo e difícil de ler". Eles provavelmente o veem 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 :)

3
lamcro

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

2
Nikhil
  • 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 quantidades de software complexo (como SQLite ou o kernel Linux) na verdade geralmente têm exatamente um autor original com uma compreensão completa e profunda dele, 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 profundo entendimento dos princípios subjacentes do CS. Não é assim com aplicativos de software "comuns".
1
Joonas Pulakka

O gerenciamento se torna muito mais fácil se houver coisas sempre da mesma maneira. 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.

1
Sascha

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

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

1
Klaim

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, independentemente de 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.

1
dsimcha