Blog da Improve It 
Publicado por Vinicius Manhães Teles há
aproximadamente 1 ano.
Acaba de ser publicado o podcast mais divertido que já gravei: o Improvecast 19. Dessa vez entrevistei a equipe de desenvolvimento da Ancar (veja as fotos), que atua na gestão de shopping centers e é cliente dos serviços de mentoring da Improve It. A Ancar vem trabalhando com XP desde o início de 2005. Durante dois anos os esforços de desenvolvimento estiveram concentrados em Java e mais recentemente a equipe passou a utilizar também Ruby on Rails.
Dessa vez, além do podcast, você também pode ler o estudo de caso da Ancar e ver as inúmeras fotos da equipe da Ancar trabalhando com XP. São nada menos que doze álbuns de fotos da Ancar. Aproveite!
Esses foram os assuntos tratados no Improvecast 19:
- Quem é a Ancar e o que ela faz?
- Como vocês conheceram o XP?
- Que tipo de problemas vocês tinham antes de adotar o XP e o que os levou a querer adotá-lo?
- Que abordagem vocês utilizaram para adotar o XP e quando começou a adoção?
- Qual era a plataforma de desenvolvimento utilizada na época em que vocês começaram com o XP?
- O que motivou vocês a adotarem o Java?
- Que treinamentos vocês fizeram antes de iniciar o primeiro projeto XP e como eles foram conduzidos?
- Depois do período inicial de mentoring e treinamento, vocês deram início ao primeiro projeto XP na Ancar, o Ancar2Go. O que é o Ancar2Go e que benefícios de negócio eram esperados dele?
Tela do Ancar2Go com a planta de um dos shoppings administrados pela Ancar.
- Quantas pessoas havia na equipe do Ancar2Go?
- Quem atuava como cliente desse projeto?
- Qual o tamanho das iterações?
- Que práticas do XP mais se destacaram nesse projeto?
- Que tipo de transformações vocês notaram no relacionamento com o cliente a partir da adoção do XP?
- O que mudou no entrosamento e motivação da equipe?
- Um dos aspectos que mais me marcaram no desenvolvimento do Ancar2Go foi a troca de abordagem que ocorreu logo no início do projeto. Começamos pensando em desenvolver um sistema web. Entretanto, à medida que o projeto avançou umas duas semanas, começou a ficar claro que um sistema desktop seria mais adequado. Lembro-me até hoje de uma reunião de planejamento semanal na qual observei, pela expressão do do rosto do Rafal, que ele não estava à vontade com a maneira como o sistema estava sendo desenvolvido. Então, pedi a ele que expressasse sua opinião, o que ele fez muito bem, levando-nos ao caminho que se revelou corretíssimo: uma aplicação desktop. Vocês acreditam que a estrutura de trabalho do XP, com suas iterações curtas, foco em adaptar-se a mudanças, re-planejamento a cada início da iteração e envolvimento de todos no planejamento, contribuiu para identificarmos cedo que estávamos indo no caminho errado?
- No início de 2006, após diversas tentativas de contratar desenvolvedores aqui no Rio, vocês decidiram tentar algo novo: importar profissionais do Paraná, recém-graduados, que estivessem dispostos a mudar-se para um apartamento próximo à Ancar, no Rio de Janeiro. Nesse processo, vocês adotaram a programação em par como forma de avaliar os candidatos. Vocês poderiam falar um pouco mais sobre o que foi feito nesse sentido?
- Depois da contratação, como a programação em par contribuiu para o trabalho dos novos desenvolvedores?
- Um aspecto muito forte aí na Ancar é a questão do desenvolvimento orientado a testes. No último projeto que vocês fizeram em Java, a taxa de cobertura dos testes era extremamente elevada, bem próxima de 100%. Agora, com dois anos de uso permanente do XP, qual a visão que vocês têm sobre a criação de testes automatizados ao longo do desenvolvimento? Eles realmente fazem a diferença e contribuem para elevar a qualidade dos produtos gerados?
- Outro aspecto significativo aí na Ancar é o nível de automação dos builds. Explique um pouquinho como é conduzido o processo de integração contínua e qual é o papel do Bob Esponja nessa questão. :-)
- O entrosamento da equipe sempre foi uma preocupação de todos nós aí na Ancar. Uma das tradições que criamos aí foi o almoço semanal com boliche. Vocês poderiam falar um pouco mais sobre ele?
- Recentemente vocês se viram diante da necessidade de desenvolver o primeiro sistema web. Diante disso, foi preciso tomar uma decisão sobre a plataforma. Vocês estudaram várias soluções no mundo Java, mas acabaram optando por sair do Java e utilizar Ruby on Rails. O que os motivou a fazer essa migração?
- Vocês podem falar um pouco sobre esse novo projeto?
- Vocês acham que está valendo a pena trabalhar com o Rails?
- O que vocês mais têm gostado a respeito do Rails?
- Quais têm sido os maiores desafios e como eles vêm sendo tratados?
- Recentemente vocês, em conjunto com o Tapajós, aqui da Improve It, desenvolveram um plugin para o Rails. O que ele faz?
- Finalmente, quais são seus planos para o futuro em termos de desenvolvimento ágil e Ruby on Rails?
Além de escutar o podcast, veja as fotos. E lembre-se, quem quer aprender mais sobre desenvolvimento ágil deve ficar atento. Em breve lançaremos nossos primeiros treinamentos abertos ao público. Fique sabendo de todos os detalhes mais cedo e concorra a descontos. Basta cadastrar seu email para receber todos os detalhes. Cadastre-se.
Tags agile, brazilianrails, fotos, java, podcast, rails, teste, workshop, xp | 3 comentários
Publicado por Vinicius Manhães Teles há
aproximadamente 1 ano.
Acaba de ser publicado o Improvecast 18 que traz o surpreendente relato de um cliente dos serviços de mentoring da Improve It, a Paggo, que desenvolveu um sistema de cartão de crédito usando Extreme Programming do início ao fim. Entrevistei Mauricio Hermogenes, Diretor de Tecnologia da Paggo. Ele descreveu o Oi Paggo, um sofisticado sistema de "cartão" de crédito utilizando celulares desenvolvido em parceria com a operadora de telefonia Oi.
O Oi Paggo foi desenvolvido sobre a plataforma Java e XP foi usado como metodologia de desenvolvimento, o que, segundo a Paggo, permitiu que o sistema fosse implementado em tempo recorde. O Oi Paggo já está em uso em diversas cidades brasileiras e sua receptividade está superando as próprias expectativas da Paggo, como o Mauricio explica no podcast.
Fonte: http://www.oipaggo.com.br
O Oi Paggo talvez seja hoje um dos produtos mais amplamente utilizados desenvolvidos em XP no Brasil. Trata-se de um projeto inédito, tanto em termos do negócio (cartão de crédito via celular), quanto em termos da metodologia de desenvolvimento. Portanto, esse podcast, além de ser muito instrutivo, é também um ótimo case para demonstrar o potencial do Extreme Programming no mercado brasileiro.
Esses foram os assuntos tratados no Improvecast 18:
- Quem é a Paggo e o que ela faz?
- O que é uma solução de private label?
- O que é o Oi Paggo?
- Como funciona o Oi Paggo?
- Quais as vantagens do Oi Paggo para os compradores?
- Qual o custo do Oi Paggo para os compradores?
- O que um comprador deve fazer para habilitar seu Oi Paggo?
- Quais as vantagens do Oi Paggo para os lojistas?
- Qual o custo do Oi Paggo para os lojistas?
- O que um lojista deve fazer para habilitar seu Oi Paggo?
- Quando a Paggo foi fundada e qual era seu objetivo?
- Quando e como teve início o projeto do Oi Paggo?
- Quando o Oi Paggo foi lançado como piloto?
- Quando o Oi Paggo foi lançado em nível nacional?
- Como está sendo a receptividade do mercado?
- A Paggo utilizou Extreme Programming desde que começou a desenvolver sua plataforma de cartão de crédito, em 2004. O que motivou a opção pelo XP?
- Como se deu a implantação do XP no início?
- Que práticas foram utilizadas no início?
- Quais foram mais fáceis de adotar?
- Quais foram os principais benefícios observados neste primeiro momento?
- Quais as principais dificuldades?
- Em 2005 a Paggo deu início ao desenvolvimento do Oi Paggo e a Improve It foi chamada para ajudar a dar continuidade na implantação do XP, através de seu serviço de mentoring. Que novidades foram sugeridas e implantadas nesse momento?
- Como foi conduzido o trabalho de mentoring?
- Na opinião de vocês, qual a importância desse tipo de trabalho?
- Quais foram os principais benefícios observados?
- Que práticas foram mais fáceis de utilizar?
- Quais foram mais difíceis?
- Você poderia falar um pouco sobre a arquitetura tecnológica da Paggo?
- Quantas pessoas havia na equipe de desenvolvimento no início do projeto Oi Paggo?
- Quantas pessoas fazem parte dessa equipe atualmente?
- Como vocês lidaram com o desafio de contratar pessoas capacitadas nessas tecnologias?
- Como vocês conduziram o treinamento dos novos contratados?
- Qual foi a importância da programação em par nessa questão?
- Em 2005, enquanto eu estava fazendo mentoring com a Paggo, utilizavam-se iterações semanais para o desenvolvimento do Oi Paggo. Quem atuava como cliente nas reuniões de planejamento?
- Como eram usados os cartões nessas reuniões?
- Como os cartões eram estimados?
- Como eles eram acompanhados ao longo da iteração?
- Uma coisa interessante que aconteceu na Paggo é que os cartões saíram da área de desenvolvimento e foram adotados por outros departamentos. Você poderia falar um pouco mais sobre como os cartões passaram a ser usados em toda a empresa?
- Na sua opinião, o que motivou tamanha aceitação e uso dos cartões?
- No momento, qual o tamanho da iteração de vocês? Continua sendo semanal?
- Em 2005, fazíamos retrospectivas ao final de cada iteração. Na opinião de vocês, que benefícios elas geravam?
- As retrospectivas continuam sendo usadas atualmente?
- Um dos desafios em se trabalhar com uma equipe grande é a reunião diária, o stand up meeting. Ela pode acabar se alongando demais caso a equipe seja grande. Como vocês têm lidado com essa questão?
- Enquanto estive com vocês, um aspecto que trabalhamos muito foi a questão de automação de testes, utilizando fortemente mock objects e outros conceitos. Quais foram as principais inovações nessa área, comparando-se com a forma pela qual vocês começaram a adotar o XP em 2004?
- Como a automação de testes vem sendo tratada atualmente?
- Na opinião de vocês, qual a importância da automação dos testes e de práticas como desenvolvimento orientado a testes para a qualidade do produto final?
- Vocês têm conseguido manter o design organizado através de sucessivas refatorações do código?
- Qual tem sido a importância dos testes automatizados para viabilizar as refatorações?
- Outro ponto que trabalhamos muito foi a questão da automação de builds e integração contínua. Quais foram as principais mudanças realizadas nessa área?
- Como ela vem sendo tratada atualmente?
- Como vocês têm lidado com o desafio de colocar mudanças no ar rapidamente, em um sistema que já está em plena utilização?
- A Oi, como quase todas as grandes empresas brasileiras, baseia seu processo de desenvolvimento em métodos tradicionais de gestão de projetos, tais como aqueles disseminados pelo PMBOK. Como vocês vêm lidando com essa diferença cultural entre o modelo de desenvolvimento da Paggo, baseado no XP e o modelo de gestão da Oi, baseado no PMBOK?
- O XP contribuiu de alguma forma para o bom relacionamento entre a Paggo e a Oi?
- Na opinião de vocês, qual tem sido a importância da utilização do XP no que se refere à motivação da equipe de desenvolvimento e habilidade da Paggo em reter seus profissionais?
- Que tipo de adaptações vocês tiveram que fazer no XP para que se adequasse às particularidades da Paggo?
- Quais são os principais desafios que vocês estão vivenciando no momento, tanto no nível do negócio, quanto no técnico?
- Como está sendo a receptividade do Oi Paggo no mercado e o que a Paggo está preparando para o futuro próximo?
Tags agile, java, podcast, teste, xp
Publicado por Marcos Tapajós há
aproximadamente 1 ano.
Estou escrevendo essa errata pois algumas pessoas utilizam RSS e podem não ler a correção que eu fiz no meu ultimo post.
Escrevi:
1 - Algo impossível (nunca consegui fazer) em java e simples em Ruby é testar métodos estáticos.
Mas o que eu realmente quis dizer foi:
1 - Algo impossível (nunca consegui fazer) em java e simples em Ruby é "mockar" métodos estáticos.
Tags java, ruby, teste | 3 comentários
Publicado por Marcos Tapajós há
aproximadamente 1 ano.
Acho que não é novidade para ninguém que a Improve it está apostando em Ruby, mas especificamente no Ruby on Rails, e que eu abracei essa aposta e cada dia estou mais feliz de trabalhar nessa linguagem e com esse framework. Cada vez que comento sobre o Rails com meus amigos, ou qualquer outra pessoa, sempre escuto a mesma pergunta, "É tão poderosa quanto o Java?". Engraçado que depois que eu discuto por alguns minutos sobre essa pergunta sempre vem a mesma pergunta, "dá para usar para tudo ?".
Eu sempre explico que não acredito que em computação exista um canivete suíço e que faz parte de um bom profissional saber diferenciar onde se aplicar uma linguagem (ou uma tecnologia) em detrimento a outra. Posso estar enganado, mas o que eu vejo pelo mercado é que as pessoas procuram se enraizar em alguma linguagem achando que todos os seus problemas estão resolvidos e se esquecem que as vezes podem estar resolvendo um problema mas passando por vários outros, ou gastando demais com excesso de complexidade.
Hoje eu li um post do Thiago Arrais e pelo visto não sou o único que acha que cada linguagem tem um objetivo e uma aplicabilidade. Gostei muito desse post pois além dele tratar essa forma de pensar ele discute sobre Design Patterns com uma abordagem super interessante mostrando o quê realmente são os padrões de projeto e como eles acabam se incorporando as novas linguagens.
A forma como a maioria das pessoas encaram os Design Patterns é uma coisa que me incomoda profundamente. Frequentemente eu vejo as pessoas escreverem códigos para usar os Design Patterns ao invés de identificarem no seu código semelhanças com os padrões conhecidos e então aplica-los. Pela minha experiência essa pratica, na maioria dos casos, introduz uma complexidade desnecessária ao software e tenho certeza que toda complexidade desnecessária além de ser um desperdício é mais código e que mais código implica em mais chances de bugs.
Não estou querendo dizer que os padrões são ruins, apenas que devemos usa-los da forma correta e quando forem necessários. Participo de várias listas e sempre que vejo alguém perguntar sobre material para aprender uma linguagem várias pessoas indicam livros, artigos e sites sobre Design Patterns e me questiono se a pessoa precisa saber padrões para poder usar uma linguagem. Será que não seria mais proveitoso ela descobrir um problema, entender as limitações da linguagem e só então começar a aplicar essas gambiarras ?
Sim, padrões são gambiarras ! Gambiarras com nomes bonitos !
Comecei a tentar explicar essas minhas afirmações e vi que não consegui falar nada diferente do que o Thiago Arrais falou em seu post e por isso mesmo vou citar um paragrafo desse post dele.
"Um padrão não é nada mais que uma gambiarra para contornar fraquezas de algumas linguagens. Estas fraquezas são completamente naturais. Não se espera que toda linguagem consiga dar suporte a todo tipo de construção, mas que seja boa naquilo a que se propõe. Já que não há como ter suporte direto a tudo que se possa pensar, as pessoas começam a criar construções padronizadas para cada tipo de trabalho. Estas construções são os padrões."
O que eu quero explicar para todos que se questionam sobre qual linguagem é melhor do que a outra é que isso não existe e que cada linguagem tem seu objetivo e provavelmente surgiu dentro de um contexto diferente das outras. Indo um pouco além, que não existe linguagem perfeita, isto é, um canivete suíço.
Tags java, rails, ruby | 3 comentários
Publicado por Vinicius Manhães Teles há
aproximadamente 1 ano.
Como eu havia mencionado no post anterior, o xispeiro Vitor Pamplona merece um artigo só para ele. Por que? Porque com apenas 23 anos, ele provavelmente já contribuiu mais para a comunidade de desenvolvimento de software do que você em toda a sua vida! E também porque exemplos merecem ser divulgados, admirados e seguidos.
Que tal uma "breve" lista de seus projetos?
Além de todos esses projetos, Vitor também administra o JavaFree.org, uma das maiores comunidades Java do mundo. E, como se não bastasse, ainda consegue arrumar tempo para escrever artigos, tutoriais e fazer seu mestrado. Em resumo, Vitor é o cara!
O fato de ter feito todos esses ótimos projetos com apenas 23 anos já é admirável por si só, mas existe um "detalhe" importante. Todo esse trabalho é voluntário. Nenhuma empresa pagou ao Vitor para que ele desenvolvesse esses projetos e, ainda assim, ele lhes dedicou tempo, esforço, noites e fins-de-semana.
O fato de alguém se dedicar tanto, sem nenhuma recompensa financeira imediata, deveria ser estudado com mais atenção pelas empresas. O que o motiva? O que o inspira? O que faz com que ele se dedique tanto? Será que a sua empresa é capaz de motivar seus funcionários da mesma forma? Ou será que ela faz tudo para desmotivá-los?
Uma coisa eu sei. Todo esse trabalho deve lhe gerar muito orgulho. A possibilidade de fazer uma trabalho bem feito, do qual se possa ter orgulho é um tremendo motivador para desenvolvedores de software. Não é o único, mas é essencial. Entretanto, infelizmente muitas empresas só conseguem fazer o oposto. Impedem que seus desenvolvedores façam um trabalho de alta qualidade.
Criam prazos impossíveis, não conseguem definir prioridades, formulam contratos que impossibilitam a realização de um trabalho bem feito e, para compensar, tentam segurar as pessoas pelo salário. Pois, deveriam olhar o exemplo do Vitor e de outros tantos que se dedicam a criar software de qualidade, pois no mundo do software livre, eles têm liberdade para fazer isso! Não precisam de CMM, não precisam de ISO, não precisam de lero-lero, pois têm liberdade para decidir a melhor forma de atingir seus objetivos. Pense nisso!
Vitor, meus parabéns pelo excelente trabalho. Você é motivo de grande orgulho para a comunidade Java brasileira. Que seu exemplo seja amplamente divulgado e seguido! Precisamos de mais gente como você nesse país!
PS: O Vitor não sabia desse artigo e não foi consultado para a formulação do mesmo. Ou seja, essa é uma homenagem genuína, sem que ele jamais tivesse me pedido para comentar qualquer coisa a seu respeito.
Tags java | 20 comentários
Publicado por Vinicius Manhães Teles há
aproximadamente 1 ano.
Chad Fowler, autor do livro My Job Went to India: 52 Ways to Save Your Job escreveu um post recentemente sobre a demanda e procura de certas habilidades na área de TI. No livro, ele fala sobre o que um desenvolvedor pode fazer para se manter valioso no mercado ao longo do tempo.
Aqui no Brasil, há pouco mais de dez anos, investir em Java não pareceria fazer muito sentido, já que poucas empresas ofereciam oportunidades de trabalho nessa área. Mas, aqueles que decidiram investir, se deram bem nos anos seguintes, já que a demanda por profissionais cresceu e hoje é bastante elevada. Portanto, o melhor que um desenvolvedor pode fazer hoje é continuar apostando suas fichas em Java, .Net, Oracle e outras tecnologias populares por aqui, certo?
Depende. Talvez isso torne o profissional valioso hoje, mas não é uma garantia para o futuro próximo. Nossa área muda rapidamente e tentar antecipar tendências é importante.
Atualmente o mercado brasileiro parece estar razoavelmente equilibrado na oferta e demanda de profissionais Java. Tem muito trabalho na área, mas também tem muita gente fazendo isso. Portanto, ser um desenvolvedor Java possivelmente está deixando de ser um diferencial na carreira de alguém. Ou talvez ainda seja durante algum tempo, mas possivelmente não por muito tempo. Eventualmente, a oferta ultrapassa a demanda e os salários começam a estagnar.
O que acontece então? Novas tecnologias surgem e as empresas começam a adotá-las. Um novo perfil de profissionais começa a ser necessário. Quem se dá bem? Quem conseguiu antecipar as tendências e se preparar.
Nos próximos anos, acredito que o mercado brasileiro começará a buscar cada vez mais profissionais com conhecimentos em Python, Ruby, Ruby on Rails e metodologias ágeis. Isso já está acontecendo lá fora há algum tempo e vai começar a se intensificar por aqui. Se isso for verdade e você começar a se preparar desde já, estará em condições de brigar por oportunidades nessas áreas e, eventualmente, receber mais do que conseguiria em um emprego com Java, visto que a oferta de profissionais qualificados não será tão grande.
Chad Fowler fez uma apresentação chamada Don’t Follow the Lemmings, na qual ele fala bastante a respeito de decisões na carreira que podem ajudar um desenvolvedor a se manter sempre valioso. Veja o vídeo da apresentação.
No nosso caso, por exemplo, estamos investindo em Ruby. Isso significa que as oportunidades de trabalho que criaremos no futuro próximo serão associadas a essa tecnologia e não mais a Java. Somos apenas uma empresa no meio de tantas outras, mas acredito que o movimento pelo qual estamos passando não tardará a chegar a outras organizações. Fique atento!
Tags agile, java, rails, ruby | 12 comentários
Publicado por Vinicius Manhães Teles há
aproximadamente 1 ano.
Ontem, após ler o artigo sobre janelas quebradas, o Rafael MVC, do grupo rails-br fez uma ótima pergunta: "100% de cobertura não é muito caro? Muitas vezes é desnecessário ter 100% de cobertura. O que você acha?"
Acredito que pode ser caro, ou barato, dependendo da forma como a questão é encarada e da tecnologia empregada. Na parte tecnológica, é mais fácil manter 100% de cobertura em Ruby que em Java, por exemplo. Seja como for, acho que o ponto fundamental é a forma como encaramos desenvolvimento de software.
Conheço algumas pessoas que estão sempre em forma. Não têm barriga, não têm problemas de saúde, e quase não se vê gordura pelo corpo. Ainda assim, elas fazem exercícios freqüentemente e comem pouco. Por que fazem isso, se não precisam? Porque se não mantiverem bons hábitos alimentares e se exercitarem freqüentemente, deixarão de ter um bom preparo físico e começarão a acumular gordura. Chamo isso de "paradoxo do atleta".
Em software acontece o mesmo, se você não exercitá-lo constantemente, através de uma bateria de testes automatizados, ele terá baixo condicionamento e não será tão saudável quanto o software "malhado" que está sempre sendo exercitado.
Qual o problema disso? Pense em uma pessoa obesa, como a da foto acima. Por ter baixo condicionamento, sua pressão sobe e seu batimento cardíaco se acelera quando passa por qualquer tipo de estresse. Já um atleta, se comporta de forma diferente. Diante de um estresse, sua pressão e seus batimentos cardíacos quase não se alteram.
Software é um organismo que enfrente os mais diversos tipos de estresses permanentemente. Ele se manifesta na forma de mudanças. Quando uma mudança é introduzida em um sistema, seu "batimento cardíado" e sua "pressão" podem variar abruptamente, ou permanecer estáveis dependendo de seu condicionamento. Sistemas bem testados, com elevada cobertura de testes, são como atletas muito bem preparados. Mudanças podem ocorrer, mas raramente irão comprometer o bom funcionamento e a boa saúde do software.
Trabalhando com TDD há alguns anos, comecei a notar o que chamaria de "paradoxo dos testes". Os testes automatizados que crio raramente detectam bugs! Não porque eles sejam ruins, ou pouco abrangentes. Simplesmente é raro introduzir um bug quando se trabalha com TDD. A forma de pensar se altera e leva você a criar código sem erros a maior parte do tempo.
O exercício de criar os testes é o que leva à baixa incidência de bugs. Então, se os testes raramente detectam erros, eu poderia deixar de produzi-los, certo? Aí é que está o paradoxo. Se eu não os escrever, começarei a introduzir mais bugs, porque o segredo está no exercício. É a mesma coisa com o corpo humano. Uma pessoa que esteja em forma aparentemente não precisaria se exercitar. Mas, se ela parar de se exercitar, começará a precisar!
Outra questão crítica na saúde de um software é a forma como ele é alimentado.
Você é o que você come. Portanto, se você só come porcaria, sua saúde tende a ser precária. Por outro lado, se você mantém uma dieta saudável, seu corpo tende a se manter em forma. Com nossos sistemas é a mesma coisa. Alimentá-los com gambiarras, código duplicado, métodos ilegíveis e outras coisas pavorosas é o que leva, gradualmente, à criação de um aplicativo moribundo, incapaz de ser alterado facilmente e propenso aos mais diversos tipos de defeitos. Portanto, alimente seu sistema com código saudável e bem testado.
Para fechar, relembrando um outro artigo fique atendo ao que acontece gradualmente com seu código, pois mudanças graduais são mais difíceis de serem notadas. Quando engordamos, fazemos isso um pouquinho a cada dia. Cada pequena extravagância diária leva o ponteiro da balança para o alto. Algumas gramas diárias à mais, se tornam muitos quilos depois de algumas semanas, ou alguns meses. Com o código é igual. Não é uma gambiarra que irá matá-lo. É a sucessão de pequenas gambiarras que vamos introduzindo a cada dia que condena nosso software ao caos e nos condena a dias estressantes tentando contê-lo.
Tags agile, java, qualidade, ruby, teste | nenhum comentário
