Eu ensino revisão de código em engenharia de software. Nesse momento os alunos precisam parar de escrever código e precisam ler e entender código. Isso só é feito bem no final do curso quando eles já estão perto de se formarem. Será que se eu ensinasse aos alunos primeiro a ler e entender código (leitura de texto seguida de compreensão de texto) para depois ensiná-los a escrever código (redação de texto) eles escreveriam códigos melhores ou mais fáceis de serem compreendidos?
Em linguagem natural, quanto mais livros você lê, melhor você passa a escrever, pois tem uma gama variada de estilos para seguir. Código também não é diferente. Quanto mais experiente você fica na leitura do código melhor você entende e pode escrever ou dar manutenção no código dos outros. Vejam o resumo deste artigo do David Garlan e outros:
Pouco se sabe sobre como desenvolvedores pensam sobre o design durante tarefas de mudanças em código, ou sobre como o conhecimento de design de desenvolvedores experientes os ajuda a trabalhar de modo mais eficaz. Realizamos um estudo de laboratório em que treze desenvolvedores trabalharam por três horas tentando entender o design de uma aplicação de código livre com 54 mil linhas de código. Os participantes tinham entre 0 e 10.5 anos de experiência e foram agrupados em três "experts" e dez "principiantes." Observamos que os participantes passaram seu tempo aprendendo, criticando, explicando, propondo e implementando fatos sobre o código, como "getFoldLevel tem efeitos." Os fatos serviam vários papéis, como sugerir mudanças, restringir mudanças e prever o tempo de investigações adicionais necessárias para se efetuar uma mudança. As diferenças entre experts e novatos incluiram o fato de os experts terem explicado a causa fundamental do problema de design e terem feito mudanças para consertá-lo, enquanto as mudanças dos novatos atacavam apenas os sintomas. Os experts não leram mais métodos mas também não visitaram alguns métodos não-relacionados em que os principantes perderam tempo tentando entender. Experts falavam sobre o código em termos de abstrações como "caching", enquanto os novatos descreviam o código de comando em comando. Os experts foram capazes de implementar uma mudança mais rapidamente que os principiantes. Também perceberam problemas que os principiantes não encontraram e foram capazes de explicar fatos que os principiantes não conseguiram. Todos esses achados tem implicações interessantes para futuras ferramentas.
Se você entende código melhor com o passar dos anos e com a experiência adquirida, eu acredito que você também automaticamente passa a escrever código melhor. Isso com certeza porque você já leu muito mais código e eu espero que seja código de qualidade que você está tendo acesso para leitura. Infelizmente, por mais que eu possa explicar isso para os alunos na universidade, são só os anos de leitura e compreensão de código que os tornarão melhores escritores de código.
não li tudo não, mas em todos os métodos de ensino que eu conheço, primeiro a criança aprende a escrever (i.e. copiar palavras) pra depois aprender a ler!
ResponderExcluirConcordo com a defesa de que, como a escrita para humanos, a escrita para a máquina melhora com a leitura.
ResponderExcluirE as vezes a leitura de um código ruim também te dá bons insights de como NÃO escrever!
@Girino, bom, comigo não foi assim mas eu aprendi a ler a muuuuuito tempo atrás. De fato, minha filha aprendeu a escrever anter de aprender a ler.
ResponderExcluirNo entanto, você não concorda que na escola (de informática) a ênfase é violentamente na escrita de programas e não na leitura? Cadê o equivalente àqueles exercícios de compreensão de textos que a gente fazia no primário? Não tem. Eu, pelo menos, nunca tive. Ninguém na universidade jamais mostrou um programa no quadro e disse, "esse programa é bem feito por esses motivos..."
Uma época eu pensei a uma disciplina semelhante ao que a Guta propôs, seria chamada "Literatura". O objetivo seria apresentar boas implementações para algoritmos conhecidos (quicksort, hashing, linked lists).
ResponderExcluirOs trabalhos práticos seriam feitos por grupos:
1) Primeiro cada grupo teria que definir o guia de estilo para a linguagem que irão desenvolver. Possivelmente cada grupo deveria apresentar para o resto da turma a sua proposta de estilo.
2) Depois cada aluno iria implementar individualmente uma solução para um problema fácil, mas que exige grande quantidade de código.
3) Finalmente os membros do grupo fariam algo parecido com "code reviews", cada aluno iria trocar com colegas do próprio grupo, códigos que eles implementaram, e os colegas teriam que sugerir melhorias para o código baseado em qualidade e no estilo que ele proporam.
É só uma ideia, nunca gastei muito tempo nela.
Eu sou ainda mais 'idealista', ou radical, Sonequinha.
ResponderExcluirEu acho que quem forma em CS deveria sair da faculdade com uma certa quantidade de CLs submetidas e Code Reviews feitos.
Os Code Reviews 'circulariam', tipo, o pessoal do 2o. periodo tem que ler o código que o pessoal do 3o. ou 4o. periodo submetem, e vice versa. Os alunos da mesma turma devem revisar o código um dos outros. e cada CR contaria como "créditos". Assim como você, eu não pensei direito nesta idéia, os detalhes. Só que acho que implementar isso pode ser bem dificil e precisa de uma cooperação/coordenação entre os professores. Além disso, é necessário que todos os professores do Depto concordem que "coding is important". Da mesma maneira que não é possível imaginar alguém formado em Letras ou Filosofia e que não sabe escrever _bem_, não deveria ser possível sair de uma faculdade de Computção sem saber escrever programas _bem_.
Só que não tenho certeza que todo mundo da área pensa assim... :(
Soneca e Ademir, eu acho as idéias boas mas como professor acho que ia ser difícil de avaliar... como é que eu faço pra dar nota no code review que o aluno fez? Eu ia ter de fazer meu próprio code review de 40 alunos, depois comparar cada um com o que o colega fez. É barra pesada.
ResponderExcluirPrecisa avaliar? A ideia do Ademirão de que "não deveria ser possível sair de uma faculdade de Computação sem saber escrever programas _bem_" é linda, mas pouco prática.
ResponderExcluirPra quem está interessado em aprender, code reviews não precisam ser avaliados, seriam uma tarefa bacana que eles se interessam em fazer. Vai ser a mesma turminha que faz iniciação científica, vira monitor, faz todos os trabalhos com capricho e tal, mas pra essa turminha seria ótimo.
Talvez seja legal como follow-up: você faz uma disciplina de Processamento de Imagens e implementa um programa que tem vários filtros. Depois que você entrega o seu trabalho, recebe um trabalho da turma anterior pra revisar.
Ou então, se for mesmo necessário avaliar, faz o seguinte: tem um prazo A pra se entregar o trabalho. Nessa entrega, os trabalhos são trocados entre alunos ou grupos, e aí passam por revisão de código dos colegas. Depois disso, num novo prazo B, a revisão de código acaba e os trabalhos são entregues ao professor. Aí o professor corrige, mas com um rigor maior quanto a estilo e qualidade de código.