Helio Costa - hlegius : As ruas sem saída em Test-first

Uma vez entendidas as motivações de se fazer Test-first, mudar seu mindset para TDD, muitas coisas ainda restam apontar. Claramente, há um processo sugerido para conseguir se concentrar e tomar como guia quando chegar em becos sem saída trabalhando com Test-first.

Tão sabido quanto ao andar de bicicleta você fatalmente cairá uma hora ou outra, com os testes não é diferente: você irá sim chegar à ruas sem saída. Terá dúvidas, poderá sentir-se no escuro. Não pelo Test Driven Development per se, mas pelo fato de que você está saindo da sua zona de conforto; você está experimentando.

Na minha máquina (não) funciona!

Há pessoas que de tanto chegar à ruas sem saída, acabam assumindo que TDD e toda aquela coisa de design desacoplado são cartas viradas. É fato de que a ciência que envolve a computação é muito recente. Vivemos nosso momento paleolítico e haverão grandes cientístas (e tecnologistas) no futuro mudando a forma como lidamos com tais problemas, mas não podemos simplesmente desistir e dizer: isto não funciona. A ciência não funciona assim. Para poder dizer esta por**** não funciona você precisa dominá-la bem. Precisa apresentar todo um estudo defendendo seu ponto de vista baseado em dados, experimentos e outros estudos. Há artigos e não posts em blog provando a eficiência do Test Driven Development para projetos de software em nosso momento da história da computação. Obviamente se você pretende fazer apenas CRUD utilizando um framework One Size Fits All - que não conterá regra de negócio alguma, o Test-first torna-se desnecessário.

Rua sem saída

Rua sem saída - a.k.a ficar sem ideias ou não saber como prosseguir - não é algo ruim. Quando atingida, nos faz pensar sobre nossas decisões de design e como elas podem melhorar. Geralmente, ruas sem saída vêm acompanhadas de pesquisas, que puxam leituras que podem gerar debates de ideias que resultam em evolução profissional e better code.

Imagine quando começou a pedalar: você não tinha qualquer equilíbrio. Talvez não tenha utilizado rodas de apoio, mas ainda assim, não tinha equilíbrio sob duas rodas. Após várias idas à praça e várias voltas com sua bike, você começou a ganhar equilíbrio. Equilíbrio traz confiança que traz mais experiência, que te faz buscar andar mais longe e consecutivamente, mais quedas. Após crescer e ao começar a pedalar mais longe, você buscará técnicas de respiração para ir mais longe com menos esforço físico. Se guia sua moto, irá pesquisar técnicas de pilotagem e direção defensiva. Com Test-first o processo é exatamente o mesmo, adaptado para software: inicia em Test-first, busca por técnicas, experimenta; falha; pesquisa mais; tenta novamente; obtém o resultado, aprendendo a técnica; inicia o ciclo novamente.

Test-first é um conceito. Assim como design de software. Isto quer dizer que não existe uma resposta certa; mas sim, soluções aceitáveis. Para obter uma das soluções, você precisa:

1. Ler livros, papers;
2. Discutir com co-workers, listas de discussão;
3. Praticar;
4. Praticar;
5. Praticar.

Equipando-se para se proteger em becos escuros

Como dito anteriormente, há algumas known tips que ajudarão você a manter-se focado na solução. Unclebob, já falou inúmeras vezes sobre isto em seu(s) blog(s), vídeos e palestras. Um conhecido é o Three Rules of TDD.

1. Você deve sempre começar a feature, criando um teste daquilo que deseja obter como resultado - e o teste deve falhar.

2. Você deve escrever apenas um teste de unidade por vez e este precisa falhar. Lembrando que não compilar é um erro também.

3. Você precisa escrever apenas o necessário para aquele código passar. Lembre-se de que TDD é para preguiçosos.

Pode parecer um tanto dogmático, mas depois de entender os objetivos do Test-first, essa coisa faz sentido.

Testes são especificações. Um conjunto de especificações formam um software funcional. Working software é o objetivo que devemos ter. De nada adianta um monte de prática se ao final o software não é entregue como deveria. Sempre tenha isso em mente: esse teste precisa ter um propósito claro dentro do meu projeto. Se o teste não é claro, pode ser que você esteja caminhando para um beco escuro.

Red, Green, Refactor. É uma versão amigável das três regras do TDD. Teste falhando; Teste passando; Limpar seu código de produção para deixá-lo o mais legível e simples possível.

Simples? Métricas para Simples:

Single Responsibility Principle. Seu método, sua classe, seu módulo(mixin, trait, etc) precisa fazer apenas aquilo que se propôs a fazer. Métodos do objeto devem ser claros, objetivos.

Outra métrica é o DRY. Don't Repeat Yourself. Fez copy-paste parcial ou totalmente de um trecho de código para utilizar em outro lugar? Duplicou o código.

Law of Demeter ou Tell do not ask: apesar do nome medonho, a coisa é fundamental estar registrada na tua cabeça: ao invés de perguntar algo de um objeto para com o retorno do método fazer alguma coisa, peça que esse objeto faça o que você quer utilizando seu input. Exemplo:

public class Order {

  public void add(Produto itemComprado, int quantidade) {
    if (itemComprado.estaAVenda() && itemComprado.getEstoque().getQuantidade() >= quantidade) {
      OrderItem item = new OrderItem(itemComprado, quantidade, this);
    }
  }
}

Ao invés de expor as particularidades do Produto e Estoque para o Order, podemos simplesmente fazer justiça com as próprias mãos:

public class Order {

  public void add(Produto itemComprado, int quantidade) {
    if (itemComprado.temDisponivel(quantidade)) {
      OrderItem item = new OrderItem(itemComprado, quantidade, this)
    }
  }
}


public class Produto {

  public boolean temDisponivel(int quantidade) {
    return this.estaAVenda() && this.estoque.temDisponivel(quantidade);
  }
}

Assim, Order#add agora passa apenas a adicionar produto à Order, sabendo apenas que precisa saber se tem estoque para tal. Como saber se tem estoque é problema do Produto e seu estoque não de Order.

Apesar de parecer óbvio, é um dos code smells que mais fiz e vi durante esse tempo. É natural falando/escrevendo, mas no meio do seu código, isso passa batido facilmente. Keep on track.

Concluíndo

Técnicas e conceitos como S.O.L.I.D, precisam estar em nossas cabeças para evitarmos andar em direção aos becos escuros. Ruas sem saída, são parte do processo de aprendizado que são mitigadas com leitura e muita prática. Test-first não se aprende em um mês ou dois. Nem por isto, testing é uma coisa chata. Em minha opinião, os testes tornam o dia-a-dia muito mais divertido, desafiador e proveitoso.

Blog do Gio : Elegance Colors!

O Elegance Colors permite mudar de cor e até mesmo alterar o próprio tema do Gnome Shell de acordo com o atual tema GTK, possibilitando também a personalização dos mesmos.

Descobri o Elegance Colors ao tentar instalar o pacote de temas e ícones Numix aqui no Arch. Depois de instalado não era possível alterar e tema do Shell para o Numix com o Gnome Tweak Tool.

Consegui mudá-lo através do “EC”, com a ajuda do amigo Matt Dobson, na opção de configurações gerais, como dá para ver na screen abaixo:

Legal não?!

O pacote está presente no repositório AUR, podendo ser instalado manualmente ou através do Yaourt, logo:

$ yaourt -S gnome-shell-themes-elegance-colors

Você pode saber mais sobre o Elegance Colors aqui!

Abraço!

Blog do Gio : Numix no Ubuntu 14.04!

Vamos utilizar para personalizarmos o nosso Ubuntu 14.04 o pacote de ícones e temas Numix!

Porém esse pacote não está nos repositórios oficiais, então precisamos adicionar o repositório que o contém, logo:

$ sudo add-apt-repository ppa:numix/ppa

Feito isso precisamos atualizar os repositórios:

$ sudo apt-get update

Agora vamos instalar o pacote “completo” de temas e ícones Numix:

$ sudo apt-get install numix-gtk-theme shimmer-themes numix-icon-theme numix-icon-theme-shine numix-icon-theme-circle

O Ubuntu ainda não fornece por padrão uma ferramenta que nos permita personalizar os ícones e o temas do sistema, além dos que já são padrões (Como assim Ubuntu?!). Para resolver esse problema vamos instalar a ferramenta Unity-tweak-tool, logo:

$ sudo apt-get install unity-tweak-tool

Agora basta abrir a ferramenta Unity-tweak-tool e fazer as personalizações, escolhendo os temas que mais gostar:

Como resultado:

Bacana não?!

Aproveite!

Ps.: Essa versão 14.04 do Ubuntu, está notavelmente mais rápida e eficiente, pelo menos em um primeiro contato.

Abraço!

Helio Costa - hlegius : Introspecção

Mudança. Todos temem à mudanças. E não seria diferente ao codificar software, não é mesmo? Para que mudar se podemos continuar com nossa atual rotina simples e praticamente automática? Aquela coisa de chegar no trabalho, fazer o de sempre, como aprendeu no tutorial há tempos atrás ou que viu o ex-chefe fazer e até hoje executa assim sem questionamentos.

Em software isso recebeu um nome no livro The Pragmatic Programmer. Caso o cenário acima encaixe no seu code-style, você está programando por coincidência. Gosto do termo em português, pois ele é duplo sentido. Além de indicar o estado profissional acima, ele também implicitamente diz que você está na área por um mero acaso. * O livro não fala disso. Essa segunda parte é totalmente de minha autoria. Pode parecer xiita, mas te convido a refletir sobre isso mais a fundo.

Ao entrar no seu modo automático e passar a fazer coisas sem se questionar o porquê está fazendo (ou fazendo novamente) aquilo, você está programando por coincidência. Seguir aquele fluxo toda vez que depara com um problema passado sem questionar-se o motivo e se há melhor alternativa, você está programando por coincidência. Se, você assume coisas - isso vale muito pra teste - por exemplo que o erro X é causado pelo Y, simplesmente porque você acha que isto ocorre, você está programando por coincidência. Neste caso você não deveria assumir, mas sim provar que o problema é aquele mesmo.

Saindo da coincidência

Uma das formas de evitar esse ciclo de tédio e comodismo é justamente fazer Test-First. Explico os motivos:

1. Lego Effect: como comentei no Teste Unitário?, começar pelo teste fará você pensar em como aquela funcionabilidade que pretende fazer irá se relacionar. Isso te faz pensar mais e consequentemente, dúvidas virão e você buscará saná-las (livros, pesquisa na Internet, Twitter, outros devs, projetos Opensource).
2. Ah, a preguiça! Os testes te ajudarão a achar o menor caminho possível para aquela implementação. (teste é coisa de preguiçoso, lembra?) Isto te fará repensar técnicas. Com a prática de novas técnicas, você evoluirá como desenvolvedor.
3. Não mais dúvidas sem resposta! Com teste, você pode testar não apenas o código de implementação mas também as suas suposições. Pensamentos do tipo: será que isto pode funcionar desta forma? serão mais frequentes, uma vez que o espaço entre o será que... e a resposta são apenas escrever um assertion simples e executá-lo.
4. You on Rails. A prática do Test-first te mantém na linha de fazer o que realmente importa. Sem suposições vazias; Sem achismo; Você se antecipa dos problemas que poderá encontrar. Estar alinhado em fazer o que importa te torna introspectivo.
5. Test & fail. Test & Learn.
6. Não sendo mais telespectador. Você no controle! Não mais sendo guiado por processos e rotinas sem saber o motivo de estar fazendo aquilo daquela forma.

Questione-se; Reflita; Pense um pouco mais sobre sua forma de fazer as coisas. Isso é realmente a melhor forma de se obter o resultado que deseja?

Recentemente peguei meu Card Deck que ajudei a fundar (?) no Kickstater. Um dos cards que mais me chamou a atenção, até pelo fato de eu já ter feito isso anteriormente é o Remove your BEST idea.

Conseguiu achar uma solução para o problema? Ótimo! Ela poderá ser seu backup caso as coisas dê muito errado. Empenhe-se para achar uma outra melhor ideia. Vale muito a pena esse exercício.

Concluíndo

Test-first é uma das formas de acabar com a programação por coincidência. Test-first entretanto não irá te salvar de todo o mal do mundo - mas posso afirmar, por experiência própria que ele te coloca on track novamente.

A propósito, já leu o The Pragmatic Programmer: From Journeyman to Master? Permita-me dizer que você deveria se ainda não o fez pelo menos uma vez.