Como você acompanha os grandes projetos?

Ao lidar com um projeto que possui muitos arquivos diferentes, sempre pareço perder a noção de como as partes interagem umas com as outras. Eu realmente nunca tive muito problema em entender componentes menores isoladamente, mas à medida que a complexidade do projeto aumenta, me encontro incapaz de construir mentalmente um entendimento do que está acontecendo. Percebo isso especialmente em projetos OOP, à medida que o número de métodos e arquivos de origem aumenta.

Meu histórico: sou um programador web autodidata. Eu lidei principalmente com python para scripts rápidos e sujos, mas também fiz alguns projetos básicos de django . Gosto de estruturas da Web como o balão , porque, na simplicidade de um layout de arquivo único, posso acompanhar (principalmente) o que está acontecendo.

Agora me encontro em uma situação em que preciso interagir com um grande projeto PHP do Zend Framework que outra pessoa desenvolveu, e estou impressionado com a tentativa de entender o código espalhado por vários arquivos.

Quais técnicas e processos você achou úteis para entender uma grande base de código que outra pessoa desenvolveu? Existe algum diagrama específico que você encontra ajuda a entender a imagem maior?

O truque para entender uma grande base de código é não tentar entender tudo. Depois de um certo tamanho, você não pode manter um modelo mental na cabeça da coisa toda. Você começa com um ponto de ancoragem que faz sentido para qualquer tarefa em que você precise trabalhar primeiro e depois ramifica a partir daí, aprendendo apenas as partes necessárias e confiando que o restante funcione como anunciado. É como entender a recursão. Se você tentar segurar toda a pilha em sua cabeça, seu cérebro explode.

Grep, debuggers e intellisense são seus amigos aqui. Se você não sabe como uma função acaba sendo chamada, defina um ponto de interrupção nela e desça o rastreamento da pilha.

A outra coisa a notar é que grandes bases de código não surgem do nada. Quanto maior, mais programadores existem com experiência, portanto pergunte a eles por onde começar, mas seja específico. Faça perguntas como "Preciso adicionar um novo provedor de pagamentos. Onde devo procurar o código?" Concentre-se nessa tarefa, em vez de tentar entender toda a base de código e, peça por peça, sua familiaridade aumentará.

Não há atalho. Você apenas tem que sofrer com isso.

Para responder sua pergunta sobre como obter diagramas, doxygen é o que você deseja. AFAIK funciona com PHP.

De maneira mais geral, eu passo pelos seguintes estágios ao encontrar uma nova base de código:

1. Entenda o que ele faz do ponto de vista do usuário. Você pode realmente usar o aplicativo como um usuário avançado. Entenda como os verdadeiros usuários finais trabalham com ele. Isso pode exigir que você se sente com eles até obter uma sólida compreensão do que eles fazem.

2. Comunique-se com os desenvolvedores originais, se possível. No início, você terá perguntas de arquitetura estimuladas pela experiência do usuário final. Posteriormente, você terá perguntas de implementação sobre casos extremos e detalhes. Ser capaz de obter respostas dos desenvolvedores ajudará muito mais do que qualquer comentário ou documentação (que é, na melhor das hipóteses, incompleta e muitas vezes enganosa ou totalmente ausente).

3. Aprenda sobre qualquer estrutura que você estiver usando. Você deve, no mínimo, criar um "olá mundo" ou outro aplicativo simples com essa estrutura antes de mergulhar no aplicativo de produção.

4. Controle todo o processo de implantação (melhor quando os desenvolvedores originais estão segurando sua mão). Se você não pode pegar a base de código atual e compilá-la e implantá-la em um ambiente de teste / validação / prod, está brindando. Mesmo a menor mudança exigirá passar por todas as etapas da implantação, então por que não fazer essa parte imediatamente? Ao fazer isso, você será apresentado a todos os adoráveis ​​servidores, bancos de dados, serviços e scripts usados ​​pelo aplicativo - você saberá "onde ele mora".

5. Controle os testes funcionais (se houver). Como você sabe se a coisa está funcionando corretamente? O que a equipe de operações deve fazer para cuidar e alimentar o aplicativo?

6. Entenda os logs do aplicativo. Embora eu nunca tenha trabalhado com PHP, vou adivinhar e dizer que qualquer aplicativo PHP sério terá algum tipo de log. Se você entender os logs, terá um bom ponto de partida quando chegar a hora dos problemas de depuração.

---- Note que até aqui, eu nem mencionei olhar atentamente a base de código. Há MUITO que você pode aprender sobre um grande projeto sem sequer olhar para o código. Em algum momento, é claro, você precisa se sentir confortável com o código. Aqui está o que me ajuda:

7. Para diagramas, o doxygen é uma excelente ferramenta que irá gerar gráficos de chamadas e outros relacionamentos para você. Acontece que tem capacidade PHP! Se você ainda não experimentou o doxygen, é absolutamente necessário dar uma olhada. Embora eu não possa garantir o quão inteligível será o código dentro de uma estrutura, mas isso poderia ajudar. Os desenvolvedores originais geralmente ficam chocados com o que veem quando são apresentados com documentos de código gerados por doxygen. A boa notícia é que isso realmente ajuda a melhorar a memória deles e a ajudá-lo melhor.

8. Se você tiver um conjunto de testes de unidade, examiná-los de perto deve fornecer uma janela para o funcionamento interno do aplicativo. Esse também será o primeiro lugar para procurar bugs que você pode ter introduzido ao fazer alterações.

9. Os marcadores IDE são inestimáveis ​​para a marcação de pontos de acesso na base de código. Ser capaz de alterná-los rapidamente promoverá a compreensão.

10. A leitura de relatórios de erros recentes e suas resoluções também é valiosa para entender os pontos de acesso e ajudará você a se familiarizar com as partes mais relevantes da base de código.

Conforme solicitado, aqui está o meu comentário como resposta.

Ao trabalhar com o código de outras pessoas, costumo criar ou, se possível, gerar diagramas de classes UML para fornecer uma visão geral da estrutura estática. O diagrama visual me ajuda especialmente quando tenho que voltar mais tarde e já esqueci o contexto de uma classe. Às vezes, faço isso por comportamento dinâmico também para alinhar as interações entre colaboradores, mas não faço isso com tanta frequência.

Se a base de código contiver testes (integração ou unidade), às vezes vale a pena conferir também.

Na verdade, vou começar a fazer isso durante o decorrer desta semana, em que um novo cliente precisa de aprimoramentos para um produto que foi deixado por outro desenvolvedor. Abaixo estão as etapas a serem seguidas:

a) Identifique a estrutura de programação usada, o que ajuda a saber como o aplicativo flui.

b) Identifique serviços comuns - registro, manipulação de exceções, MVC, conexão com o banco de dados, auditoria, visualização (geração de páginas), pois essas são as partes em que mais usaremos.

c) Execute fluxos de usuários comuns (no aplicativo) e tente alinhá-los à maneira como o código é organizado

d) Tente fazer algumas alterações e ver como elas saem. Este é o maior passo, porque até você começar a fazer alterações, o código ainda é uma caixa preta ....

Vou informá-lo de outras idéias que recebo ao longo das próximas duas semanas.

Meu pensamento é que você deva ler a documentação. Eu sei que os hackers gostam de dizer "o código é a documentação" e usam isso como desculpa para não escrever nenhuma documentação, mas eles estão errados. Veja o kernel do Linux, um projeto de software maciço de muitos milhões de linhas de código: eu não acho que alguém possa realmente entrar de novo sem ter lido um livro e apenas buscá-lo. Se o código com o qual você está trabalhando não está documentado (ou bem comentado se um projeto menor), provavelmente não é um bom código.

Se você está trabalhando com algo realmente grande e sem documentação (eu também estive lá, é difícil!), O que descobri que ajuda é tentar isolar a parte em que você está trabalhando. Nessa parte do código, descubra como os dados / eventos / mensagens / interações passam e saem dessa unidade. Em outras palavras, faça a engenharia reversa da interface. Anotá-la. Da próxima vez que você trabalhar em outra unidade (bônus se ela falar com a que você trabalhou primeiro), faça a mesma coisa. Guarde toda a sua documentação. Após alguns meses, você terá uma boa imagem de como a coisa flui.

Descubra a interface de uma pequena unidade na qual você está trabalhando e grave-a para referência posterior. Com o tempo, você irá costurar a maior parte de como funciona. Encontre o que seu programa faz e rastreie como essa mensagem flui. Por exemplo, se o seu sistema pega alguma mensagem da rede de entrada e envia uma mensagem de saída, rastreie como essa mensagem flui pelo sistema, sem se preocupar com todos os detalhes - apenas veja para onde ela vai.

O que faço é criar um único modelo UML a partir de todos os arquivos que foram revertidos de java para UML. Essa abordagem significa que o modelo não é mais apenas uma visão abstrata do projeto, mas o próprio projeto totalmente mapeado para o MOF e, portanto, para a UML.

O que recebo é um grande modelo único composto por vários submodelos, cada um composto por pacotes, que são compostos por classificadores, etc. Quero dizer que o mesmo método pode chamar um classificador no projeto A e outro classificador no projeto B. A única maneira de ver toda a estrutura do projeto é reverter os dois ao mesmo tempo. Não tenho tempo para criar diagramas de componentes e as informações não são realmente precisas. Prefiro pedir ao computador para reverter o projeto completo para mim. Eu faço o inverso a cada iteração com a equipe e todos os meus diagramas são atualizados imediatamente. A engenharia reversa é incremental e usa o mapeamento de Java para UML Ids. Quero dizer que cada elemento java é mapeado para um elemento MOF único e único que permanece o mesmo durante toda a vida do projeto, mesmo se refatorado. Isso não limita mais a modelagem UML e permite modelagem de projeto muito grande e complexa. Para sua informação, eu trabalho com projetos com mais de 5 000 000 linhas de código OOP. Todos os meus projetos são revertidos corretamente e a navegação gráfica é possível

Eu só uso diagramas de classes porque, no meu modelo UML, posso criar quantas visualizações forem necessárias, sempre atualizadas. Eu também posso modelar projetos muito complexos.