Alguns anos atrás pude conviver um pouco com minha cunhada arquiteta enquanto viajávamos por algumas cidades do interior da Itália. Uma das coisas que me surpreendeu na viagem foi a atenção que ela dava aos detalhes das construções, tirando fotos de calhas, paredes, janelas, portas, etc. Enquanto nos preocupávamos com um mundo novo que conhecíamos, ela ficava atenta a cada detalhe.
Fiquei, obviamente, intrigado com o comportamento dela. E fiquei ainda mais intrigado após entender por que ela observava o trabalho dos outros com tanto afinco. Na arquitetura, o processo de criação leva em consideração a observação do trabalho dos outros arquitetos.
O processo de desenvolvimento de software também é um processo criativo. No entanto, parece-me que neste processo a observação do software desenvolvido por outras pessoas não tem um papel tão fundamental. Pelo menos não tem o papel que deveria ter.
Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (GoF) foram em um caminho parecido, ao utilizar a observação para identificar padrões de solução de problemas em software. Martin Fowler também é outro expoente deste tipo de observação e de sua aplicação na vida real. No entanto, a prática da observação realizada por estes grandes nomes da computação não foi absorvida pelos demais desenvolvedores (com exceções, claro). Apenas os resultados de sua observação é que se tornaram notáveis, e não o processo pelo qual estes resultados foram obtidos.
Os design patterns são exemplos de como a observação é efetiva. No entanto, o uso destes design patterns não é o benefício mais importante destes trabalhos. O benefício está no processo de observação e aprendizado. É este processo que precisamos exercitar constantemente e é nesta observação que devemos basear nosso aprendizado.
Nenhum comentário:
Postar um comentário