Como você lê o código de outros? [fechadas]

Quase todo programador avançado diz que é muito útil ler o código de outros profissionais. Geralmente eles aconselham código-fonte aberto.

Você leu ou não? Se sim, com que frequência e qual é o procedimento de leitura do código? Além disso, é um pouco difícil para iniciantes lidar com o SVN - um monte de arquivos. Qual a solução?

Você leu ou não?

Sim.

Se sim, com que frequência

Diariamente. Constantemente. Trabalho com vários projetos de código aberto (principalmente relacionados ao Python) e devo ler o código-fonte, pois é a documentação mais precisa.

e qual é o procedimento de leitura do código?

Hum. Abra e leia.

Além disso, é um pouco difícil para iniciantes lidar com o SVN - um monte de arquivos. Qual a solução?

Abra e leia. Então leia mais.

Não é fácil. Nada facilita isso. Não há Royal Road para o entendimento. Dá trabalho.

Existem várias camadas no enigma que você tem. Primeiro, comece no nível mais alto, com uma visão panorâmica, por assim dizer. Após o check-out de um projeto, haverá vários arquivos em uma estrutura de diretórios. É o mesmo se você estiver olhando para código aberto ou código fechado (afinal, o código-fonte é o código-fonte). Então comece com isso:

• Como os arquivos de origem são organizados? Você pode dizer pelo nome do arquivo ou pelo diretório que contém o que você pode encontrar dentro? Nós programadores costumamos gostar de nomes previsíveis e estrutura lógica. Você deve ter uma idéia aproximada de onde procurar um problema específico.
• Qual é a natureza do aplicativo, é baseado na Web, linha de comando, GUI? A razão pela qual isso é importante é que você deseja saber por onde começar a rastrear a execução. Se for baseado na Web, você deseja começar com o local em que o aplicativo começa a processar a solicitação. Se for construído sobre uma estrutura, tanto melhor. Depois de conhecer a estrutura, você geralmente pode entender o código existente. Caso contrário, você começará com o respectivo ponto de entrada para o aplicativo de linha de comando / GUI.
• Pegue uma folha de papel e um lápis ou, se tiver sorte, um quadro branco e marcadores de apagar a seco. Dê os nomes dos componentes (ou use os fornecidos no código) e desenhe linhas entre as caixas com setas para que você possa ver como as coisas são processadas. Como alternativa, se você estiver olhando para um algoritmo, esboce as estruturas de dados de maneira a entender e esboçar como elas são manipuladas.

É preciso prática, mas é definitivamente factível. Quanto mais você souber sobre as bibliotecas e estruturas que o aplicativo está usando, mais saberá como o código precisa ser organizado e onde procurar respostas para perguntas específicas. Algum código é um pouco mais difícil de seguir, principalmente se for bastante indireto. É por isso que você precisa de lápis e papel. Eventualmente, uma lâmpada se apaga na sua cabeça e você a entende. É quando ler o restante do código faz muito mais sentido.

Não é ler como você lê um romance, mas mais como ler um livro de referência. Uma boa maneira é escolher um bug corrigido recentemente em uma mensagem de check-in, fazer uma comparação do que mudou e ler as partes relevantes até entender o problema e a solução. Vulnerabilidades de segurança bem divulgadas são bugs divertidos, porque há muita discussão sobre elas nos fóruns. Em seguida, escolha um dos erros de "frutas baixas penduradas" no rastreador de erros e leia até entender como corrigi-lo. A maioria dos profissionais de leitura de código é incidental no curso de correção de bugs ou adição de recursos.

Geralmente, os melhores exemplos de código são quase imperceptíveis. Você os entenderá instantaneamente sem ler mais de uma vez. Eles fazem com que pareça extremamente fácil de escrever, mesmo que um código tão bom normalmente passe por vários rascunhos. Produz a sensação paradoxal de que, é claro, o código fornecido é a maneira óbvia de fazê-lo, mesmo que não seja a primeira maneira que você pensou.

Quando você se deparar com um código como esse, tente entender as informações necessárias para escrevê-lo e os princípios de design envolvidos; assim, quando se encontrar em uma situação semelhante no futuro, esperamos poder aplicar os mesmos princípios.

Um truque que uso frequentemente ao ler uma função complicada, o segmento de código, é começar a refatorá-la em algo mais legível sem alterar a lógica.

Como é difícil lidar com "um monte de arquivos"? Não é diferente de quando você escreve seu próprio código, exceto que você não tem conhecimento prévio de sua organização, a menos que esteja documentado.

Se você, como programador declarado, não pode descobrir a estrutura do projeto a partir de "um monte de arquivos", seja um projeto extremamente mal organizado, ou você é um programador inepto (ou, em casos extremos, ambos).

Comece a ler, tente encontrar alguns pontos de entrada ou classes / métodos essenciais de pivô e construa um entendimento de como tudo acontece a partir daí. Não será instantâneo, levará tempo, mas pode ser feito mesmo se não houver documentação.

A melhor coisa que você pode esperar ao ler o código de outro projeto, seja uma API ou um software, é que as variáveis, funções e nomes de macro não sejam abreviados de forma ambígua ou nomeados para que você possa descobrir sua intenção.

Mas, além disso, é preciso uma quantidade decente de conhecimento espalhado pela linguagem, pelas técnicas de programação e também pelo próprio propósito do código para poder mergulhar em códigos complexos.

Atualmente, estou tentando ver como Lua faz parte de sua mágica, mas estou chegando ao ponto acima, onde muitos dos identificadores são nomeados vagamente e abreviados até o ponto em que não consigo descobrir qual linha está tentando fazer o que sei que precisa ser feito em algum momento no código da função ... As variáveis ​​frequentes de uma única letra e os nomes de macro / função bastante abreviados estão me fazendo pensar.

Depois de observar o "Primeiro, comece no nível superior, uma visão panorâmica", como sugeriu @Berin Loritsch, você pode procurar por unittests e / ou integração, se houver algum.

os unittests são interessantes para ver como os detalhes (api-) funcionam.

O teste de integração geralmente fornece uma boa visão geral dos processos de negócios.