Matheus Tardivo

Thinking and talking about software development

Novo endereço

Posted by Matheus Tardivo em março 24, 2009

Depois de muito tempo sem postar, resolvi retomar as atividades, mas agora em um novo endereço: http://blog.tardivo.org.

Não se esqueçam de atualizar os seus feeds.

Obrigado a todos pela audiência 🙂

Anúncios

Posted in Uncategorized | 1 Comment »

O mercado esta mudando ou é impressão minha?

Posted by Matheus Tardivo em março 28, 2008

[edit]
O Vinícius Teles acabou de postar no blog dele o mesmo texto. Tirando a minha introdução – e incluindo a dele, o conteúdo é o mesmo. Segue o link para o post: O mercado está mudando?
[/edit]

O título desse post é o assunto de um email, enviado para a lista Scrum-Brasil, que gerou uma discussão bem interessante.

Pra quem, assim como eu, tem interesse em métodos ágeis de desenvolvimento de software, o texto abaixo serve para mostrar o quanto é complicado conseguir mudar a cultura das empresas que utilizam métodos ultrapassados tradicionais.

Continuo acreditando e defendendo a idéia que Scrum, XP, (coloque aqui sua métodologia ágil preferida), dão uma visão muito mais realista para o desenvolvimento de software, afinal, desenvolver software é essencialmente diferente de construir prédios. Infelizmente, comparar o desenvolvimento de software com a construção civil ainda é a análogia mais usada – tanto na prática quanto no meio acadêmico.

O texto abaixo foi escrito pelo Vinícius Teles que é uma das pessoas com mais experiência no assunto “ágil” no Brasil. Pra quem já leu algum post desse blog já deve ter lido sobre ele.

É um texto extenso, mas de leitura obrigatória pra quem tem interesse por metodologias ágeis e quer ter uma idéia realista do que terá que enfrentar na maioria das empresas brasileiras.

“Minha resposta curta para a sua pergunta é: sim, o mercado está mudando. Ele está sempre mudando. 🙂 Mas, talvez não tanto assim quanto gostaríamos e, possivelmente, não na direção que desejamos. Uma das mudanças mais perceptíveis é que cada vez mais gente tem ouvido falar de desenvolvimento ágil. Mas, isso não quer dizer necessariamente que cada vez mais gente esteja adotando métodos ágeis. Certamente, cada vez mais gente DIZ estar usando métodos ágeis. Mas, a distância entre o DIZER e o FAZER é imensa, sobretudo nesta área. Acredito que, daqui por diante, veremos cada vez mais gente falando sobre desenvolvimento ágil, mas continuaremos a ver poucos usando. Há algumas razões fundamentais para isso.

Desenvolvimento ágil não tem a ver com Scrum, XP, FDD, Lean ou seja lá qual for o nome. Tem a ver, acima de tudo, com a maneira como encaramos desenvolvimento de software. Tem a ver com a compreensão da verdadeira NATUREZA do desenvolvimento de software. Os anos passam, mas a maioria absoluta das pessoas não consegue se livrar da idéia de que desenvolver software seja igual a construir prédio. As conseqüências desta dissonância cognitiva são infinitamente mais sérias do que a maioria de nós gostaria de acreditar. Escrevi exaustivamente sobre isso na minha dissertação (http://www.improveit.com.br/xp/dissertacaoXP.pdf, cápitulos 3 e 4), então, não vou me estender aqui. Apenas resumirei porque isso é tão prejudicial.

O que uma empresa produz é resultado de como ela está estruturada. Quem tem autoridade para dizer como deve ser a estrutura de uma empresa é quem está no topo. Então, a estrutura de qualquer é empresa é, no fim das contas, o resultado do modo de pensar, da mentalidade, de quem está no comando. A mentalidade da maioria dos empresários, diretores e gerentes no mundo inteiro é, com raríssimas exceções, arcaica e incompatível com o trabalho de desenvolver software. Quando o topo da empresa não entende o tipo de mentalidade necessária para se desenvolver software de forma bem sucedida, não há santo que possa fazer milagre. E eu garanto, a maioria absoluta das pessoas que estão no comando das empresas não entende uma vírgula do que significa desenvolver software. Isso inclui, certamente, a maioria absoluta dos CIOs. Não é à toa que eles buscam recorrentemente coisas como CMMI, PMBOK, MPS.BR, ITIL etc, todos absolutamente incompatíveis com a NATUREZA do desenvolvimento de software. A mentalidade por trás destas aberrações é inútil, quando o assunto é software, mas casa perfeitamente com a mentalidade da maioria dos gestores. E não pára por aí. Nas universidades, a situação é igual ou pior.

Veja o caso da UFRJ, por exemplo. Neste semestre, o professor de engenharia de software, percebendo a crescente movimentação em torno de métodos ágeis, resolveu gastar boa parte do seu tempo para mostrar aos alunos que métodos como o XP não funcionam. Afinal, se fôssemos fazer um prédio com XP, aconteceria mil e uma coisas horrendas. Nisso ele está certo. O problema, como sempre, é a maldita distinção entre construir prédio e desenvolver software, a qual, seria óbvia para uma criança, mas é impossível de ser percebida por um Ph.D(eus). Olha que loucura, em uma universidade do quilate da UFRJ, o cidadão, só porque é Ph.D.(eus), não precisa se dar ao trabalho de estudar sobre métodos ágeis, nem muito menos usá-lo, para já saber, desde criancinha, que não pode dar certo. E claro, um conhecimento destes, tão valioso, não pode ser mantido só para ele. Também é preciso passar adiante para os alunos, como se fosse necessário. Afinal, eles já estão todos estagiando em empresas entupidas de documentos e péssimas práticas de desenvolvimento até o último fio de cabelo.

Sempre fui muito otimista, em tudo. Mas, em se tratando de desenvolvimento ágil, acho que meu otimismo se foi. Foram precisos seis anos para isso acontecer, devo dizer, mas se foi. E a razão está lá em cima, no topo das empresas, no topo das universidades. Está lá onde a mediocridade e a incompetência imperam, ao menos em se tratando de desenvolvimento de software e gestão de pessoas. Percebi, com o tempo, que podemos fazer diferença na base, sim, mas é muito pequena e, freqüentemente efêmera.

Fiquei tempo suficiente nesta área para ver equipes adotarem XP, funcionarem super bem durante algum tempo e, mais a frente, serem impedidas de continuar porque a organização passa minar o andamento do grupo. É como um corpo estranho, que é expelido naturalmente pelas nossas células. Só para dar um exemplo. Em 2003, nós fizemos um projeto XP para a Vale do Rio Doce. Foi um projeto lindo, com tudo que se tinha direito. Até contrato de escopo negociável. As áreas de negócio amaram tudo o que foi feito. Adoravam os desenvolvedores. Depois que o sistema foi colocado no ar, foram encontrados apenas 3 bugs durante os seis meses seguintes. Isso é nada em um projeto de mais de um ano, com mais de dez pessoas envolvidas. O projeto foi um sucesso em praticamente todos os quesitos que se pudesse imaginar. Mas, aí é que estava o problema. A última coisa que alguém quer é um projeto de sucesso! Afinal, como ficam os demais? Quando o projeto acabou, tudo foi feito dentro da Vale para que nunca mais isso se repetisse. Acredite, não foi a única vez que vi isso acontecer. Em seis anos, eu vi muita coisa começar bem e, mais a frente, acabar. Por que?

Porque desenvolver software com a mentalidade ágil não é compatível com a mentalidade de quem manda. Isso é mais do que suficiente para limitar as mudanças na área de software. Acredito que vai levar muito tempo para que as empresas passem a ter gestores que compreendam não apenas o que é fazer software. Mas, o que é fazer um trabalho do conhecimento. A maioria absoluta dos gestores tratam seus funcionários como se fossem crianças. Fica parecendo que os piores imbecis são justamente os que mais freqüentemente são escolhidos para comandar as empresas. Não parece apenas, isso realmente acontece e dói ver o quanto isso é comum. Enquanto estes estiverem lá em cima, vamos ouvir falar muito sobre desenvolvimento ágil. Mas é só. Aliás, não é não. Tem coisa pior. Vamos ver pessoas fazendo barbaridades e dizendo que estão usando desenvolvimento ágil.

Para quem ainda estiver no ramo de consultoria, isso não é necessariamente ruim. Essa área vai bombar. Vamos ter cada vez mais espaço para cursos e consultoria em desenvolvimento ágil. O interesse só vai crescer daqui por diante. Não necessariamente pelos méritos, mas porque alguém ouviu dizer que agora o grande lance é fazer software com a ___________ (preencha com a metodologia ágil preferida).

O problema dos gestores não afeta apenas o desenvolvimento de software. Ele é muito mais sério e muito mais abrangente que isso. Entre em qualquer empresa grande e o que você verá é um bando de trabalhadores do conhecimento sendo tratados como pedreiros por um bando de incompetentes que não conseguem fazer nada melhor que jogar tempo e dinheiro na lata de lixo. O nível de desperdício de talento, tempo, dinheiro, oportunidades etc é tão colossal que eu realmente não consigo compreender como alguém consegue trabalhar em uma empresa grande atualmente. Claro, existem exceções. Pouquíssimas, mas existem. São apenas isso, exceções.

Desejo muita sorte e sucesso para quem continua lutando para mudar este panorama. Não tenho dúvidas de que as coisas irão melhorar ao longo do tempo. Mas, acho bastante improvável que uma mudança significativa aconteça no curto ou médio prazo. Enquanto as pessoas chegarem no topo das empresas com a mentalidade que temos hoje em dia, enquanto os professores universitários continuarem ensinando lixo, enquanto as empresas continuarem a ganhar dinheiro apesar das práticas de administração arcaicas que utilizam, enquanto nós aceitarmos trabalhar para estes idiotas, vai ser complicado.

Desculpa pelo pessimismo. Não foi sempre assim. Foram necessários seis anos, seis turmas de XP na UFRJ, literalmente centenas de apresentações de XP em todo o Brasil, um mestrado, não sei quantos cursos, vários mentorings, alguns projetos de desenvolvimento XP, algumas conferências no exterior, um livro e mais um monte de coisas que eu não lembro, para me dobrar. E antes que alguém pense que o problema era o XP e que tudo poderia ser diferente se tivesse sido Scrum, FDD, Lean etc, não se enganem. O buraco é mais embaixo. Se você conseguiu chegar até aqui e prestou atenção ao que estou dizendo, tudo se resume a uma coisa: mudar é difícil? É. Mas, ainda é a parte fácil. O difícil mesmo é mudar de vez.

O Kent Beck tem um exemplo ótimo. Segundo ele, parar de fumar é fácil. Tanto que tem gente que já parou várias vezes. 🙂 O problema é parar e nunca mais voltar a fumar. É a mesma coisa. Um monte de gente vai conseguir mudar para desenvolvimento ágil. Poucos conseguirão sustentar esta mudança. E eu adoraria estar falando isso de orelhada. Mas, é que eu vi as pessoas voltarem a fumar um número suficiente de vezes para saber que é ótimo ver mais movimentação atualmente sobre desenvolvimento ágil. Mas, acredito que seja ingênuo achar que isso implique em uma mudança significativa. Muitos tentarão e a maioria vai voltar às práticas antigas, simplesmente porque todos os incentivos nas empresas giram em torno delas e isso continuará assim por muito tempo.

Apesar de tudo o que disse, torço, profundamente, para estar absolutamente equivocado! No mais, redobrem seus esforços! O desafio é bem maior do que parece à primeira vista.

Pra quem quiser ler a discussão na íntegra, segue o link: http://br.groups.yahoo.com/group/scrum-brasil/message/656
E pra quem quiser se inscrever na lista de discussão Scrum-Brasil, segue o link: http://br.groups.yahoo.com/group/scrum-brasil

Posted in agile, scrum, XP | Etiquetado: , , | Leave a Comment »

Fábricas de… software?

Posted by Matheus Tardivo em janeiro 16, 2008

É impressionante ver que em pleno ano de 2008 existem pessoas que ainda acreditam em fábricas de software. Geralmente, estas pessoas tendem a permanecer alheias as novas metodologias – sei que o termo “novas” foi um pouco forte, afinal, pra ter uma idéia, o artigo “The New Methodology” de Martin Fowler foi escrito no ano de 2000.

Fábricas de software sugerem que os desenvolvedores são apenas recursos que executam tarefas manuais, determinísticas e altamente especializadas. Isso funciona bem para carros, sapatos, mas não para software. A explicação para isso pode se tornar extensa e gera várias discussões, mas, no meu ponto de vista, é algo simples de entender: desenvolver software é essencialmente um trabalho de criação, que se assemelha mais a pintar um quadro ou escrever um livro.

Tentar tornar o trabalho de desenvolvimento de software altamente especializado e determinístico NÃO FUNCIONA!

A especialização é uma teoria que surgiu na revolução industrial e funciona muito bem para o trabalho manual. Nela cada recurso executa uma pequena parte de um trabalho, muito especifico – como apertar parafusos. Neste caso, o recurso pode ser facilmente substituído. No desenvolvimento de software o trabalho é essencialmente um processo de criação, uma arte. Por isso, essa teoria não encaixa.

A forma de especialização mais conhecida na área de desenvolvimento é a separação entre analista e programador. O analista é responsável por estudar os requisitos do sistema e gerar artefatos que transmitam a idéia para o programador – estes artefatos geralmente são diagramas UML (diagramas de classes, diagramas de seqüência, diagramas de iteração) e casos de uso. Em posse desses artefatos, o programador apenas “transforma” tudo isso em código. Simples não? Parece ser. Mas então por que isso não funciona? Aliás, acabei de ler mais um ótimo post do Phillip Calçado sobre este assunto: Quando eu crescer quero ser Analista de Sistemas.

O processo de criação de um software exige que a análise e o desenvolvimento andem o tempo todo juntos e sejam feitos de maneira incremental. A análise é feita a medida que o desenvolvimento evoluí. Algo que foi analisado hoje, pode não ser mais válido daqui uma semana – ou até mesmo num tempo menor.

Para entender como funciona o processo de desenvolvimento incremental, ou melhor, iterativo, precisamos antes nos lembras dos velhos tempos: o estilo cascata.

“O estilo em cascata subdivide um projeto com base na atividades. Para construir software, você precisa realizar certas atividades: análise dos requisitos, projeto, codificação e teste. Assim, nosso projeto de um ano poderia ter uma fase de análise de dois meses, seguida de uma fase de projeto de quatro meses, após a qual viria uma fase de codificação de três meses, seguida de uma fase de teste de mais três meses.
No desenvolvimento em cascata, normalmente existe alguma espécie de transferência formal entre cada fase, mas freqüentemente existem refluxos. Durante a codificação, pode surgir algo que o faça rever a análise e o projeto. Você certamente não deve supor que todo o projeto esteja concluído, quando a codificação começa. É inevitável que as decisões de análise e projeto tenham de ser revistas nas fases posteriores. Entretanto, esses refluxos são exceções e devem ser minimizados o máximo possível.”

Essa definição sobre o estilo em cascata foi tirada do livro UML Distilled: A Brief Guide to the Standard Object Modeling Language de Martin Fowler. Então, nada mais justo que expor a definição sobre o estilo iterativo deste mesmo livro:

“O estilo iterativo subdivide um projeto em subconjuntos de funcionalidades. Você poderia pegar um ano e dividi-lo em iterações de três meses. Na primeira iteração, você pegaria um quarto dos requisitos e faria o ciclo de vida do software completo para esse quarto: análise, projeto, código e teste. No final da primeira iteração você teria um sistema que faria um quarto da funcionalidade necessária. Então, você faria uma segunda iteração tal que, no final de seis meses, tivesse um sistema que fizesse metade da funcionalidade. É claro que o exposto é uma descrição simplificada, mas é a essência da diferença. Na prática, evidentemente, vazam algumas impurezas no processo.
No estilo iterativo, você normalmente vê alguma forma de atividade exploratória, antes que as iterações reais comecem. No mínimo, isso fornecerá uma visão de alto nível dos requisitos: pelo menos o suficiente para subdividi-los nas iterações que se seguirão. Algumas decisões de projeto de alto nível também podem ocorrer durante a exploração. Por outro lado, embora cada iteração deva gerar software integrado pronto para produção, freqüentemente ela não chega a esse ponto e precisa de um período de estabilização para eliminar os últimos erros. Além disso, algumas atividades, como o treinamento dos usuários, são deixadas para o final.
Você pode não colocar o sistema em produção ao final de cada iteração, mas eles devem ter qualidade de produção. Freqüentemente, entretanto, você pode colocar o sistema em produção em intervalos regulares; isso é bom, porque você avalia o sistema antecipadamente e obtém um retorno de melhor qualidade. Nessa situação, muitas vezes você ouve falar de um projeto com múltiplas versões, cada uma das quais subdivididas em várias iterações.”

Parando e refletindo sobre o assunto é interessante observar que muita coisa exposta neste texto e nos links abaixo não são exatamente grandes novidades. Essa é a realidade do desenvolvimento de software. Quem não entende isso ou não quer entender está completamente fora dessa realidade e deveria rever seus conceitos.

Alguns links sobre o assunto:

Posted in agile | Etiquetado: , , | 3 Comments »

Improve It fecha as portas para consultorias em metodologias ágeis

Posted by Matheus Tardivo em dezembro 21, 2007

Uma notícia preocupante – pelo menos pra mim, que estava realmente acreditando no sucesso dessa empresa por causa dos trabalhos com desenvolvimento ágil. Mas que também serve para mostrar as inúmeras dificuldades que esse tipo de metodologia (ou filosofia de trabalho) enfrenta no nosso país. Ou não será só aqui?

Alguns pontos que eu gostaria de salientar: recentemente passei a estudar e defender as práticas de metodologias ágeis, principalmente o XP.
Na equipe que trabalho, como todos também tem interesse em metodologias ágeis, decidimos aplicar práticas do XP no nosso dia-a-dia. Tentamos aplicar o que está ao nosso alcance: programação em par, refactoring, desenvolvimento guiados pelos testes, código coletivo, padrões de codificação, iterações e releases curtos, entre outras. Como a metodologia oficial adotada pela empresa não é XP (dizem que é RUP, mas na verdade é puro Waterfall) temos que procurar oportunidades para utilizar as práticas do XP, e posso dizer que estamos conseguindo. Ficamos satisfeitos (pelo menos eu estou) com os resultados que estamos obtendo com isso.

Mas, quando falamos de metodologias ágeis, existem alguns pontos críticos. Segue abaixo um trecho do texto publicado pelo Vinícius (desenvolvedor de software e fundador da Improve It) falando sobre isso:

“À medida que este ano termina, algumas coisas ficam claras para mim. Primeiro, é preciso admitir que comercialmente XP é muito ruim. Há uma resistência enorme ao seu uso, baseada nas mais diversas interpretações equivocadas. A maioria das pessoas não sabe o que é, mas pelo nome, é melhor nem saber mesmo. Com certeza não é coisa boa. Segundo, não tem certificação, o que é um pecado capital neste país. Terceiro, demanda das pessoas, das equipes, das empresas, um nível de atitude social e comportamental que parece ser avançado demais para o pensamento pequenino que reina nas empresas brasileiras, com raras exceções.”

Pra mim, tudo se resume neste texto: uma boa parte das pessoas que eu converso, mesmo sem realmente entender as propostas do XP, prontamente concluem que é algo ruim. Que não funciona. Quanto a isso, o que fica claro pra mim é que essas pessoas ou pensam que conhecem XP, ou apenas ouviram falar.

Recomendo que todos leiam a notícia na íntegra e tirem as suas conclusões. Fica claro que a atitude que a Improve It tomou não é baseada em problemas ou insucessos causados pelas metodologias ágeis, muito pelo contrário, pois isso deu condições à eles de tomarem esse novo rumo. Apenas mudaram o foco comercial de serviços para produtos – que, com certeza, continuaram a serem desenvolvidos utilizando metodologias ágeis.

Na notícia o Vinícius cita o caso de sucesso da 37signals: “Sem dúvidas esta empresa é, atualmente, nossa principal inspiração.” Pra que não conhece, David Heinemeier Hansson da 37signals é o criador do Ruby on Rails – e diversos outros produtos como o Basecamp.

Mas uma notícia como essa, principalmente com o conteúdo colocado, me deixa um pouco preocupado. Acredito não ser o único a ter essa preocupação pois vi mais pessoas acreditando no modelo de serviços que a Improve It vinha apostando. Segue um trecho de um post do Phillip Calçado num “Momento Mãe Diná 2008“:

“Vai ser o ano das consultorias pequenas. As ImproveIt, TriadWorks e Caelum da vida vão mostrar ao mercado brasileiro o que o internacional já sabe: times pequenos com foco em qualidade são melhores que enormes fábricas de software que simplesmente não conseguem entregar projetos”

Já conhecia a Improve It através dos artigos sobre XP, mas passei a ter admiração através do livro de XP do Vinícius – que virou uma fonte de referência para todos da equipe que trabalho, e pelo movimento para disseminar as técnicas ágeis no Brasil.

Boa sorte e sucesso para o pessoal da Improve It.

Aliás, vale a pena ler o artigo do Danilo Sato sobre essa notícia: Os Valores Ágeis não se Expressam em Palavras, mas em Ações.

Posted in agile, XP | Etiquetado: , , | Leave a Comment »

Don’t call us, we’ll call you.

Posted by Matheus Tardivo em novembro 1, 2007

O padrão Template Method define o esqueleto de um algoritmo dentro de um método transferindo alguns de seus passos para as subclasses. O Template Method permite que as subclasses redefinam certos passos de um algoritmo sem alterar a estrutura do próprio algoritmo.

Basicamente, o padrão consiste na criação de um template para o algoritmo. Mas o que é um template? É apenas um método – ou, mais especificamente, é um método que define um algoritmo como uma seqüência de passos. Um ou mais desses passos podem ser definidos como abstratos e implementados por uma subclasse. Isto assegura que a estrutura do algoritmo permaneça inalterada mesmo quando as subclasses fornecem parte da implementação.

Verifiquemos o diagrama de classes:
TemplateMethod

  • A ClasseAbstrata contém o template method e versões abstratas das operações usadas no template method.
  • O template method utiliza operações primitivas para implementar um algoritmo, mas desconectada da implementação efetiva dessas operações.
  • A ClasseConcreta implementa as operações abstratas, que são chamadas quando o templateMethod() precisa delas.
  • Podem existir muitas classes concretas, cada uma implementando o conjunto de operações exigidas pelo template method.

E o código:
ClasseAbstrata

public abstract class ClasseAbstrata {

	public final void templateMethod() {
		operacaoPrimitiva1();
		operacaoPrimitiva2();
		operacaoConcreta1();
		operacaoConcreta2();
	}

	public abstract void operacaoPrimitiva1();

	public abstract void operacaoPrimitiva2();

	public void operacaoConcreta1() {
		// implementação
	}

	public void operacaoConcreta2() {
		// implementação
	}
}

ClasseConcreta

public class ClasseConcreta extends ClasseAbstrata {

	public void operacaoPrimitiva1() {
		// implementação da operação primitiva 1
	}

	public void operacaoPrimitiva2() {
		// implementação da operação primitiva 1
	}
}

Usando:

ClasseAbstrata classe = new ClasseConcreta();
classe.templateMethod();

Uma forma de controle das extensões de subclasses são os métodos gancho (hook methods, em inglês). É possível então criar um template method que chama os métodos gancho, permitindo um controle do comportamento somente nestes pontos.

Agora um código de exemplo usando o gancho:

public abstract class ClasseAbstrata {

	public final void templateMethod() {
		// Agora a operação está condicionada ao gancho.
		if (gancho()) {
			operacaoPrimitiva1();
		}
		operacaoPrimitiva2();
		operacaoConcreta1();
		operacaoConcreta2();
	}

	public abstract void operacaoPrimitiva1();

	public abstract void operacaoPrimitiva2();

	public void operacaoConcreta1() {
		// implementação
	}

	public void operacaoConcreta2() {
		// implementação
	}

	// Por padrão, o gancho apenas retorna true.
	public boolean gancho() {
		return true;
	}
}

As subclasses podem ou não sobrescrever o gancho. Devem fazer isso apenas se desejam mudar o comportamento padrão, como por exemplo, adicionar alguma condição para a execução da operacaoPrimitiva1.
Exemplo:

public class ClasseConcreta extends ClasseAbstrata {

	public void operacaoPrimitiva1() {
		// implementação da operação primitiva 1
	}

	public void operacaoPrimitiva2() {
		// implementação da operação primitiva 1
	}

	@Override
	public boolean gancho() {
		// Faz alguma verificação
		if (...) {
			return true;
		}

		return false;
	}
}

Mas você deve estar se perguntando: “O que o título deste post tem haver com esse padrão?”. A resposta é simples: muito!
Este título é o Princípio de Hollywood, que traduzido significa: Não nos telefone, nós telefonaremos para você.

O Princípio de Hollywood nos proporciona uma maneira de evitar o “colapso das dependências”. Colapso das dependências é o que acontece quando você tem componentes de alto nível dependendo de componentes de baixo nível que dependem de componentes de alto nível que dependem de componentes laterais que dependem de componentes de baixo nível, e assim por diante (ufa). Quando essa estrutura entra em colapso, ninguém mais consegue entender como o sistema foi originalmente projetado.

Com o Princípio de Hollywood, nós permitimos que componentes de baixo nível se conectem ao sistema através de ganchos, mas são os componentes de alto nível que determinam quando e como eles serão solicitados. Em outras palavras, os componentes de alto nível dizem aos componentes de baixo nível: “Não nos telefone, nós telefonaremos para você.”

É provável que você já tenha detectado a conexão entre o Princípio de Hollywood e o Template method: quando usamos um template method, na verdade estamos dizendo às subclasses: “não nos telefone, nós telefonaremos para vocês”.

Posted in Java, padrões de projeto | 1 Comment »

O meu chefe tem um jatinho. O seu também tem?

Posted by Matheus Tardivo em novembro 1, 2007

Mais uma thread para entrar na história do GUJ. A intenção do tópico era de anunciar o framework Space4J que tem como objetivo “ser um banco de dados simples que vai te permitir trabalhar com Java Collections em memória”.

Acontece que, para dar continuidade a tradição, o assunto do tópico mudou de rumo. Mas, na minha opinião, para um rumo interessante.
A essência da discussão gira em torno de: qual é a verdadeira importância de um projeto ter uma suíte de testes? Mais uma vez, na minha opinião, é MUITO importante para qualquer projeto ter uma suíte de testes.

A maioria dos projetos que trabalhei não tinham uma suíte de testes – apesar de eu não me conformar com isso e desenvolver testes para partes isoladas. O que eu não me engano é da importância que eles representam para um projeto. Como já foi falado, boas práticas de orientação a objetos e “programação defensiva” (!) não basta para garantir que algo que estava funcionando, deixe repentinamente de funcionar por alterações que o sistema sofreu.

Vale a pena ler sobre Test-driven development e Behavior driven development. Mas é bom deixar claro que existe uma grande diferença entre fazer Test-Driven Development e testar. “TDD é sobre modelagem de objetos e especificações, não sobre testes (tanto que Behaviour Driven Development está se consolidando como algo mais eficiente que TDD) apesar de que no final você acaba ganhando uma suíte de testes de graça.” (trecho retirado do post do Phillip – veja o final deste post).

Outra coisa que sempre acontece nesse tipo de discussão são as pérolas que surgem. Para justificar a ausência dos testes, as pessoas apelam pra todo tipo de absurdo: “em um mundo capitalizado não há tempo para testes”, “não agrega nada para o cliente”, ou até mesmo uma das maiores pérolas que já vi: “Agora, se me permite, vou voltar ao trabalho, pois o meu chefe, que também gosta do (coloque aqui um framework sem testes) e tem o seu próprio jato particular e não está nem um pouco preocupado com os testes unitários…”

Deixando um pouco o circo de lado, toda essa discussão incentivou mais um ótimo post do Phillip Calçado – que aliás, está de malas prontas para trabalhar na ThoughtWorks. Leiam: Programadores Profissionais Escrevem Testes, Ponto Final.

Posted in pérolas, testes | 1 Comment »

Don’t talk to strangers

Posted by Matheus Tardivo em outubro 31, 2007

A Lei de Deméter ou o Princípio do Mínimo Conhecimento nos orienta a reduzir as interações entre objetos, limitando-as a apenas alguns “amigos” mais próximos.

No projeto de um sistema, você deve tomar cuidado com o número de classes com que qualquer objeto interage e também com a forma como essa interação ocorre.

Este princípio nos orienta a não criar projetos com um grande número de classes interconectadas, o que faz com que qualquer alteração numa parte do sistema exerça um efeito em cascata sobre outras partes. Um sistema com muitas dependências entre múltiplas classes é um sistema frágil, de difícil manutanção e complexo demais para ser compreendido por outros.

O princípio nos fornece algumas dicas: pegamos um objeto qualquer e, a partir de qualquer método nesse objeto, só podemos invocar métodos quer pertençam:

  • Ao próprio objeto
  • A objetos que tenham sido passados como parâmetro para o método
  • A qualquer objeto que seja criado ou instanciado pelo método
  • A quaisquer componentes do objeto – Pense em “componente” como qualquer objeto que seja referenciado por uma variável de instância. Em outras palavras, esta seria uma relação TEM-UM.

Um exemplo:
Sem o princípio:

public float getTemp() {
	Thermometer thermometer = station.getThermometer();
	return thermometer.getTemperature();
}

Com o princípio:

public float getTemp() {
	return station.getTemperature();
}

Em um outro exemplo:

String nomeFilial = funconario.getDepartamento().getFilial().getNome();

Caso você tenha que navegar muito nos seus objetos você está, provavelmente, com um problema na sua modelagem. Neste caso, talvez o que você teria que fazer seria delegar isso para uma classe de “meio de campo”.

O uso de Padrões de Projeto e outros Princípios OO ajudam na aplicação da Lei de Deméter.

Já que comentei sobre Padrões de Projeto e outros Princípios OO, vou listar abaixo alguns desses princípios:

  • Encapsule o que varia
  • Dê prioridade à composição em relação à herança
  • Programe para interface, não para implementações – Estratégia
  • Tente manter conexões flexíveis entre objetos que interagem.
  • As classes devem estar abertas para a extensão, mas fechadas para modificação.

E alguns padrões:

Claro que existem outros padrões que podem auxiliá-lo e, por isso, recomendo a leitura de livros sobre o assunto.

A Lei de Deméter é uma Rule of thumb e seu uso deve ser priorizado, mas, por diversos motivos, nem sempre podemos utilizá-la.

Embora o Princípio do Mínimo Conhecimento reduza as dependências entre objetos, e estudos tenham comprovado que isso simplifica a manutenção do software, sua aplicação também exige que mais classes “envelopadoras” sejam escritas para lidar com as chamadas de métodos em outros componentes. Isso pode aumentar a complexidade e o tempo de desenvolvimento do software, além de reduzir seu desempenho durante a execução.

Uma boa parte desse texto foi retirado do livro Head First Design Patterns que, com certeza, é uma ótima leitura.

Posted in Java, padrões de projeto | 1 Comment »

Hello world!

Posted by Matheus Tardivo em outubro 10, 2006

Olá pessoal! Vou tentar escrever algo de útil aqui (assim que eu tiver um tempinho).

Pretendo começar colocando um artigo sobre Struts 2 + Spring 2 + JPA + AJAX.
É uma praticamente o mesmo exemplo desse artigo, mas com algumas modificações e comentários.

Até mais.

Posted in Java | Leave a Comment »