Como se comportar quando cai no seu colo um sistema que não foi você quem desenvolveu?

Antes de mais nada quero explicar o porque da escolha de ‘Boas maneiras’ ao invés de ‘Boas práticas’. Boas maneiras esta ligada a boas práticas porém com a adição de ética e postura. Quando mexemos em um software desenvolvido por outra pessoa, precisamos lembrar que foi um companheiro de profissão que fez o trabalho. Falar mal, questionar e duvidar do Software em questão deve ser feito com muito cuidado e ética.

O cénario de mexer em um sistema de terceiro é muito comum, inclusive alguns sistemas acabam se tornando verdadeiros desafios. Só o fato de você ter de entender a arquitetura utilizada (quando tem) além da regra de negócio pode te comsumir muito mais horas do que o esperado. Para evitar noites sem dormir preparei uma cartilha que pode ajuda-lo nestas tarefas:

1 - Diretorios e arquivos do projeto

Faça um levantamento de todos os diretorios do projeto. Crie um documento texto com a lista de todos os diretorios e pacotes com um indicativo de qual a funçao do respectivo diretorio/arquivo no projeto.

Este levantamento vai te ajudar muito com uma visão de alto nível sobre as diferentes entidades envolvidas no projeto. É nesse momento que podemos identificar as camadas, as boas práticas e as convenções de nomenclatura.

Após entender a estrutura do sistema faça uma segunda análise com o objetivo de identificar os frameworks envolvidos e os arquivos de configuração (.properties e .xml)

Comportamento:
Mudanças na estrutura ou nomenclatura de pacotes só são aceitos em situações de Refactoring (alterar o codigo sem alterar funcionalidade). As vezes encontramos fulgas de padrões que realmente nos incomodam. Diretorios em português e inglês, nome de pacotes em maiusculo, etc. e mesmo assim devemos nos controlar e eveitar qualquer mudança. Lembre-se estamos na fase de Analise ainda.

2 - Depuração

Execute a aplicação em modo DEBUG. Realize operações simples e siga o fluxo de mensagens. Identifique entidades com papéis essencias como ServiceLocator, DAO, Factory, BusinessDelegate, Façade.

Neste momento você esta entendendo como funciona a arquitetura. A utilização de uma ferramenta de engenharia reversa para gerar um diagrama de sequencia e um diagrama de classe pode te ajudar muito.

Os modelos nesta situação servem para uma identificação mais detalhistas. Porém não se atenha somente aos modelos. Execute o programa. Veja as mensagens.

Comportamento:
Perca um tempo nesta etapa. Faça pesquisas, cadastrados e relatórios. Identifique a maioria das funcionalidades. Lembrando mais uma vez, ainda estamos na etapa de Analise. Não faça modificações.
Nesta etapa inclusive surgem as primeiras críticas ao software. Porque dessa classe vai para essa? O cara usou o DAO diferente dos projetos que eu estou acostumado? Poderiamos criar uma interface aqui ou ali.

3 - Começe pelo fácil

Na lista de novas funcionalidades a serem aplicadas no sistema, com certeza existem aquelas fáceis. Alinhamento de campo, formatação, validação. Comece por estas. Com isto você estará se familiarizando com a arquitetura, com a organização de arquivos e diretórios. Na comece pelas difíceis pois estas exigem um conhecimento de regra de negócio, que talvez você ainda não tenha.

Comportamento:
Ao fazer uma alteração, inclusão ou exlusão de código faça comentários. Mesmo que seja a inclusão de um atributo. Para os comentários utilize um identificar ligado a nova funcionalidade. Algo como

//NF0600505:Hildebrando Furlan Neto:Inclusao de if para validacao

O significado de NF é ‘New Feature’. Isto nao é um padrão, porém serve como controle para uma possível estatística de mudança. Adote o seu padrão. Converse com os outros envolvidos no projeto para seguirem este padrão.

4 - Testes unitários

Agora sim você consegue entender o porque da utilização de testes unitários é tão importante. Se ainda nao existe metodos de teste, crie-os. Isso ajuda inclusive para entender o algoritmo executado. Uma modificação em algo que esta funcionando deve ser feita com cautela. Com testes unitarios você tera um maior controle se o que você esta fazendo pode estar impactando em outras partes do Software.

Comportamento.
Siga o mesmo modelo de testes. Se for proprietário utilize o mesmo padrão. Caso nao possua, utilize um framework de testes como o JUnit e começe documentando alguns métodos de consistencia. Esclareça suas duvidas com o Analista responsavel para definir dados de entrada e as saidas. Se não existir ninguém simule testes na aplicação e utilize os dados de saida.

5 - Mão-na-massa

Ferramentas a mão e vamos codificar. Siga sempre a estrutura de pacotes e nomenclaturas (classes e identificadores). Abuse dos comentários. Adicione para que serve cada variavel, da onde veio e para onde vai. Mesma coisa com os metodos. Para que serve cada parametro. O que o metodo faz. Outro ponto é conhecer a Arquitetura utilizada. Se for proprietaria entenda seu processo e como as coisas funcionam. Interfaces que você deve implementar, VOs, DTOs, Tiles, Struts.

6 - Cuidado com os prazos

Somente após voce entender a estrutura completa do sistema (exemplo JSP -> Form -> Action) você conseguira dar uma prazo mais preciso. No entanto conheço a realidade brasileira e normalmente voce é questionado pelas horas antes mesmo do item 1. Os passos anteriores demoram cerca de 1 a 3 dias. Variando pelo numero de Frameworks e bibliotecas e seus conhecimentos em relação a eles.