Ir para o conteúdo
ou

Thin logo

Organização

Patrocínio Ouro

Patrocínio Prata

Apoio

Realização

LinguÁgil no Twitter

410 Gone

LinguAgil

 Voltar a Notícias
Tela cheia Sugerir um artigo

Sith Refactoring

16 de Setembro de 2010, 0:00 , por Software Livre Brasil - 0sem comentários ainda | Ninguém está seguindo este artigo ainda.
Visualizado 689 vezes

 

Por algum tempo eu venho pensando em “como ensinar habilidades de programação reais e de boa qualidade?”. Tenho compartilhado diversas conversas a respeito do tema com amigos e antigos professores. O fato é que geralmente termina com críticas ao modelo atual de ensino, todavia não respondem a pergunta. É um tema complexo, alguns livros [pragmatic programming, refactoring] tratam do assunto de forma exemplar, mas não são ainda a resposta que procuro. Já era um tanto claro para mim que não basta saber a resposta, é preciso vive-la [a meta].

O que segue é um misto do que vivenciei junto ao o que observei no mercado, aliado a muita cultura geek dos anos 80. Então:

“A long time ago. In a galaxy far, far away....”

No inicio da jornada, um Padawan Programmer tenta absorver ao máximo a técnica. Aprende estruturas de controle, laços, bibliotecas, frameworks e vai tateando diversas linguagens. Diz alô ao mundo (Hello World) das mais diferentes formas. Os primeiros problemas ocorrem quando a técnica ao ser aplicada a prática tem um domínio do problema muito maior do que o mundo cumprimentado. É o primeiro cho que de realidade, um momento onde o Padawan se vê perdido em forum s e grupos de usuários a procura de ajuda. A medida em que o problema aumenta a complexidade cresce exponencialmente. É perceptível que a técnica sozinha não é suficiente.

Muitos limitam aos cookbooks, contudo alguns se rebelam e buscam mais do que manejar o sabre, querem saber construi-lo. Começam a perguntar em forums como o framework funciona e a olhar o código fonte de terceiros. Fazem a auto-critica do seu legado, onde acumulo de debitos de design, aumenta a tentação de reescrever todo o código.  Até o primeiro contato com os quatro cavaleiros [Design Patterns] e os seus designs mágicos.

O grau de cavaleiro é passado quando o programador enfrenta os próprios problemas [refactoring]. Que atire a primeira pedra quem nunca provou do próprio Spaghetti code. É fim dos livros de receita e o inicio dos blocos de montar. A mudança de grau ocorre do fato da abstração do pensamento em detrimento ao colar de receitas. Um olhar mais aguçado permite criar padrões complexos de sistemas modulares. Até o ponto em que fogem da visão periférica e a miopia não permite acompanhar o todo, mas apenas fatias do problema.  O big-upfront-design e o over-planning e suas arquiteturas da nasa são os novos inimigos.

Para alcançar o ponto de projetar, construir e manter um sistema sem perder o foco, são necessários testes. Um Jedi Master Tester quebra e concerta o programa inúmeras vezes, importante é obter o sinal verde ao fim do dia [agile testing]. Assim, finalmente param de ver apenas a TI e enxergam o negocio como um todo. Aprendem a meditar e reavaliar todo o código feito.

E voltamos para o primeiro paragrafo, agora reavaliado, testado e quebrado.

Como ensinar uma habilidade? Como fazer um programador vivenciar uma experiência?

Em geral o processo de aprendizado de um programador é sequencial, do Padawan ao JediMaster-Tester. A formação acadêmica enfatiza esse processo desdes a raízes. Tendo em vista o necessário ao desenvolvimento profissional, podemos deduzir o triangulo do programador. A base fundamental para a formação de um programador: técnica, conhecimento e foco [sith refactoring]. Um fator pode compensar a deficiência do outro, mas não inibe a necessidade do mesmo. Vértices que ele ira encontrar ao longo da sua jornada se seguir as pedras corretas.

Hexagonodoprogramadoragil

Essas pedras são conhecidas e percorridas desde tempos de relatórios do caos. E só esse caminho não ajudaram muito naqueles relatórios. O manifesto ágil amplia o espetro apresentando novos vértices. Estes são somatório dos vértices adjacentes e tem como premissa os três vértices opostos. A criatividade, simplicidade e o bom senso.

Triangulodoprogramador

 

O Manifesto 2.0 [alegomes, linguágil 2009], agrega um vértice isolado, com o eixo perpendicular ao hexagono formado, e de influência a todos os demais. O vértice da motivação. Caracterizado pelo ambiente e os mais diversos fatores que orbitam o programador.


Sith_radar

 

E assim surgiu o Sith Refactoring. Um projeto começou logo após o primeiro LinguÁgil. Onde eu queria uma forma de levar a laboratório o design evolutivo de código e mostrar a importância do manifesto ágil. Exemplificar que mesmo projetos com uma UML aceitável podem sofrer com mal-cheiros de código e os vértices responsáveis. E a partir desdes prover soluções que visam melhorar e simplificar o código [refactoring to patterns, e algumas ideias minhas]. Refatorar o código e o programador [serge rehem, aptitude 2.0], de Jedi a Sith.

Para refletir tal objetivo , queria um exemplo real. Embora eu admire os Dojos, queria algo mais que um Hello World. Peguei um projeto antigo de 2005 , e fui reorganizando o mesmo de forma a deixa-lo propositalmente em termos de projeto, com uma UML aceitável, mas de difícil evolução. O objetivo, explicar o porque a evolução do mesmo é complexa, identificar os mal cheiros de código e procurar formas para refatoração do código.

O projeto escolhido foi uma biblioteca funcional de MSN, a Hellow - More than a Hello World, por tratar de questões que geralmente são vistas como complexas, com uso protocolo e threads.

Os códigos estão disponíveis (GPLv3) no meu github: http://github.com/gutomaia/

Até então, já fiz 2 laboratórios com (cobaias) amigos. Aprendi muito e tenho me divertido com essa brincadeira. Estou refinando e ajustando apresentação e as possibilidades para refatoração. Vou tentar organizar todos os resultados e deixa-los acessíveis a qualquer interessado.

Fica aí o meu convite para o LinguÁgil e o Sith Refactoring.

 

Guto Maia

@gutomaia

 

Referências e agradecimentos:

Tenho como referência nessa processo, autores, que apesar da influência no trabalho, não conheço pessoalmente. Assim como pessoas mais próximas que em pequenas frases são detentoras de igual mérito. Sith Refactoring nasceu no último LinguÁgil, basicamente nos corredores. Muita coisa ocorre nos corredores que não aparecem no cronograma. Por isso, fiquem a vontade a participar se me verem perambulando entre as salas. Seguem todos que contribuíram para o Sith Refactoring.

 

  • The Pragmatic Programmer: From Journeyman to Master; Andrew Hunt e David Thomas;
  • Refactoring: Improving the Design of Existing Code; Martin Fowler, Kent Back, John Brant, Willian Opdyke, Don Roberts;
  • Refactoring to Patterns; Joshua Kerievsky;
  • Design Patterns: Elements of Reusable Object-Oriented; Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides;
  • Agile Testing: A Practical Guide For Testers And Agile Teams; Lisa Crispin, Janet Gregory;
  • @alegomes e as conversas que iam muito além do contexto em seu mini-curso de Liferay. Acho que ele estava fazendo um ensaio interativo da palestra do Manifesto 2.0.
  • @felipernb, em seu mini-curso de programação a prova de balas, nas pausas discutíamos sobre testes e qualidade de código, neste ponto foi surgindo a idéia de aplicar o assunto em alguns códigos meus antigos. Algumas idéias foram surgindo, mas faltava ainda um formato.
  • @mlalbuquerque e as discussões sobre o modelo educational e propagação do conhecimento (durante a aula do @felipernb).
  • @serge_rehem e @alexchatisnet que no bate papo fora da sala, na véspera do dia de palestras, que o Sith Refactoring começou a ter uma identidade e propósito.
  • e @anarchya por ter me ajudado a refatorar este artigo. Dando um excelente feedback sobre os problemas encontrados. E me deu uma excelente dica: Não escrever artigos com sono!

Fonte: Gustavo Maia

0sem comentários ainda

Enviar um comentário

Os campos são obrigatórios.

Se você é um usuário registrado, pode se identificar e ser reconhecido automaticamente.