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?
Respostas:
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:
É 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.