Archive for the 'pragmatic waterfall' Category

26
jun
08

Resenha do livro Pragmatic Unit Testing

Olá a todos !

Sei que estão estranhando … perceberam que não tem Waterfall no título ? Pois bem, hoje não vou chorar e digo mais, vou até fingir que não vivo num Waterfall e vou falar sobre TESTES ! Tá bom, sei que enfatizei demais, só vou fazer uma resenha sobre este último livro que li mesmo.

Pragmatic Unit Testing

Numa leitura leve e até divertida (sou nerd mesmo), os autores abordam conceitos práticos de testes que não estão ligados diretamente ao JUnit, e sim a “Filosofia de Testes”. O legal que os principais conceitos são apresentados com acrônimos como “Right BICEP”, “CORRECT Boundary Conditions”, “A TRIP”, MockObjects e etc. Depois da passagem por todos esses acrônimos, os próximos capítulos atacam temas como, onde colocar os testes, design dos testes e etc.

Isso pode parecer estranho, mas de todos os capítulos o que eu mais gostei foi do primeiro, a Introdução, talvez porque no momento estou com a água do waterfall até o pescoço, e nele os autores colocam as dicas de como contra-argumentar as desculpas para não fazer testes. Exemplos dos tópicos, “Por que devo me importar com testes ?” e “Desculpas para não testar”, parece que os autores realmente conhecem o lado negro da força. Por sinal, achei este último tão interessante, que estou pensando em pedir permissão para traduzi-lo e postar aqui, se alguém souber o caminho das pedras e quiser ajudar eu peço a gentileza de entrar em contato.

Gostei muito do livro, o considero uma ótima referência sobre o tema, veja bem, referência, pois se queres uma biblia do JUnit, descarte-o. Sei que muitos da nossa área não conhecem nada sobre o assunto, e um ótimo começo seria por ele.

Agora, voltando um pouco pra minha (e de muitos) realidade cruel, antes de ler o livro eu imaginava (ou sonhava ?) que o sistema atual em que trabalho, poderia ser implantado testes, agora, com uma visão mais pragmática, tenho certeza que estava certo, só que mirando na camada errada. Aqui, a maioria da lógica (uns 90%) está em PL/SQL no banco, e a melhor maneira de implantar testes seria começando com um PL/SQLUnit … mas aí já é assunto pra outro post. Ahh, ainda não pesquisei, mas deve existir com certeza.

Chegando ao fim do livro …

Uma parte chata do livro foi quando terminei de lê-lo, confesso que fiquei com uma vontade de “quero mais” e acabei ficando com a impressão de que só li a ponta do iceberg sobre o tema. Sugestões de mais livros sobre o tema, são bem vindas !

04
jun
08

TPW – Dicas para o Desenvolvedor

Tradução rápida do diálogo:

Chefe (com chifrinhos): Por que você levou seis meses para completar esta simples tarefa ?

Dilbert: Por causa das suas mudanças contínuas, sua comunicação confusa e seu pequeno expediente de trabalho.

Chefe (com chifrinhos): Estou procurando por alguma coisa mais parecida como você sendo preguiçoso.

Hello hello hello ! Estas tirinhas do Dilbert estão de matar ultimamente. E já pra avisar, o TPW significa The Pragmatic Waterfall, um novo termo para o que buscamos aqui neste blog, ajudar quem sofre com o Waterfall ! Ok, isso inclui a mim mesmo.

Quem vive num malditodigno ambiente Waterfall já deve ter vivenciado muito disso que ocorreu acima, o gerente “junior” procurando uma desculpa de porque o gant chart está vermelho para repassar ao gerente “pleno” que este repassará ao “senior junior” e que este repassará “senior pleno” … bom, já entenderam até onde a desculpa vai chegar.

Na tentativa de transformar este post de “muro das lamentações” para Pragmatic Waterfall, vamos as dicas didáticas (ou seria um guia de sobrevivência?) de como tentar contornar este tipo de situação frustante:

==>>Waterfall Model

  • Gerador de código descartável. Sim, é isso mesmo que você leu, o gerador de código você já sabe o que é, agora o descartável é o que você deve estar imaginando. Isso não tem muito a ver com o Waterfall, mas todo projeto que trabalhei tem aquelas camadas que repassam chamadas e seguem um padrão comum. Logo, você não precisa – e nem deve – escrevê-los, para isto inventaram o computador. Se você tem sorte de usar um sistema unix like, se aventure com shell scripts, vale a pena, caso não tenha esta sorte … err, primeiro sinto muito por ti … mas você tem opção de linguagens de scripts como Perl, Python e Ruby em suas mãos, aproveite ! Crie estes scripts descartáveis e gere toneladas de código, seu chefe vai ficar feliz da vida com o aumento da produtividade.
  • Conheça todos os recursos que a sua IDE ou seu editor de texto oferecem. Isso parece ser uma dica besta, mas pode acreditar que não é, já vi muita gente usando um mesmo editor por mais de meses e ficam “abobados” ao descobrirem que o Ctrl+H abre a tela de Replace !!! Bom no meu caso que uso Eclipse o dia todo, as dicas são:
    • Aprenda a usar teclas de atalho, elas realmente aumentam a produtividade. Cheat Sheets como este, ajudam no processo de adaptação.
    • Use e abuse dos Templates, aquelas configurações chatas de xml que toda hora são necessárias, não perca tempo, crie um template para isso e seja feliz. Você pode criar também para aqueles métodos chatos com assinaturas iguais sempre (tipo do Struts mesmo sabe !?!) … o céu é o limite !
    • Aprenda a usar as opções do menu Refactor e – adivinhe! – Geradores de Códigos.
  • Mantenha um checklist de documentos a atualizar, aqueles do tipo, Requisitos, Casos de Uso, Arquitetura, Alteração, Instalação … etc. Com um checklist você não precisa ocupar a cabeça com este passo muito importante do waterfall e lembre-se que neste ambiente o que é valorizado são os documentos e não as pessoas.
  • Antes de começar a sua nova tarefa que está no Gantt, descubra quem são os envolvidos, neste nosso ambiente temos especialistas para todos os lados, converse com eles e feche pactos, pois é muito comum no final da tarefa você descobrir que a procedure retornará um tipo complexo e não um cursor como você imaginava.
  • Sei que isso pode parecer irreal para você que está num waterfall enraízado, porém, tente pelo menos. Tenha um ambiente mock para desenvolvimento, isso pode te salvar ao manter sua tarefa “verdinha” no Gantt Chart. Sim, todos nos sabemos que o Gantt Chart não funciona, porém eu e você que estamos no waterfall temos que usar e até fingir que funciona.

Espero que com essas dicas você consiga se livrar de suas tarefas em menos tempo, e com o tempo que sobrar, aproveite para aprender coisas novas, metodologias novas e descobrir que existe vida fora do waterfall … e acredite ! Estão documentando, aqui, aqui e aqui !

01
jun
08

Waterfalling…

Primeiramente tenho que admitir que o termo usado no titulo do post não existe em nenhum dicionário convencional (encontrei apenas no UrbanDictionary, mas não era bem o que queria expressar…risos).
Mas mesmo assim vou usá-lo livremente, pois acho que não teria nenhum verbete mais adequado para expressar como me sinto atualmente (profissionalmente falando claro!), nada descreve o fenômeno que é desenvolver software, ou pelo menos tentar, em um mercado onde praticamente 99% das grandes empresas ainda gastam milhares de reais com consultorias especializadas em implementar metodologias e processos que no fundo só servem para gastar tempo, dinheiro e a paciência dos colaboradores envolvidos. O resultado disso é uma empresa certificada(CMM/i, MPS.br e afins) e dezenas de funcionários estressados.

É impressionante como a falsa segurança de um processo todo controlado,
medido e previsivel (isso é o que os chairmen ainda pensam!) ainda está
presente nos gestores de TI atuais, pelo menos no Brasil.
O Waterfall continua enraízado em nossa cultara de gestão por simples
jogo de interesses. Essas metodologias (CMM/i e similares…) só
beneficiam pessoas que não querem se comprometer, não estão
interessadas na real satisfação do cliente e querem se manter no
mercado, muitas vezes sendo incompetentes no que fazem (afinal este
tipo de processo permite que as pessoas se escondam atrás desta
burocracia). Existem milhares de papéis (analista, projetista, analista
de negocios, gerentes e mais gerentes, analista de qualidade…blah
blah blah) a serem desempenhados, mas estes papeis são tratados como se
fossem exercidos por robôs. Isso gera o tipo de frase: “Mas eu faço
análise, prazo não é comigo!”.

Eu vejo este tipo de metodologia como a velha discussão dos sistemas sócio-politicos. Se analisarmos de forma fria e racional as duas principais vertentes desenvolvidas neste campo, percebemos que de uma lado temos o socialismo com todo seu esforço para ser algo justo e equilibrado, e na outra ponta temos o capitalismo com toda sua desigualdade, agressividade competitiva entre outras coisas.

“O Socialismo é um sistema sócio-político caracterizado pela apropriação dos meios de produção pela coletivadade. Abolida a sua propriedade privada
destes meios, todos se tornariam trabalhadores, tomando parte na
produção, e as desigualdades sociais tenderiam a ser drasticamente
reduzidas uma vez que a produção, sendo social, poderia ser
equitativamente distribuída. A proposta de Karl Marx, um dos autores que desenvolveu este tema, é a de que o socialismo fosse um sistema de transição para o comunismo, que eliminaria de forma integral o Estado e as desigualdades sociais.” Ver referencias

Como sabemos atualmente o mundo é capitalista, apesar de algumas exceções. Mas que relação isto tem com processo de desenvolvimento de software??
Uma das razões para o capitalismo dar certo é a sua naturalidade, quero dizer com isso que este pensamento/comportamento é intrínseco ao ser humano, todos nós de alguma forma nascemos pensando e agindo assim, uns mais outros menos, e isso acaba refletindo no sucesso que teremos ou não no futuro. Por isso digo que é natural.

Capitalismo é comumente definido como um sistema de organização de sociedade baseado na propriedade privada dos meios de produção e propriedade intelectual, e na liberdade de contrato sobre estes bens (livre-mercado).
“Capitalismo” é o nome que se dá às atitudes econômicas decorrentes
naturalmente numa sociedade que respeita a propriedade privada e a
liberdade de contrato. As pessoas quando sujeitas a estas condições,
com o intuito de satisfazer seus desejos e/ou necessidades, tendem
espontaneamente a dirigir seus esforços no sentido de acumular capital,
o qual é então usado como moeda de troca a fim de adquirir os serviços
e produtos desejados.” Ver referencias

Quando falamos de socialismo, logo percebemos que ele parece muito perfeito, realmente tudo é pensado em prol de todos, todos são uma peça de um esquema muito maior e que tem um plano ideal para todos.
A desigualdade não existe, porém temos que pagar um preço muito alto por isso, ficamos o tempo todo lutando contra nossos instintos, motivações e tudo mais que move o ser humando em sua busca por uma condição melhor pra si. Temos que sempre pensar no coletivo antes do individual, temos que nos conformar em ter as mesmas coisas que todos, perdemos caracteristicas que nos tornam únicos em nome de uma causa maior. Isto é muito legal!! Mas é altruísmo demais até para um monge.

Apenas para deixar claro, não tenho intenção nenhuma de discutir ciências politicas ou econômia com ninguém, realmente não tenho conhecimento para isso (desconsiderem qualquer bobagem que eu tenha dito, tentem captar a intenção. risos).
Minha intenção desde o inicio é mostrar que os processos e metodologias que conhecemos na vida real como parte do Waterfall não são naturais ao desenvolvimento de software e muito menos à nós desenvolvedores. Eles parecem maravilhosos em um quadro na parede com todo fluxo do PMBOK, por exemplo, mas no dia-a-dia custam muito para serem aplicados e exigem que nademos contra nossos instintos para que cheguemos à algum lugar.

Quando falamos de metodologias ágeis, em primeiro momento parece muito vago, o manifesto ágil em sí não se mostra muito técnico, em alguns momentos parece um pouco distante de uma aplicabilidade real. Mas na verdade em sua excência ele tem tudo que nos identificamos. A começar por suas ferramentas, quem na vida nunca se viu praticando
pair programming, pois bem isto é uma pratica muito útil de uma coisa maior chamada Extreme Programming. E não precisamos procurar muito para chegar a conclusão de o Scrum tem como consequencia uma maior aproximação da equipe e auto conhecimento dentre os participantes, com isso proporciana um maior controle gerencial para quem exercer esta função.

Tudo isso natural para nós programadores e computeiros, assim como o capitalismo é para a sociedade e o mercado ecônimico.

Reforçando, não quero iniciar nenhum tipo de flamming relacionado à política ou econômia, quero apenas expôr algumas maluquices que venho pensando ultimamente.

Bom galera, gostaria de dizer que me motivei a escrever essas idéias depois de ler um excelente post do Rodrigo Yoshima no Blog Débito Técnico. É bom saber que ainda existem pessoas que tem a capacidade de provocar o pensamento e instigar a busca por explicações.

Eu sonho um dia poder trabalhar com uma metodologia ágil, enquanto isso não chega vou me lamentando por aí.

Abraços, e coloquem suas opiniões! Podem esculachar, risos…

Referências:
Socialismo
Capitalismo
Débito Técnico – Não jogue dinheiro com melhoria de processos…

26
maio
08

The Pragmatic Programmer, no ambiente Waterfall é claro !

Estou lendo o consagrado The Pragmatic Programmer, o livro é ótimo e faz com que eu tenha certeza que sou um sadomasoquista -calma, eu vou explicar-. Da sua capacidade técnica eu nunca desconfiei, pois sempre é citado nas lista de “top hits” de pessoal muito bom como o Guilherme Chapiewski e Phillip Calçado.
Agora entra a explicação do sadomasoquismo … ler um livro destes, realmente nos faz pensar, tanto em corrigir hábitos ruins que adquirimos com o tempo, quanto novas possibilidade em automatizar todas as tarefas rotineiras por exemplo. Até ai tudo bem, maravilha, o livro até parece uma auto-ajuda alá Paulo Coelho para o programador sofrido e abatido pelo rotina Waterfall … E é nesse momento que volto a realidade e lembro que não sou um programador e muito menos pragmático, pois aqui, no real world Waterfall eu sou apenas um macaco digitador, logo adaptei algumas lições do livro para a vida real:

  • The DRY Principle, bom aqui é diferente, parafraseando o Miguel, aqui temos o PRY Principle, que se auto explica, Please Repeat Yourself.
  • Building Adaptable Systems, essa parte aqui se resume a criar “flags” no banco de dados e dar um nome bonitinho de “parametrização”.
  • Programming Close to the Domain, Domain !?! Seria enviar 18 ou mais parâmetros pra procedures que contém as regras de negócio ? Se for, aqui a gente faz !
  • Programming Defensively, aqui isso se resume a colocar logs em lugares chaves pra passar a culpa do bug para outro equipe.

É claro que existem mais conceitos, mais para um programador-pragmático-waterfall os principais estão acima. O significado real de cada tópico você pode ver nos links, apesar que nada substitui a leitura do mesmo, que por sinal eu recomendo!

Enquanto isso, continuo com a minha sessão “sado”, lendo sobre DDD e tentando descobrir Por que as pessoas de negócios falam como idiotas.

Qualquer desabafo deixem nos comentários.

*obs: o link do amazon não é “paitrocinado”, só ilustrativo mesmo.




Saiba mais sobre nós

RSS Feeds

junho 2017
S T Q Q S S D
« ago    
 1234
567891011
12131415161718
19202122232425
2627282930  

Feed Counter

Blog Stats

  • 1,111 hits

tail -10f /top-posts

RSS job4dev

  • Ocorreu um erro. É provável que o feed esteja indisponível. Tente mais tarde.