Neste artigo, explico como funciona o estágio aqui na Doutbox e, além disso, compartilho a terceira parte do meu projeto como estagiário. Confira!

Se você ainda não leu a introdução do meu projeto de estágio, clique aqui para ler a parte 1.

3. DESENVOLVIMENTO

3.1 Git

Tarefa: Estudar as principais funcionalidades do git.

Antes de tudo deve-se criar o .git no repositório com git init.

1. Git push: vai enviar os arquivos alterados ou criados para o repositório especificado.
2. Git pull: vai puxar os arquivos atualizados do repositório especificado.
3. Git merge: vai fazer a fusão do projeto base com a atualização feita através do git merge;
4. Branchs: as branchs são ramificações, ou partes da aplicação, é comum que a branch principal seja nomeada main, e quando se quiser alterar esse código sem causar problemas pode-se adicionar outra branch com um nome diferente e por o código alterado lá.
5. Commits: é como enviar as alterações para uma branch, deve-se adicionar um comentário para facilitar o entendimento do que foi alterado.

3.2 Gitlab

Tarefa: estudar as principais funcionalidades do Gitlab, favor avisar para fazermos um tutorial de utilização.

Com a ajuda do Attus inicialmente foi acessado o gitlab e adicionado um projeto inicial, dentro desse projeto foi criado a branch inicial, e também criado uma issue de teste. Depois foi pego o link para por na origin através do terminal, dentro do terminal foi configurado as informações de usuário e dado o commit inicial, depois feito os testes dos comandos git, para ver se estavam funcionando corretamente, depois foram incluídas alterações através de branchs diferentes no projeto através do merge, para manter o controle de versão e deletada a branch secundária.

3.3 Docker

Tarefa: Estudar as principais funcionalidades do Docker, (container, imagens, DOCKERFILE, docker-composer, vantagens, desvantagens).

O docker fornece containers para que possam ser colocadas a aplicação e as suas dependências, então elas poderão funcionar em qualquer outra máquina que contenha o docker também.

A imagem é onde serão salvas as configurações de ambiente(Sistema operacional, versões das ferramentas, etc) e disponibiliza essa imagem para que os containers utilizem essa imagem para rodar, sem que cada usuário tenha que manualmente alterar seu ambiente para que a aplicação funcione. è quase como uma VM para rodar uma aplicação.

DockerFile é onde será construída a imagem do para que a aplicação seja rodada, é basicamente um documento com linhas de comando e quando executado ele vai executar cada linha de comando criado a imagem que se deseja que criar.

Docker-compose é uma ferramenta para definir e rodar uma aplicação docker com múltiplos contêineres quando usado o comando docker-compose up ele vai automaticamente rodar a aplicação se não houver nenhum erro na criação.

3.4 Boas Práticas de Programação

3.4.1 DRY

Tarefa: Estudar as vantagens, exemplificar com código.

• DRY - Don’t Repeat Yourself (Não Se Repita), se um código for necessário em vários locais, deve-se arrumar uma maneira de especificar o código em um lugar e só chamá-lo quando for necessário.

Exemplo: a barra de navegação de um site, pode-se criar um arquivo que contenha apenas essa barra, e ela ser chamada em todas as telas:

Figura 4: criando a template de navegação da página

Figura 5: página inicial, onde será chamado template de navegação

3.4.2 YAGNI

Tarefa: Estudar as vantagens, exemplificar com código.

• YAGNI - You Arent’t Gonna Need It (Você Não Vai Precisar Disso), criar algo que pode ser útil futuramente as vezes pode parecer uma boa ideia, mas pode ser que se torne algum recurso inútil que apenas irá pesar a aplicação no futuro, então não é interessante criar algo que "pode" ser usado no futuro, mas pode não ser também.

Exemplo: a tela de Account é criado e chamado, mas não tem conteúdo nenhum:

Figura 6: template de navegação com a chamada da tela de Account

Figura 7: tela de Account vazia

3.4.3 DECOUPLING

Tarefa: Estudar as vantagens, exemplificar com código.

• Decoupling - (Dissociação), muitos códigos geralmente tem classes que geram muita dependências entre elas, e é muito importante manter as dependências no menor nível possível, porque vão existir casos em que uma classe é atualizada, e a classe dependente acaba apresentando erros, por isso ao dissociar o máximo possível do código, a manutenção do mesmo se tornará uma tarefa muito mais fácil, tanto para quem desenvolveu, tanto para um terceiro que precisar efetuar a manutenção.

Figura 8: tela inicial antes de utilizar decoupling

Figura 9: tela inicial depois de utilizar decoupling

3.4.4 REUSABILITY

Tarefa: Estudar as vantagens, exemplificar com código

• Reusability - (Reutilização), existem partes dos códigos que seguem um padrão independentemente até mesmo se forem aplicações diferentes, é muito importante criar um padrão para esses códigos que sejam facilmente adaptáveis para outras partes de um projeto ou até para outros projetos.

Figura 10: cabeçalho (base apenas) que pode ser reutilizado

3.4.5 READABILITY

Tarefa: Estudar as vantagens, exemplificar com código

• Readability - (Legibilidade), manter um código que qualquer desenvolvedor possa facilmente ter o entendimento do que está sendo feito por um determinado código, sem isso a manutenção do código pode ser uma tarefa mais árdua do que deveria. para que o código se torne legível é importante comentar e indentar o código, os comentários não devem ser feitos para coisas óbvias, isso irá tomar tempo desnecessário.

Figura 11: código indentado e comentado, com fácil entendimento

3.4.6 SINGLE RESPONSIBILITY

Tarefa: Estudar as vantagens, exemplificar com código.

• Single Responsibility - (Responsabilidade Única), é o princípio de que todos os módulos, classes e funções devem atender a apenas uma parte da funcionalidade de um programa, segundo Robert C. Martin, uma classe deve ter apenas uma razão para mudar, por exemplo, uma classe que compila e mostra um relatório, essa classe vai ter dois motivos para ser alterada, primeiro, o conteúdo do relatório pode ser alterado, segundo, o formato do relatório pode ser alterado. Segundo o single responsibility esses dois aspectos do problema são de responsabilidades diferentes, então deveriam ser classes diferentes.

Utilizando um CRUD em laravel como exemplo:

Figura 12: o layout tem apenas a obrigação de criar o layout da aplicação

Figura 13: o create tem apenas a obrigação de criação dos itens

Fontes: www.medium.com / www.hashbangcode.com / www.digitalocean.com / www.thinktocode.com / www.github.com