Começando um projeto

Olá, noobs!

Há algum tempo estou com um projeto. Não tenho tido muito tempo pra me dedicar a ele, mas vou tocando conforme posso. Já citei ele no meu primeiro post, e agora vou falar um pouco sobre...

Em primeiro lugar, este projeto é, pra mim, uma maneira de testar tecnologias, testar habilidades, testar metodologias ágeis, etc. Estou fazendo junto com minha namorada e um amigo, que também já foram citados, e decidi que vou postar, o mais regular que eu conseguir, como as coisas estão indo.
A título de ambientação, o projeto é um gerenciador de fichas de RPG, inicialmente para o sistema de Tormenta.

O projeto está no GitHub, para quem quiser baixar.


Enfim, após discutir com o Gabriel os nossos objetivos finais - ou seja, o produto final - que desejamos obter, comecei a trabalhar no site que será disponibilizado. Criei o index.html com o cabeçalho, onde, assim como na ficha, ficam as informações mais básicas do personagem. Ficou bastante bonito (como pode ser visto abaixo).

Quando o Gabriel olhou o arquivo, porém, veio imediatamente falar comigo:

Cara... não faz o DOM na mão! JavaScript > HTML + CSS!

Ao qual eu respondi que, por mais que eu utilize JS, sempre será necessário o uso de HTML e CSS no DOM.

Nossa discussão durou algum tempo, durante o qual defendi minha posição de usar o HTML e CSS diretamente no DOM, e ele a de criar o DOM dinamicamente por meio de Frameworks de JS, citando o Backbone.js.

A discussão ficou por isso mesmo, até que, essa semana, ele postou um link do CodeSchool com um curso de Backbone. Resolvi conferir. Fiz o primeiro módulo do curso e... gostei! Realmente, é muito simples de ler, quando já se entende sobre o que é aquilo. O documento fica simples, pois abstrai a redundância do documento HTML. Eu posso simplesmente importar um arquivo com o JavaScript e Voilà! O DOM está pronto. (Infelizmente, o CodeSchool cobra uma taxa de $29.00 POR MÊS para fazer os cursos lá, com exceção do primeiro módulo... Valeria a pena, se eu tivesse tempo de fazer vários cursos por mês... Mas eu acho alternativas...) :)

Claro, falando assim parece até mágica.

Não. Não é.

Nesse post não vou mostrar nenhum tipo de desenvolvimento com o Backbone.js, até por que ainda não tenho nada pronto. Meu intuito é explicar a decisão que tomei.

De acordo com o Uncle Bob (já citado no meu post anterior), é essencial que o código seja compreensível. Não adianta que tenhamos um documento enorme, cheio de métodos, que não se entenda nada. O ideal são documentos pequenos. Métodos que façam uma - e apenas uma! - coisa, e bem feita! É preciso que o documento seja simples o suficiente para que alguém que nunca o tenha visto possa compreender o que está sendo feito em pouco tempo. E isso é mais fácil dito do que feito, por incrível que pareça.

Usar um framework nem sempre é a decisão mais aconselhada. Como nós não somos os donos do código, é possível que ele venha a mudar e determinadas funções parem de funcionar. E é bem difícil fazer com que o framework não seja o dono do código (no sentido de "quebrar" o código quando mudar).

Esse, porém, é meu intuito. Nos próximos dias, vou estudar o que eu puder sobre Backbone.js para que eu possa desenvolver a mesma coisa que desenvolvi anteriormente nele, e mostrar a diferença. Quiçá eu tenha um arquivo bonito, simples e elegante para mostrar aqui em breve.

O que é Teste Unitário?!?

Olá, noobs!

Há algum tempo atrás, no meu primeiro estágio, foi-me pedido pelo meu chefe que começasse a cobrir o código da empresa com Testes Unitários. Na época eu estava recém começando a ouvir falar em métodos ágeis, a empresa estava adotando o Scrum e eu nunca tinha feito TDD (Test Driven Development).
Entretanto, era de minha vontade aprender sobre isso, e eu já havia comentado com meu chefe e colegas de trabalho. Logo, essa tarefa veio na hora certa.
Ou será que não?
Vejam bem... Eu nunca havia feito um teste unitário, nem sequer sabia como eles deveriam ser feitos. Pesquisei na internet e achei referências a JUnit, que já sabia que era usado na empresa (embora com pouca cobertura do código). Comecei a procurar como usá-lo e fui encontrando exemplos.
Bom, antes de continuar, saibam que esse foi meu primeiro erro.
Os exemplos não eram explicativos, usavam Mocks (que eu explico o que são daqui a pouco) e cobriam códigos pequenos. Mas a ideia eu havia entendido! Eu deveria fazer testes que cobrissem (garantissem) todo o código que eu queria testar. Deveria ter um teste para cada possível entrada e saída do método!
Ou será que não?
Foi o que comecei a fazer. Porém estava muito enganado sobre o método que deveria ter utilizado. Eu cheguei a cobrir algumas classes do código da empresa, mas não conhecia profundamente a arquitetura adotada pelo sistema. Quando me deparava com métodos utilizando outras classes, não sabia como instanciar a classe dentro do teste, pois não queria ter que chamar uma instância real da classe e, quando perguntava para os desenvolvedores sêniores da minha equipe, eles apenas diziam para usar o "Mock". "Mock", de acordo com eles, era uma classe falsa, que serviria apenas ao propósito de completar o teste (passando ele ou não). Mas eu não encontrava nada sobre como fazer um "Mock" na internet.

O tempo passou. Um pouco. Eu comecei a me interessar mais por metodologias ágeis. Principalmente depois que, em uma entrevista de emprego, me indicaram um livro para ler.

Código Limpo: Habilidades Práticas do Agile Software

Não, esse livro não fala sobre testes unitários. Ao menos, não diretamente. Mas se prestou perfeitamente a me apresentar Robert C. Martin.. E é aí que eu queria chegar.

Recentemente, comecei a ler artigos do Uncle Bob (como Robert chama a si mesmo). Acabei encontrando o blog Clean Coder. Nesses artigos, ele defende incessantemente a metodologia ágil, sobretudo o TDD. Mas, para o TDD funcionar, é necessário que se saiba fazer testes unitários. E como um teste unitário é feito? Qual é a proposta?

Os testes unitários têm mais funções do que aparentam. De acordo com Uncle Bob, eles são a maior documentação do sistema. Eles devem descrever o funcionamento do sistema. Eles garantem que o sistema funcione, independente de modificações no código, afinal, quando uma mudança faz com o que o sistema não funcione mais, os testes não passam. E isso é derivado da parte anterior, de descrever o funcionamento.

Então, para criar um teste unitário, é necessário que entendamos a que nosso sistema se propõe. Precisamos saber quais são as entradas possíveis e o que não pode ser aceito. E precisamos saber as saídas esperadas. De maneira geral, existe uma breve fórmula que pode ser utilizada. Ela segue o seguinte padrão:

Dado que (eu tenha determinados dados) Quando (alguma coisa é recebida/acontece) Então (esse deve ser o retorno).

Seguindo esse padrão, é fácil percebermos que os testes unitários se distanciam brevemente do código e, acredito, devem ser feitos independente do código. Devemos seguir apenas as definições do sistema, mantendo sempre nossos testes o mais perto da fórmula acima possível.

Não vou me estender muito mais, mas prometi informações sobre mocks. Para facilitar, quem sabe inglês pode acessar diretamente esse texto do Uncle Bob: The Little Mocker, onde ele explica os diferentes tipos de Mocks.

Requiem for a Noob

Olá, noobs!

Eu comecei esse blog por influência de algumas pessoas e de uma ideia genial de "compartilhar conhecimento, independente de o quanto se sabe".
A ideia é de que "sempre existe alguém que sabe menos". E, ao mesmo tempo, serve como um histórico pessoal de o que eu estou aprendendo e de como eu estou evoluindo nos assuntos de meu interesse.

Pra começo de conversa, o assunto geral do blog vai tender para a área da informática. Desde livros, teorias, linguagens, workarounds. Mas não vou me prender a esse único assunto. Eu sou um noob confesso, e não só em computação. Conforme eu for fazendo coisas diferentes que eu ache interessante compartilhar, faço um post aqui. Acima de tudo, esse é um espaço para que eu possa dissertar sobre as coisas que eu estou aprendendo. Se, de alguma forma, a informação que eu acabar disponibilizando aqui for útil para ti, faça bom uso dela. Aprenda com os erros que eu vier a cometer, discuta o assunto do post e dê ideias e ajudas no que achares conveniente.

Além disso, como comecei um projeto pessoal, em parceria com o Gabriel Oliveira e com a Kamilla Oliveira, esse blog vai servir como um espaço para eu explicar decisões tomadas com relação a esse projeto, sejam elas de arquitetura do sistema, de modo de fazer uma funcionalidade ou da tecnologia que decidirmos utilizar.


Como disse anteriormente, eu sou um noob. Estou aqui para experimentar e aprender. E, no processo, disseminar o conhecimento que eu adquirir.


Btw, devido à falta de tempo, o layout ainda está bem básico. Ele virá a melhorar. Espero.