** Você vai ler mais código do que escrever.**
Um dos fatos da carreira em programação é precisar entender uma base de código antiga.
Ou uma base moderna, porém grande.
Às vezes simplesmente entender a stack do projeto React do seu time.
Mesmo para aquela pequena correção, é necessário entender um módulo do sistema.
Ou dois, pois estão acoplados.
E vai encontrar uma função complexa, que vai te ocupar um dia quase todo.
Já se passou um dia e você não escreveu código.
Apenas leu.
Até conseguir ter o contexto completo, você já passou por muitos arquivos e funções.
O código escrito se resumiu a poucas linhas.
No fim o maior esforço foi ler o código e entender. Não escrever.
Quais as opções? ¶
Seria ótimo te dizer, leia a documentação.
Raramente a documentação existe, e quando existe, está desatualizada há mais de um ano.
Neste caso temos as opções de ler o código ou consultar alguém que conheça o código.
Nem sempre há pessoas disponíveis, às vezes nem está mais na empresa.
Ler o código se torna a última saída.
A mentalidade é importante ¶
Existe uma ansiedade em entender tudo rapidamente.
O tamanho do projeto pode ser intimidante e as regras muitas.
A questão é que você não precisa entender tudo rapidamente.
Na pressa, conclusões incorretas podem ser tomadas e mecanismos implícitos continuarão em segredo.
Não é possível entender tudo de uma vez só, por isso algumas técnicas podem ser usadas.
Você não vai entender tudo de uma vez!
Procure por testes ¶
Isso se existirem, claro.
As suítes de testes demonstram como o código se comporta.
Os cenários e fluxos são descritos, assim como dados esperados.
É uma forma de documentação viva e um ótimo ponto de início.
Procure por palavras-chave ¶
Existem certos padrões entre diferentes aplicações, que representam os mesmos conceitos.
Algumas palavras-chave comuns:
- handlers: representam handlers para diferentes tipos de entrada, geralmente em apps web
- controllers: comuns em aplicações no padrão MVC
- repository: persistência, geralmente para banco de dados
- cache: implementação para cache
- services: serviços da aplicação
- usecase: comum ao utilizar Clean Architecture
- clients: clientes HTTP para integrações HTTP
- log: escritas de log podem indicar pontos importantes da aplicação
Siga fluxos ¶
Procure pelas entradas de dados e por onde eles transitam pela aplicação.
O fluxo mais comum é:
- Entrada de Dados -> como os daods chegam na aplicação? Um formulário, via API?
- Processamento -> Local Onde a regra de negócio “vive”
- Persistência -> Banco de dados, arquivos, cache
Identificar fluxos, a partir de pontos de entrada, pode trazer uma boa visão da aplicação.
Pode ser combinado utilizando debuggers em uma IDE, executando o código e entendendo o que ocorre.
Em uma aplicação web, comece pelo controller/route que recebe a requisição HTTP.
Siga o parâmetro até o service, depois até o repository.
Use o debugger para “caminhar” com os dados.
Anote as descobertas ¶
Aproveite o conhecimento e anote o que achar relevante.
Isso pode ser útil no futuro, tanto para você quando para sua equipe, ou até mesmo para outras pessoas interessadas no projeto.
Indicar locais importantes, partes críticas da aplicação é muito bem-vindo.
Você pode comentar nessas funções críticas.
Pode-se usar também diagramas para especificar fluxos mais importantes.
Isso pode ser base para uma documentação futura.
Concluindo ¶
Ler código é tão importante quanto o escrever.
É uma habilidade que se aprende na prática, utilizando técnicas para tanto.
Algumas foram listadas aqui, mas com a experiência novas serão criadas ou aprendidas.
Lembre-se, hoje é você quem lê o código, amanhã pode ser outra pessoa.