É impossível agradar a todos, especialmente em sala de aula

Sempre gostei de trabalhar com a qualidade do código-fonte, onde nos últimos 10 anos, me tornei um fervoroso adepto das boas práticas do paradigma POO. Princípios S.O.L.I.D., Design Patternsrefactoring (especialmente para bad smells), TDD, integração contínua, métodos ágeis, e qualquer outro tema que priorize a qualidade do código-fonte. Esse tema sempre me motivou em todos os segmentos da minha carreira, como o post Você realmente cria Softwares no Paradima POO?, pesquisas no mestrado e constante avaliação crítica, seja do meu código-fonte ou dos colegas.

Contudo, em 7 anos de docência, nunca tinha recebido uma oportunidade de ministrar alguma disciplina onde eu pudesse ter total liberdade de abordar este assunto. O máximo que tinha conseguido foi a oportunidade de ministrar uma disciplina chamada “UML e Padrões de Projeto” no curso de Pós Graduação Lato Sensu em “Desenvolvimento Java”, onde eu podia abordar uma parte do assunto, mas não com foco total.

Com alguns meses de docência no IFTM, finalmente consegui ter a oportunidade de ministrar uma disciplina neste formato, da melhor forma possível: a disciplina “Programação Orientada a Objetos”(POO) do curso de Pós Graduação Lato Sensu em “Análise e Desenvolvimento de Sistemas Aplicados à Gestão Empresarial”. A disciplina possui 8 encontros com 4 horas cada. Por se tratar de um curso onde 100% dos alunos possuem graduação em cursos de computação e afins, podia assumir tranquilamente que todos conheciam herança, encapsulamento, polimorfismo, composição, sobrecarga, sobrescrita, e todos os outros conceitos básicos de POO. Seria necessário apenas doutriná-los, para mergulharem no paradigma, buscando evoluir drasticamente a qualidade do seu código-fonte, livrando-os das maldições procedurais.Além de tudo isso, este tipo de disciplina é interessante, porque a grande maioria conhece o básico, mas poucos conhecem profundamente. Por isso, fica mais fácil e interessante de se aprofundar, diferente de disciplinas onde todo o conteúdo tende a ser novidade. Além do que, com os anos de experiência em desenvolvimento de sistemas comerciais no mercado de trabalho, surge uma bagagem natural que pode ser bem explorada na disciplina, mostrando várias decisões ruins aplicadas no dia-a-dia.

A primeira aula foi no dia 14/03/2015. Todos os planos de aula, slides e exemplos do curso estavam preparados. Algum tempo antes, tinha comprado na casa do código três livros que envolvem POO para buscar a abordagem mais atual possível. Resgatei alguns livros que já tinha e fechei o conteúdo. Na primeira aula(clique para ver os slides), ficou claro que a turma era bastante heterogênea: alguns estavam no mercado programando a todo vapor, enquanto que outros trabalhavam com outros paradigmas, e alguns tinham alguns bons anos que não criavam uma linha sequer de código-fonte. Eu já esperava por isso, tanto que o material preparado da primeira aula ficou bastante didático e baseado em um overview e nivelamento, para começar a “tacar fogo” a partir da segunda aula. Obviamente coloquei materiais de pré-requisito da disciplina, além de diversos livros e links, tudo com o propósito de guiar o aluno para o melhor aproveitamento possível. Após a primeira aula, percebi que precisavam de um reforço extra, então resolvi criar dois vídeos no youtube para ajudá-los a resgatar os conceitos: poo básico parte 1 e poo básico parte 2. Também formalizei um horário de atendimento semanal com 1 hora e meia de duração, para que as dúvidas fossem sanadas neste horário.

Após essa aula, no primeiro atendimento da semana seguinte, ao conversar com alguns alunos, já percebi que o nivelamento não poderia se restringir à primeira aula, precisaria mostrar como os objetos resolvem coisas básicas como: criar telas funcionando, persistência no banco de dados,etc… as pessoas no geral até entendem os objetos, mas em exemplos acadêmicos. Não sabem ao certo como isso funciona no dia-a-dia. Por isso decidi refazer os meus planos de aula, e ministrar algumas “aulas passo-a-passo”, ou “aulas tutorial”. Esse tipo de ajuste é comum, podemos planejar uma aula perfeitamente, mas pelo fato de estarmos constantemente lidando com pessoas, é natural que cada turma tenha uma forma mais apropriada em absorver o conteúdo. Com isso, os objetos de aprendizagem tendem a variar com o perfil de cada turma.

Com isso, na segunda(clique para ver os slides) e terceira(clique para ver os slides) aulas, ministradas em 20 e 21/03/2015, adotei um formato passo-a-passo, mas tentei fazer isso de maneira elegante, tentando chegar em um meio termo, para prender a atenção de todos: fiz um passo-a-passo em sala de aula sobre como criar um sistema básico orientado a objetos, utilizando MVC para que o projeto tenha separação lógica de camadas, utilizando Java Swing com o matisse do NetBeans para a criação de telas, classes de domínio mapeadas com hibernate/jpa para persistência no banco de dados Java DB(Apache Derby), e o framework beans binding para efetuar a vinculação automática entre os campos da tela e os objetos do control. Eu particularmente não gosto de aulas “passo-a-passo ou tutorial”, mas reconheço que é bem produtivo no que diz respeito ao nivelamento dos alunos, pois agrega muita prática para os que pouco sabem do assunto, e para os que possuem maior conhecimento, pelo menos uma ou outra novidade irá surgir. Por exemplo, nenhum aluno desta turma conhecia o framework beans binding e a sua forma elegante de trabalhar com as vinculações de objetos. O objetivo desta aula era apenas que os alunos entendessem melhor como que os objetos trocam mensagens para resolver problemas, especialmente em sistemas comerciais. Aspectos como a criação das telas e a persistência foram itens que tomaram muito pouco tempo, em virtude da produtividade do NetBeans. Obviamente usei conceitos visando qualidade, como genéricos, interfaces, isolamento de código, pacotes, padrões Java EE como DAO, Facade, etc.. Na aula 3 ainda fiz um total desacoplamento da camada Model, colocando-a em outro projeto, e até em outra IDE (Eclipse), efetuando uma comunicação cliente-servidor, via RMI (Remote Method Invocation). Não sou fã do RMI, mas é um ótimo estudo de caso para ensinar  melhor o desacoplamento de classes, e até ajuda no entendimento de outros itens, como por exemplo, a geração e o entendimento de bibliotecas .jar, pois o servidor precisa gerar uma biblioteca para aplicações cliente. Como sabia que era muita informação e muito passo-a-passo prático em sala de aula, fiz 5 vídeos e publiquei para que conseguissem absorver melhor os conceitos em casa. MVC parte 1, MVC parte 2,MVC parte 3,MVC parte 4 e MVC parte 5. Eu adoro criar vídeos, mas toma bastante tempo, pois são várias horas consumidas para criar os vídeos e efetuar o upload destes, fora o tempo de preparação dos slides, consolidação do conteúdo, horários de atendimento e as aulas em si.

Como mudei os planos de aula, naturalmente o sistema de avaliações também iria sofrer um “refactoring“. 1 mês antes de iniciar as aulas, tinha planejado distribuir os 100 pontos da seguinte forma: 20 pontos para formalizar os requisitos de um projeto, e os demais 80 pontos para executá-lo. Observei que, como os alunos precisavam aprender boas práticas de POO rapidamente, um bom negócio seria pedir para estes realizarem leituras de artigos técnicos de revistas como Java Magazine, e efetuarem resumos, me entregando em datas estratégicas, ou seja, exatamente no dia destes conteúdos serem efetivamente ministrados. Com isso, na quarta aula, pedi a leitura de dois artigos técnicos, me entregando os resumos no dia da sexta aula, com 2 semanas de prazo. Os artigos foram: Entendendo o Encapsulamento em Java e Desenvolvendo Software Sólido. O professor ganha muito com essa abordagem, pois eleva o nível do conhecimento do aluno com material extra, e o aluno também ganha, pois o seu estudo é recompensado com pontos, neste caso, 25 pontos.

Para a quarta(clique para ver os slides) e quinta(clique para ver os slides) aulas, ministradas em 27 e 28/03/2015, percebi a chance de introduzir algumas boas práticas POO no projeto “passo-a-passo” que foi criado em conjunto com os alunos nas duas aulas anteriores. As estratégias do bom uso de herança e composição são clássicas do paradigma POO, então abordei estas no projeto, refatorando as camadas DAO e Control, primeiramente usando a estratégia de herança, e posteriormente a estratégia de composição, comparando ambas, elevando o nível da discussão em sala de aula. Tudo isso sem sair do passo-a-passo, efetuando um refactoring em conjunto com todos os alunos, o que soa bastante interessante, pois todos programam, e depois discutem a efetividade da solução, pensando no seu código-fonte. Obviamente não perdi a chance e continuei os vídeos, criando as MVC parte 6, MVC parte 7 e MVC parte 8 apresentando essas estratégias de refactoring criadas em sala. Nos vídeos, geralmente adiciono algo que não foi dito em sala, para incentivá-los a assistir.

Na sexta(clique para ver os slides) e sétima(clique para ver os slides) aulas, ministradas em 10 e 11/04/2015, assumindo que os alunos tiveram bastante prática com o conteúdo, além de terem lido e entregado os resumos dos dois artigos que pedi para serem lidos, resolvi modificar um pouco a estratégia: cessaram as aulas passo-a-passo, e entraram as aulas mais alto nível, com as partes teórica e prática, aproveitando inclusive alguns pequenos projetos já prontos, para que o código-fonte seja analisado, e pequenas mudanças sejam feitas em aula. Com isso, mais conteúdo pode ser ministrado em menos tempo: os princípios POO, especialmente os básicos como “Encapsule o que varia”, “Modelo anêmico”, “Programe para a interface e não para implementação”, “Evite Herança Favoreça Composição”, “Favoreça Imutabilidade”, etc… trouxeram uma discussão em alto nível, e a todo tempo, além dos novos projetos, o projeto passo-a-passo utilizando entre as aulas 2 até 5 não foi esquecido, onde os conceitos dos princípios eram confrontados com algumas decisões tomadas neste projeto, evidenciando boas e más escolhas. Na aula 7, isso ficou ainda mais evidente, pois o conceito de inversão de controle é imprescindível, e algumas más práticas adotadas no projeto passo-a-passo nos motivaram a refatorá-lo e aplicar este bom princípio. Uma boa vantagem de não abordar todas as boas práticas de uma vez em um projeto é que, os alunos geralmente só vêem o benefício quando já conhecem uma abordagem inferior, mas claro que isso tem um limite. Essa aula inspirou os vídeos MVC parte 9 e a MVC parte 10, que mostram na prática um pequeno refactoring realizado no projeto passo-a-passo, usando inversão de controle. Como sabia que a aula 8 que ainda seria ministrada possuiria grande foco em Design Patterns, pedi para lerem e efetuarem o resumo de um artigo que aborda este tema, que foi o Explicando Padrões de Projeto, valendo mais 25 pontos, ou seja, metade dos pontos da disciplina foram distribuídos no resumo destes 3 artigos. Este artigo teve o valor de 25 pontos porque existem 4 partes do mesmo na revista.

Por fim, na oitava e última aula(clique para ver os slides), ministrada em 17/04/2015, alguns bad smells e design patterns precisavam ser abordados. Nesta parte, nada de projeto passo-a-passo, só exemplos que justicam o uso dos design patterns, pois sempre defendi que inventar o uso de padrão em um problema é um grande indício de anti-pattern. Observei que, mesmo abordando apenas 6 padrões na teoria e prática, a aula ficou um pouco alto nível para alguns alunos, e mesmo assim, chegando em casa, resolvi criar 6 vídeos, buscando uma nova abordagem para explicar o conteúdo. Entendendo patterns parte 1,Entendendo patterns parte 2, Entendendo patterns parte 3,Entendendo patterns parte 4,Entendendo patterns parte 5 e Entendendo patterns parte 6 .

Finalizado o curso, formalizei um email nesta mesma aula, que os 50 pontos restantes seriam usados para criar um Sistema no formato do projeto passo-a-passo utilizado nas aulas 2 até 7, com apenas 3 requisitos básicos:

1 – Uso de 2 design patterns gof à escolha;

2 – Uso dos princípios POO e MVC;

3 – Pelo menos 3 tabelas.

A data de entrega foi marcada para 30 dias depois, ou seja, dia 17/05. O sistema é livre de linguagem, desde que esta seja Orientada a Objetos. Mas obviamente, foram feitos 18 vídeos durante o decorrer da disciplina com todo o material pronto em Java, apenas necessitando mudar o exemplo para entregar o trabalho. De qualquer forma, deixei livre porque soa muito mais interessante tanto para mim quanto para eles.

Com o curso finalizado, surgiu uma sensação imensa de dever cumprido, pois fiz da melhor forma possível, com poucos erros, e do jeitinho que gostaria de ter aprendido, seja em cursos de graduação ou pós graduação. Se ainda for levar em conta que ministrei a disciplina pela primeira vez, diria que foi um resultado muito positivo. Talvez a minha única auto-crítica é que eu deveria ter solicitado a leitura desses artigos logo na primeira aula, e infelizmente tive essa idéia apenas com o curso em andamento. Também recebi muitos elogios de outros professores, que perceberam claramente o esforço. Um colega por exemplo foi categórico em dizer que é rarísismo um professor produzir 18 vídeo-aulas em um curso de 1 mês.

Mesmo com todo esse feedback positivo, infelizmente, recebi alguns feedbacks não tão agradáveis. Alguns alunos reclamaram deste trabalho final, que eu deveria ter solicitado este no meio do curso, para me me entregassem no dia do término da disciplina, evitando deixar trabalhos em aberto com as aulas já encerradas (como se não tivessem acesso a horários de atendimento, email e vídeo aulas). Outros já reclamam que eu deveria ser mais autoritário, não permitindo interrupções de alunos, para que a aula seja mais produtiva. Outros reclamam que eu ministro conteúdo demais, cobro demais,etc.. Se a minha carreira de docente estivesse se iniciando exatamente neste curso, certamente estaria muito chateado e talvez até arrependido de ter me dedicado tanto. Mas, após alguns anos, aprendemos algumas coisas simples, que nos ajudam a seguir em frente produzindo cada vez mais:

1 – O conteúdo, as metodologias e os objetos de aprendizagem da aula sempre precisam ser adaptados e aperfeiçoados. Professores que ensinam hoje do mesmo jeito que 20 anos atrás estão fadados ao fracasso;

2 – É impossível agradar a todos, especialmente em turmas heterogêneas. Sempre vai ter o aluno que exige que o curso seja ministrado exatamente do jeito que ele quer, não se importando se os demais colegas irão ou não aprender;

3 – Descontração é muito importante em sala de aula, especialmente quando se trata de 4 horas seguidas. Breves intervalos em aula com relatos de experiências vividas no dia-a-dia, não só geram descontração como recapturam a atenção dos alunos que se perderam na aula;

4 – Professor não somente ensina, mas também aprende. Observe que, quando o docente possui muito apreço pelo conteúdo, qualquer informação pertinente que o aluno possa compartilhar, tende a ser muito bem vinda;

5 – O bom professor é aquele que cobra do aluno, que mostra caminhos, novas formas de se pensar, que exige excelência e dedicação. Observe que, isto não tem nada a ver com injustiça. Injustiça é um professor cobrar algo na prova que não ensinou, ou corrigir uma prova errada e não aceitar voltar atrás, ou exercer abuso de autoridade em sala de aula. Um professor pode perfeitamente bem exigir muito do aluno, e ser justo;

6 – Especialmente em disciplinas que envolvem programação: todo mundo gosta de falar de programação, mas poucos realmente gostam de programar. A grande verdade é que a maioria começa a carreira de programador já sonhando com o dia em que possivelmente serão coordenadores ou gerentes de projeto. Da mesma forma que todo mundo quer parecer inteligente, culto, articulado, mas poucos realmente se movem para isso. Qual é a moral da história? Se o docente exige que o aluno crie código-fonte, seja em sala de aula ou em casa, está destinado a ser criticado, por melhor que seja a aula.

7 – Todo mundo gosta de receber elogios, mas muito antes ser criticado fazendo o certo, do que ser o elogiado que deixa de fazer o certo.

Por fim, concluo tudo o que foi dito com um excelente pronunciamento do Professor Clóvis, da faculdade de Filosofia da USP.

About CarlosEduardoXP

Especialista em desenvolvimento de Sistemas Distribuídos, sempre aplicando boas práticas e padrões difundidos na comunidade. Auto didata, fanático por refatoração e performance, sempre buscando reutilização e testes automatizados cada vez mais eficazes.
This entry was posted in Software Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s