Viagens, opiniões e afins

No artigo passado da série “Estudo compartilhados”, abordei mais a questão da Orientação a Objeto e como ainda não nos entendemos bem com ela.  No finalzinho do artigo, rapidamente, falei sobre os testes automatizados no famoso TDD.

TDD virou um buzzword. Traduzindo: Uma palavrinha da moda.  Hoje as empresa já colocam nos seus anuncios de vagas que o candidato que conhece TDD é um diferencial, outras até exigem. A questão é: Você sabe realmente o que é TDD?

TDD é a sigla em inglês para TEST DRIVEN DESIGN ou design dirigido por testes.

Mais uma vez para me ajudar com essa questão, pedi a ajuda para meu amigo Alexandre Martins, e ele me recomendou ( meio óbvio), o livro do Kent Beck , criador do TDD,  TEST-DRIVEN DEVELOPMENT . Além desse, Nunes também me recomendou alguns artigos e outros livros como o Growing Object-Oriented Software, Guide by Test, que mostram o caminho das pedras e como o teste pode ser o melhor amigo do desenvolvedor.

Numa conversa com outra pessoa, Rafael Martins (Cabra) da Globo.com,  concluímos que muita gente acaba por ter uma visão torta do que vem ser testar antes. Testar antes parte da premissa, na minha concepção, de que é preciso um problema para procurarmos a solução. Seria mais ou menos assim:  Você tem que comer quando sentir fome, pois do contrário, você está sendo guloso e indo além de suas capacidades.

Quando você cria os seus teste antes, baseado em suas necessidades, está de certa forma, criando um problema a ser resolvido. Se for disciplinado e apenas resolver aquele problema e repetir esse ciclo até que todos os requisitos sejam atendidos, a solução literalmente emerge. Isso mesmo: EMERGE.

Muitas das pessoas que me ouviram falar disso, respondem dizendo que é mentira ou exagero da minha parte que a solução EMERGE. Convido, os descrentes, a assistir e participar de uma sessão de dojo.

No livro Agile Software Development, também do UncleBob,  existe um capítulo em que ele descreve o desenvolvimento de um sistema para pontuação de boliche em que faz um par (pair programming) com outra pessoa e segue  conceitos como TDD e baby steps. É simplesmente revelador. Sei que exagerado mas é isso mesmo: REVELADOR ; pois ele simplesmente vai fazendo o sistema “sem pensar”. Dando pequenos passos, e sempre mantendo um dialogo e trocas constante com seu amigo, o design vai surgindo diante deles e se mostrando diferente do que se imaginava de inicio.

TDD evita desperdício

Um outro livro que recomendo muito é o Pragmatic Programmer. Nesse livro ele procura mostrar que o pragmatismo é uma boa filosofia para nós que fazemos software. Dentro disso, uma das coisas é a questão de evitar o desperdício.

Evitar desperdício é algo muito amplo e engloba diversas atitudes que devemos ter como: automatizar tarefas repetitivas,  tornar simples fazer o certo,  não fazer mais do que é preciso, etc.

Muitos se perguntam o que fazer para ser um programador ou ter um time altamente eficiente. Eu acredito que a solução vem de evitar desperdício e fazer o “justo necessário”. Isso também é conhecido como evitar o OverDesign. Sabe aquela aplicação simples para enviar arquivo para um servidor que o pessoal quer fazer com um monte de camada, abstrações, etc, justificando que isso facilitará uma possível modificação futura…Isso é um excelente exemplo de gasto desnecessário.

Quando fazemos TDD e nos disciplinamos a fazer o teste passar (isso mesmo) a gente fica focado; ao ficar focado evitamos desvios e perdas de tempos fazendo coisas para necessidades que não existem ainda.

ATENÇÃO: ISSO NÃO SIGNIFICA QUE VOCÊ DEVE FAZER ARQUITETURA PORCA. SEU CÓDIGO DEVE SER LIMPO.

Testar depois é apenas automatizar. TDD é mais uma ferramenta de design.

Até a próxima pessoal.

A muito tempo venho pensando em uma coisa: O que acontece quando mudamos nosso foco para a direção das pessoas? Se ao invés de focarmos em obter mais lucro, mais dinheiro, mais bens, melhores processos,  equipamentos mais rápidos, a gente simplesmente focasse na pessoa… na pessoa na forma do cliente, na pessoa e sua qualidade de vida, na pessoa que usará aquele novo equipamento, etc.

Existe um grupo de pessoas aqui no Rio, mais especificamente ligados a TI (desenvolvedores, designers, etc)  que proporam exatamente isso:  miraram no ser humano. Isso vem galgado no Small Acts (acesse o link e leia pois vale a pena).  Ao fazermos isso, centra nossas atenções nas pessoas, os resultados foram surpreendentes e nossas ações tem tido repercussões até inesperadas.  São eventos em que, por pura paixão, vamos e levamos toda a nossa “energia” (nenhum de nós ganha dinheiro palestrando, ou fazer qualquer outra coisa afim), são encontros que para muitos parecem organizados e ultra focados como grupos de usuários sendo que na verdade estamos ali para conviver, rever amigos, tomar um chopp e como bons nerds que somos acabamos por falar de tecnologia e similares.

E claro que por vez ou outra surgem boas iniciativas dentro desse encontros e elas, por sua vezes,  em alguns casos viram excelentes projetos e ficam famosas. Mais tudo isso acontece não porque se quer ficar rico ou famoso. Mas porque acreditamos sinceramente nas pessoas e queremos levar essas coisas, que consideramos legais, para as pessoas.

Pode soar para muitos como algo idealista e utópico. De certa forma, olhando friamente e tendo como base o “restante” da sociedade, realmente é.   Entretanto, quando estamos ali fazendo para nós não passa de diversão. Por muitas vezes, me pus “de fora” e fique observando: parecíamos crianças empolgadas.

Insisto que ainda parece um tanto utópico nesse nosso mundo consumista mas quando o foco deixa de ser o lucro, o processo, a empresa e passar ser as pessoas realmente coisas mágicas passam a acontecer. Isso eu falo e qualquer nível de relacionamento. Se pegarmos uma loja e fazermos com que a equipe foque na pessoa e não no dinheiro do cliente veremos vendas aumentar, satisfação do cliente, aumento da propaganda boca a boca, etc. Se pensarmos em ambientes de trabalho, quando temos gerentes “humanos”que focam na pessoas de seus funcionários e não os encara como recurso, todos produzem mais, ficam mais felizes, as coisa fluem sem atritos, etc.  Isso pode ser extrapolado, ouso dizer, para qualquer situação.

Claro que em TI isso não pode ser diferente e ao meu entender possui uma dimensão mais interessante. A maioria das pessoas que trabalham com TI são pessoas que gostam de máquinas. Sim…. elas gostam de máquinas: são seus celulares, seus computadores, seus gadgets, seus video games, e o que mais vier. Poucos são aqueles que gostam de convivência. Isso é algo que para o profissional de nossa área deve ser vencido. Quanto não são os gênios que simplesmente travam quando tem que estar dentro de uma equipe? Quantos problemas temos no desenvolvimento por problemas que nada tem relação com a tecnologia e sim com as relações pessoais da equipe? .

O foco nas pessoas faz que com isso tudo se inverta e verdadeiros progressos se façam. Ao focar na pessoa, os processos se humanizam e passam a levar em consideração essa dimensão. Com isso eles se tornam mais próximos da realidade. Mas factiveis. Softwares são feitos para seres humanos, em sua maioria. E por isso, em sua concepção devem ter o foco no ser humano e não da linguagem, na máquina, etc. Isso que chamamos de experiência do usuário e que vem sendo perseguido pelos grandes players do mercado.

Muito tenho escutado neste últimos dias sobre a questão do sucesso ou não do uso de metodologias ágeis.Principalmente com relação a entregas. Primeiro preciso dizer que não sou um doutor no assunto, nem pretendo ser, muito menos um profundo conhecedor, mas considero que tenho uma pequena vivência no assunto que me permite tecer alguns comentários sobre o assunto.

A poucos dias atrás eu deu uma palestra numa PythonCampus ( foi na Estácio de Madureira) para um público de cerca de 50 a 80 pessoas.  Nessa palestra, mesmo que o tema principal tenha sido falar de como fazer grandes produtos em python, aproveitei para passar alguns pontos de vista para a galera que está começando agora.

Antes de mais nada é válido dizer que apesar que já está a um bom tempo na estrada, por várias vezes me sinto como eles: sem saber para que lado “atirar”.  Hoje, como profissionais de TI, somos bombardeados a todo momento com toneladas de post de blogs, twitters, artigos, livros, lista, etc dizendo qual será ou quais serão as próximas grandes tecnologias do momento.  Frente a esse quantidade exagerada de coisas, ficamos num “mato sem cachorro” tentando dimensionar nosso tempo para investir em algo que nos garanta um bom futuro.

Bem frente a isso, tenho um péssima notícia: não tem uma resposta pronta, somente o famoso depende. Cada caso vai pedir uma coisa meu caro e quanto mais saber mais opções terá e com isso, mais chance de acertar a escolha.

Embora o assunto seja fascinante e dê “pano para a manga”, o que gostaria aqui, hoje, de falar é quanto a reaproveita conhecimento.

Voltando ao assunto da PythonCampus, durante a apresentação aproveitei para pergunta para a galera presente, como um pequeno censo, quantos usavam determinadas linguagem. As duas que foram mais votadas foram java e .Net. Um brve parenteses antes de continuar: Ao contrário do que a maioria pensa . NET  não é uma linguagem e sim uma plataforma de desenvolvimento. Tanto que existe muitas linguagens que foram feitas para rodar dentro do .NET (C#, ASP.NET, VB.NET, IronRuby, IronPython, etc).

Dado que o mercado ainda demanda por profissionais que saibam usar essas duas tecnologias, .NET e Java, fiquei pensando como seria que uma pessoa poderia dar o passo adiante rumo a uma coisa mais produtiva e diferente.  Quando falamos com alguém que a vida toda trabalhou com Freelas (aqueles projetos pessoais que a gente cobra; aquele site do tio- entendeu?) e  que por isso usou bastante PHP, por exemplo, fica mais fácil apresentar para ele Python e Rails ; a pessoa já está acostumada com aquela natureza dinâmica e não burocrática e agora apenas aprenderá algo com mais ordem e etc.

Mas quando falamos de caras de Java, vem logo a imagem daquele moleque andando de roupa social  ou terno pelo centro do rio e trabalhando em grandes consultorias que cobram os olhos da fuça para fazer um helloworld e ainda por cima não entregam no prazo e nem perto do que o usuário queria.  Antes que me atirem pedras ou coisas afins, eu sei que nem toda a culpa é da linguagem tem muito do profissional.  Tendo essa perfil em mente, fica díficil converser aquele cara que ele deve aprender outro coisa. Ele não quer se esforçar muito mais e fica colocando defeito nas coisas para justificar sua preguiça.

Diante esse cenário caótico fiquei matutando um jeito que poderia servir de transição suave e assim, sem grandes revoluções e sim evoluções, levaria aquele cara para dentro de um mundo novo de possibilidades.

Para o caso do java, graças ao grande oraculo, aka Google, eu encontrei o Grails. o Grails é um spin off do raisl para a plataforma java usando a linguagem Groovy que roda dentro da JVM.  O GRails é uma implementação do rails em groovy. Segundo o próprio site do produto é rails melhorado pois pegar o que há de melhor e aprimorar frente as experiências da galera.

A parada é realmente boa e vale a pena baixar e testar. Com a vantagem de ainda ser Java embora a sintaxe do groovy seja muito produtiva caso resolva se lançar de cabeça. Assim como em Ruby on Rails, como muita pouca linha de código você consegue ter um site no ar.

Bem essa volta toda para dizer para a galera acordar para as coisas que estão acontecendo, para acordarem que não terão vida fácil,  não existe mais a linguagem solução e sim uma caixa de ferramenta e por aí segue.