Arquivo da categoria: agile

Boas práticas aqui NÃOOOOO!!!!

Todo programador deve aproveitar oportunidades de implementar algo que agrege valor para o projeto e/ou refatorar código legado para otimizar a manutenção do sistema.

Infelizmente em alguns ambientes, principalmente onde não há testes … o código funcionando por pior que esteja deve ficar como está, não se modifica uma virgula, ou ajax é considerado ‘firula’ do qual se evita utilizar … creio que para programadores ignorarem técnicas da nossa profissão como ajax, melhoria continua e refatoração, é um sinal que algo está faltando.

Esse foi a minha constatação ao participar de dois projetos PHP , onde percebi a diferença entre desenvolvedores e empresas(que utilizam PHP comparado ao Ruby), principalmente sobre teste unitário, ao convesar a respeito do assunto, ouvi respostas como: “aqui não rola teste unitário”, ou, “o que é teste unitário?”, e ainda, “não vimos utilidade no teste unitários, na verdade, achamos que iriam mais nos atrapalhar”.

Então procurei anotar algumas situações nestes projetos onde os testes trariam benefícios, que seguem abaixo:

  • Em uma tarefa para uma correção de bug e criei alguns teste unitários, e mostrei para o responsável por aprovar as alterações, foi onde ouvi “Teste unitário aqui não rola!”, então ele pediu para excluir os testes do branch e subir apenas a correção. Alguns dias depois, quando surgiu um outro bug, no mesmo método, ele me pediu para testar bem as modificações antes de colocarmos em produção, se fazer isso manualmente para alguém que conhece todo o sistema não é eficiente, imagina para alguém novo no projeto.
  • “Métodos pequenos não são necessário, aqui adicionamos novos requisitos e comentamos”. Havia métodos com mais de cem linhas e quando é necessário uma nova funcionalidade no sistema a regra é adicionar direto nos métodos existentes.. mas quando ocorreu um bug no meio de um destes métodos, com vários ‘ifs’ aninhados, que ninguém conseguiu identificar a causa do bug, o bug foi consertado, extraindo um trecho do algoritmo, mas a real motivo do erro não foi detectado.
  • Em outra situação, ao desenvolver um script para buscar o geocode no gmap, estava sendo excedido o limite de consultas na API, travando o desenvolvimento da solução, e os teste (manuais) do script, obrigando a deixar essa tarefa para o dia seguinte. Nessa situação, mocks e stubs poderiam ser a solução para não interromper o desenvolvimento.
  • Implementaram um padrão para codificação de código (do qual foi recentemente definido na empresa), como tabs, nome de funções, e espaços agora devem seguir o padrão, mas há muito código feito antes de se definir o padrão do qual esbarramos quando vamos corrigir um bug, que a regra é modificar apenas o código que a tarefa pede, ou seja, não faça refatoração, se você ver algo errado, deixe do jeito que está, tudo isso por medo de derrubar um sistema do qual a única maneira de verificar se algo deu errado é através dos logs de erros do sistema !!  Claro que a empresa tem prejuízo se algum desenvolvedor fizer algo errado, mas um projeto que não é melhorado constantemente torna-se difícil de gerenciar e diminui a produtividade do time, talvez irá dar ainda mais prejuízo .

Minha conclusão ao retornar ao PHP depois de ruby, existem diferenças de linguagem e plataforma, mas a maior diferença é a cultura da comunidade de desenvolvedores, infelizmente a maioria dos programadores PHP não estão preocupados com boas práticas.

Anúncios

Agile Vale 2010 .. eu fui

O time de desenvolvimento web da Canção Nova esteve no Agile vale 2010 e tivemos uma grata surpresa durante o evento, fomos citado na palestra de “cultura de aprendizagem” da Bluesoft devido ao nosso grupo de estudo… \o/\o/\o/

    Time de desenvolvedores web da Canção Nova e o pessoal da Bluesoft

Time de desenvolvedores web da Canção Nova e o pessoal da Bluesoft

As palestras foram ótimas e tivemos dificuldades em escolher qual participar, destaque para a mesa redonda que discutiu temas bem interessantes.

post original : http://blog.cancaonova.com/desenvolvimentoti/agile-vale-2010-nos-fomos/

CodingDojo na FATEC-GT

Rolou o dojo na faculdade (Fatec de Guaratinguetá) … foi show de bola =D

Depois de vencida as dificuldades para liberar a infraestrutura, finalmente, aconteceu sábado (28/08/10)  o primeiro dojo na FATEC-GT .. o primeiro MESMOOO, pois pelo que sabemos ainda tinha ocorrido um dojo nesta faculdade, e se bobear foi única FATEC de todo estado a ter um dojo 🙂

grupo de estudantes da fatec no dojo

Deu trabalho, foi um pouco burocrático mas no final deu td certo

Este é o segundo grupo de dojo que reuno…  e parece que estou pegando o jeito .. heheheh

Levei dois katas, e o escolhido foi o kataFizzBuzz, um kata simples perfeito para introduzir os conceitos do dojo, TDD e pair programming.

Alguns dados do encontro:

Tenho que agradecer a FATEC que cedeu a sala e o projetor, e ao professor Leandro Guarino que deu uma força para conseguirmos a autorização da FATEC, e ao Bruno que levou o notebook dele . OBRIGADO 😉

O Alvaro criou um blog para falar a respeito dos encontros de dojo na Fatec e fez um post a respeito do primeiro encontro, http://dojofatecguara.wordpress.com/2010/08/30/primeiro-dojo-sabado-28-08-2010/

E como eu disse no post anterior  o mais difícil foi começar

É isso ai, até o próximo dojo 😉

Meu primeiro code dojo

Foi meu primeiro dojo, o primeiro dojo da empresa e o primeiro dojo da equipe…

Aconteceu terça-feira (10/08/10)  na empresa, e como diz o ditado a primeira vez a gente nunca esquece..  eu terei boas recordações pq foi ótimo =D

Pra quem não sabe Coding dojo (ou code kata) é um encontro onde os participantes tem o objetivo de praticar programação e trabalho em equipe, utilizando TDD (assunto do qual recomendo a leitura do excelente livro de TDD do Kent Beck) e qualquer linguagem de programação (preferencialmente aquela que vc ainda não domina).

equipe de programadores da Canção Nova

equipe de programadores da Canção Nova

Agendamos o coding dojo com uma semana de antecedência mas ainda sim por pouco não foi cancelado, devido algumas dificuldades com a configuração do notebook, as chaves da sala e o empréstimo do projetor… mas apesar das dificuldades, todos os participantes foram atrás e fizeram o dojo acontecer.

Devido as dificuldades mencionadas iniciamos com uma hora de atraso, (9:10hrs), conseguimos reservar a sala das 8-10 hrs, então tínhamos apenas mais uma hora, já havíamos escolhido o problema que foi o Secret Santa , deveríamos ter feito um brainstorm inicial sobre o problema, mas devido ao atraso não fizemos e isso nos fez falta, fomos direto programar a solução.

Apesar de não termos evoluído muito com a solução, o resultado foi excelente, logo depois do primeiro dojo, já percebo que alguns agora estão receptivos em aceitar o desafio e a nova cultura agile, e nem preciso mencionar os benefícios de ter toda equipe programando o mesmo código.

Inicialmente faríamos quinzenalmente, mas ao final do encontro todos foram unânimes em marcar logo o próximo dojo em uma semana e deixar o encontro semanal =D

Parece que o mais difícil foi começar,  agora só falta organizar um dojo na faculdade (Fatec de Guaratinguetá), alguém me ajuda ?