Para o programador, o GIT ajuda muito a organizar o código, ver modificações feitas ao longo do projeto e, caso se depare com enventuais bugs ou erros após uma nova versão ser lançada, pode voltar atrás e manter o programa “saudável”. O GIT funciona através de um repositório local, sem necessidade de conexão com a internet para poder ser utilizado, porém você pode passar esses arquivos para um repositório virtual e então acessá-los de qualquer computador. Esse repositório virtual é o nosso GitHub.

O GitHub já é tão popular, que se tornou um item obrigatório de todo programador – caso você não tenha ainda, trate de resolver essa pendência imediatamente. O GitHub permite que o usuário já utilize de algumas das funções básicas do GIT de uma maneira bem simples, como commits dos seus arquivos, push/pull, criação de branches entre outras. Hoje, o GitHub é mais que uma ferramenta de controle, ela serve de portfólio para o programador exibir seus códigos ao público, que poderá clonar, fazer melhorias e “devolver” o código à você.

Chega de papo, vamos ver como utilizar essas ferramentas no nosso trabalho. Vou demonstrar com um exemplo bem simples, upando um arquivo “helloworld.txt” em um repositório do meu GitHub. Para executar os comandos apresentados abaixo, faça download do GIT Bash aqui. Isso nada mais é do que um terminal do GIT. Bom, vamos começar.

1. Para iniciar um repositório local pelo GIT, você deve usar o comando git init.
   
   Perceba que surgirá um (master) logo após o local do seu repositório. Essa é a branch em que você se encontra. Aqui só trabalharemos com a master.
2. Em seguida, cria-se um arquivo “helloworld.txt” dentro da pasta do nosso repositório.
3. Para ver a situação dos seus arquivos dentro do repositório, você deve utilizar o comando git status.
   
   Os arquivos em vermelho indicam que são novos no repositório e ainda não foram adicionados, que é justamente o que você fará agora.
4. Com o comando git add nome-do-arquivo você adiciona o arquivo em questão para o seu repositório local.
   
   Logo após o git add é bom executar um git status novamente para ver se está tudo OK. Perceba agora que o nome do arquivo está verde, indicando agora que ele está no repositório esperando um commit.
5. Executando agora o git commit -m mensagem-de-commit, o GIT pega todos os arquivos em verde e os salva de fato no seu repositório. Essa mensagem de commit é um lembrete breve sobre o que foi “commitado” (recomenda-se no máx. 50 caracteres).
   
6. Se você der um git status novamente, verá que ele não mostra mais nenhum arquivo, pois não existem mais arquivos pendentes a serem commitados.
   

Pronto, agora você já sabe o básico para gerenciar seus arquivos através do GIT Bash, mas faltou ver como publicar esse repositório local em um repositório virtual no GitHub.

1. Para isso, você deve criar um repositório novo no seu perfil do GitHub clicando no “+” ao lado da sua foto de perfil e depois selecionando “New Repository”.
   
2. Logo depois, o GitHub já pergunta qual será o nome desse repositório, pede uma descrição, se será publico ou privado, se deseja inicializar com um README.txt… Isso é com você.
3. Repositório virtual criado, salve a sua URL. No meu caso, o nome do meu repositório para esse exemplo é git-test e a minha URL é https://github.com/ftfetter/git-test.
4. Voltando ao GIT Bash, utilize o comando git remote add origin <link-do-repositório>. Isso irá associar o nosso repositório virtual ao local. O link do nosso repositório virtual estará salvo no origin.
5. Vínculo criado, use o comando git push origin master para puxar os arquivos commitados no master para o repositório virtual registrado no origin.
   Quando executar esse comando, irá aparecer uma tela de login do GitHub para você entrar (somente se você não estiver com a sua conta salva nas configurações).
6. Se tudo correu bem, você deve estar com o seu arquivo no repositório do GitHub.
   

Você poderia ter feito o processo de push iniciando o repositório pelo GitHub, depois clonando ele para a sua máquina e utilizando-o como um repositório local, porém eu não teria mostrado o git init nestes exemplo.

Para aqueles que tem um pouco de conhecimento em inglês, esse tutorial é muito bacana e bem útil. Try Git

Clean Code é, essencialmente, um conjunto de boas práticas que tem como objetivo facilitar a leitura e compreensão do código. Isso ajuda na manutenção do mesmo aumentando a sua vida útil.

Qualquer um consegue escrever um código que o computador entende. Bons programadores escrevem códigos que humanos entendem.
Martin Fowler, autor

Separei algumas práticas básicas para exemplificar bem o objetivo do Clean Code:

Nomes Significativos
Tomaremos como base a seguinte função:

int calc(int x, int y, int op){
   int z;
   if(op==0)
      z = x+y;
   else if(op==1)
      z = x-y;
   else if(op==2)
      z = x*y;
   else if(op==3)
      z = x/y;
   return z;
}

Porque não começamos evitando as variáveis “x”, “y”, “i” e “z”? A prática mais básica do Clean Code é nomear decentemente as variáveis de acordo com o que ela é. Há uma convenção de usar substantivos como nome para variáveis. No nosso exemplo, podemos substituir “x” por “fator1” e “y” por “fator2”, “op” seria “operacao” e “z” seria o nosso “resultado”. Ficaria algo assim:

int calc(int fator1, int fator2, int operacao){
   int resultado;
   if(operacao==0)
      resultado = fator1+fator2;
   else if(operacao==1)
      resultado = fator1-fator2;
   else if(operacao==2)
      resultado = fator1*fator2;
   else if(operacao==3)
      resultado = fator1/fator2;
   return resultado;
}

Já está mais claro, porém, o nome da nossa função não significa nada. O nome da função deve deixar claro o que ela vá fazer. Outra convenção aqui é colocarmos verbos para as funções. No nosso caso chamaremos nossa função de “calcular”.

int calcular(int fator1, int fator2, int operacao){
   int resultado;
   if(operacao==0)
      resultado = fator1+fator2;
   else if(operacao==1)
      resultado = fator1-fator2;
   else if(operacao==2)
      resultado = fator1*fator2;
   else if(operacao==3)
      resultado = fator1/fator2;
   return resultado;
}

Pronto, já demos uma boa melhorada, porém nossa função além de mal construída, está fazendo muita coisa. Vamos continuar ao trabalho.

Métodos/Funções Enxutas
Outra prática fundamental do Clean Code é quebrar os métodos/funções em coisas menores, a ponto de cada uma fazer uma coisa específica. Isso, além de facilitar na leitura do código, nos ajuda na hora de depurarmos o programa. Imagina se houvesse um erro na nossa função exemplo e o nosso compilador nos aponta somente a função que possui um problema. Como só temos uma única função, não temos como saber em qual das condições está o erro, porém, se para cada uma das condições possuíssemos uma chamada para uma outra função específica para o que queremos.

int calcular(int fator1, int fator2, int operacao){
   int resultado;
   if(operacao==0)
      resultado = somar(fator1,fator2);
   else if(operacao==1)
      resultado = diminuir(fator1,fator2);
   else if(operacao==2)
      resultado = multiplicar(fator1,fator2);
   else if(operacao==3)
      resultado = dividir(fator1,fator2);
   return resultado;
}

Agora teríamos uma função para cada operação específica, nosso depurador vai indicar a função certa em caso de erro e, apesar de não ficar tão evidente no nosso código, temos agora uma função mais limpa. Imagina se no lugar de uma única linha, tinhamos antes umas 13 linhas dentro de cada condição. Substituir 13 linhas por uma chamada de função, torna o código bem mais limpo. Outra coisa que podemos melhorar é essa quantidade de if/else. Vamos usar um switch/case e teremos um código bem mais legível.

int calcular(int fator1, int fator2, int operacao){
   int resultado;
   switch(operacao){
      case 0: resultado = somar(fator1,fator2);
              break;
      case 1: resultado = diminuir(fator1,fator2);
              break;
      case 2: resultado = multiplicar(fator1,fator2);
              break;
      case 3: resultado = dividir(fator1,fator2);
              break;
   }
   return resultado;
}

O código agora já fala por sí só, você lê, você entende o que ele está fazendo, não precisamos mais de linhas e linhas de documentação, o que nos leva para a próxima prática básica.

Poucos comentários
Como dito anteriormente, o código fala por sí só agora. Perdemos um pouco mais de tempo escrevendo um código decente e limpo, em que fica explicíto o que está sendo feito, e nos poupamos de escrever linhas e mais linhas de documentação além de nos facilitar o trabalho em uma possível manutenção.

Não comente um código ruim – reescreva-o.
Brian W. Kernighan e P. J. Plaugher, autores

Comentários no programa, para o Clean Code, só fazem sentido se forem explicar uma lógica não muito clara de uma função, por exemplo: nenhum programador precisa saber cálculos de contabilidade, por isso, caso tenhamos de desenvolver uma aplicação para a área, podemos utilizar comentários para explicar o que aquela equação calcula e como ela faz isso. Fora isso, o código será autoexplicativo o suficiente para tornar qualquer outro comentário desnecessário.

Espero que tenha ficado tudo bem claro assim como os próximos códigos de vocês.
Estou com um projeto no meu github onde estou treinando todas as técnicas passadas aqui.

Caso queiram acompanhar, ou até colaborar com ele, o link do repositório está aqui.

A POO tenta auxiliar o programador na resolução de programas permitindo uma Abstração do mundo real para a programação. Agora nos temos Classes que possuem Atributos e que executam Métodos. Tentarei me utilizar da Abstração para criar uma metáfora com um cenário de RPG.

Uma Classe poderia ser um Elfo; ele possui Atributos como Nome, Idade, Tamanho, Cor do Cabelo; e ainda executa Métodos como Correr, Atacar, Caçar.

Porém, algumas desses Atributos e Métodos não são exclusivos dos Elfos; Humanos, Orcs e Anões também possuem tais informações. Portanto, modificaremos nosso cenário criando uma Classe Abstrata chamada Raça com tudo o que colocamos anteriormente na nossa Classe Elfo e faremos Elfo herdar essas informações. Agora estamos vendo o conceito de Herança e de Classe Abstrata. A Herança serve para evitar reescrita de código enquanto já auxilia o programador a organizar o seu projeto deixando tudo mais limpo. Uma Classe Abstrata serve somente de base para outras classes, não podendo ser instanciada, ou seja, não existe algo que seja a “personificação” de uma raça, mas sim de Elfo, Humano, Orc ou Anão, que são raças.

Criando classes para cada uma das raças, herdando as características da Classe Raça, teremos algo semelhante a isso:

De acordo com esse diagrama, temos Raça como uma Superclasse (ou Classe-Pai) de Elfo, Humano, Orc e Anão, que são Subclasses (Classe-Filho) de Raça.

Outro conceito interessante da POO é o de Encapsulamento, que se deve basicamente em executar determinada função sem precisar saber como as coisas funcionam, necessariamente. Um Rei que deseja enviar uma carta para um outro reino, só precisa pedir para um serviçal, que todo o resto acontece como mágica para ele. Isso é útil para evitar perda de tempo tendo que ensinar ao Rei a escrever, como adestrar um pombo e tal.

Agora que temos as nossas raças criadas, temos de criar especificações para os nossos personagens. Um Orc tem um método padrão de ataque. Porém temos Orcs Guerreiros que não atacam da mesma maneira que os demais, mas também atacam. Essas adaptações de métodos de uma Superclasse por uma Subclasse se chama Polimorfismo, outra base da POO. Ou seja, o método de ataque de um Orc Guerreiro é diferente do padrão, chamamos isso de Sobrescrita (Overriding). O Orc Guerreiro além desse ataque diferente, se ele possuir flechas, ele pode atacar com um arco. Como esse método de ataque respeita uma condição adicional (só ataca enquanto possuir flechas) se trata de uma Sobrecarga (Overload).

Por mais que sejam metodologias diferentes, possuem muitas semelhanças notáveis. Spoiler alert: simplicidade, comunicação, trabalho em equipe e atenção ao cliente, são as bases para essas metodologias, portanto serão repetidas com frequência.

Agile

No Manifesto Agile encontramos as “leis” que regem essa metodologia e os princípios por trás dela.

Basicamente, o diferencial do Agile em relação a “metodologia tradicional”, é o trabalho com as pessoas e não somente com as máquinas. A comunicação é um pilar essencial do Agile que valoriza muito um bom relacionamento entre os membros da equipe e da equipe com o cliente. O cliente que aqui é o foco de todo o desenvolvimento, uma vez que ele é o mais interessado no produto, nada mais justo que ele esteja sempre presente nas etapas do desenvolvimento através de feedbacks que ajudam a equipe a entregar o projeto de acordo com o desejado. Há quem diga que essa participação ativa do cliente ajuda na compreensão de eventuais atrasos.

Quanto ao projeto em sí, são entregues pequenos pacotes do produto final ao cliente para que ele já possa ir usufruindo de algumas funcionalidades já prontas do projeto. A prioridade desses pacotes são definidas pelo cliente de acordo com a sua necessidade.

XP (eXtreme Programing)

No XP temos práticas levadas ao “extremo”, como o nome sugere. Basicamente, se uma prática é boa, que seja feita o tempo todo. Testes, revisões, simplicidade são algumas das práticas adotadas pelo Extreme Programming. Há também seus princípios como o Pair
Programming, o código fonte coletivo e padronizado, por exemplos.

O diferencial do XP em relação ao Agile, é que o XP traz mais detalhes sobre como proceder no projeto em sí. Como deve ser a conversa com o cliente, como deve ser o código, como a equipe deve se comportar em relação ao código, enfim, é como se o XP trouxesse o Agile como uma filosofia, um ideal, e tentasse nos guiar para alcançá-lo.

Algumas práticas do XP que achei importante destacar:

• Metáforas: sempre lidar com o cliente através de metáforas para facilitar a compreensão, uma vez que o cliente pode não ter conhecimentos em programação.
• Documentação enxuta: documentar somente o necessário e tornar o código em sí algo fácil de se entender. Uma documentação muito grande só dará o trabalho de escrever as coisas duas vezes.
• Código coletivo: de acordo com o XP, o código é responsabilidade da equipe e não de um único indivíduo.
• Padrão de código: combinar com a equipe um padrão para a escrita do código. Como o código é coletivo e terá pouca documentação, utilizar um padrão para se programar facilita o entendimento do código pela equipe.

Lean

O Lean, semelhante ao Agile, se trata mais de uma filosofia do que uma prática em si. Ele trás como prioridade a redução de desperdícios tanto de tempo, quanto de dinheiro através dos seus princípios básicos.

De acordo com o LEAN, o cliente deve ter liberdade para definir o que é de maior prioridade para ele. Agora, trabalha-se somente com aquilo que agraga valor ao produto nesse momento, evitando assim desperdícios de tempo. Com o “To Do” do projeto feito, cria-se um fluxo contínuo de trabalho, respeitando as definições das etapas anteriores, em que uma etapa do processo só pára quando for entregue ao cliente (One-Piece Flow). Agora com o produto todo entregue, busca-se problemas para a melhoria constante do mesmo agregando mais valor, não só ao produto, mas também ao cliente.

Aqui vai um video explicativo do One-Piece Flow.

Kanban

O princípio básico do Kanban é tornar o fluxo de trabalho algo visível, palpável. Isso ajuda a equipe a se organizar, aumentando a produtividade. O Kanban consiste comumente em um quadro em que se organiza uma tabela com situações possíveis de uma tarefa. A tarefa é representada por um papel colorido, ou post-it, que “passeia” pela tabela de acordo com a sua situação atual. A cor do papel também é uma ferramenta para facilitar a compreensão, podendo ter cores diferentes para uma determinada característica de uma tarefa: vermelho possui alta prioridade, amarelo normal, e verde baixa prioridade, por exemplo. Outra ferramenta importante no Kanban é o WIP (Work in Progress) que se trata de um limite de tarefas para uma determinada coluna na tabela. Isso serve para que possa ser visualizada onde o trabalho está trancado e possa precisar de uma ajuda.

Cada método apresentado tem suas funcionalidades individuais, mas não precisam ser necessariamente aplicadas separadamente. Há uma definição que diz que essas metodologias são como ferramentas dentro de uma caixa de ferramenta. Não há uma ferramenta melhor que todas, mas há a melhor para cada situação individual, e tendo todas à disposição e aplicando elas em conjunto, temos então um desempenho extremamente eficiente com um trabalho de qualidade.