Photo by Javier Allegue Barros on Unsplash
Como desenvolvedores de software, precisamos nos atentar às mudanças que ocorrem todos os dias nesse universo da programação. Estamos em constante aprendizagem, ou pelo menos deveríamos, e o nosso código deve refletir tais mudanças. Quero compartilhar algumas coisas que aprendi no decorrer desse último ano.
Trabalho no dia a dia como freelancer e em 2019 comecei a trabalhar em um sistema de chat. Aliás, conheci esse cliente no Workana ;) e seguimos juntos até hoje! De uma forma geral, apesar de existirem muitas outras funcionalidades, algumas até bem diferentes dessa primária, trabalhamos para manter esse sistema de entrega e recebimento de mensagens. Isso tudo envolve: Laravel, Vuejs, Node, MySql, Socket.io, Redis etc.
Bem, não fui eu quem criou o sistema, mas desde que começamos a trabalhar juntos, muitas mudanças têm sido feitas no código. Logo de início percebi que não haviam padrões no código atual, mas afinal eu também não sabia muito bem aonde escrever as coisas, como organizar o projeto etc. Possuía conhecimento das linguagens e frameworks, porém não de forma padronizada.
Photo by Erik Mclean on Unsplash
Refatoração
É o processo de modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo --- wikipédia
Estudar sobre refatoração, TDD (desenvolvimento guiado a testes), boas práticas... é algo excelente! O que acontece, porém, é que para aplicar tais técnicas no dia a dia, não algo tão fácil assim de ser feito. Imagine-se em um carro em pleno movimento e, de repente algo acontece no motor, por algum motivo você não pode parar o carro, mas ainda sim precisa consertá-lo! É mais ou menos isso o que vemos no dia a dia.
Quando comecei a trabalhar com esse sistema, ainda não fazia ideia de muita coisa, por exemplo:
- Separar código e não deixar tudo nos controllers.
- Validar entradas do usuário e não confiar que o que esperamos é o que realmente iremos receber.
- Não testar lógicas complexas e esperar que as coisas vão dar certo por si só.
- Não tipar variáveis em métodos (string $nome).
- Criar métodos e classes gigantescos e precisar dar CTRL+F no código.
- Não atentar a testes, preferir entregar tudo correndo, depois de algumas horas ou dias, ver tudo voltando por conta de bugs.
- Dentre outras coisas.
Quando o código não possui testes, todos têm pavor de fazer qualquer alteração que seja. O medo de quebrar todo o sistema faz com que o código ruim e legado, fique cada vez pior e mais legado.
Mudanças no código
Tá, mas o que fazer quando já se tem um código "funcionando", e algo novo precisa ser construído? Bem, é o desafio que tenho enfrentado nos últimos meses: há uns dois/três meses atrás começamos a atualizar a plataforma de chat! Desde que iniciei a trabalhar com este cliente, aprendi muita coisa, claro: ainda tenho muito o que aprender e melhorar, mas evolui bastante.
Algumas coisas que comecei a fazer de diferente:
No geral:
- Organizar melhor os commits, pra isso estou utilizando o Conventional Commits (feat, fix, style etc). Vale muito a pena!
No Vue:
- Preferir utilizar components e estilizá-los de nossa maneira, do que criar tudo do zero. Estamos utilizando o Vuetify ❤️ (um amorzinho). Ao invés de focar na criação de componentes, gastar mais tempo pensando na lógica do sistema.
- Comecei a usar o Vuex para comunicação e melhor gerenciamento dos meus components, ao invés de fazer diversas chamadas http para o backend, tento economizar e gerenciar melhor o conteúdo com Vuex.
No Laravel:
- Separar a lógica e reduzir a responsabilidade dos controllers. Comecei a utilizar Services e Repositories. Essa abordagem, embora possa ser melhorada, tem me ajudado a testar a parte das consultas ao banco com as factories do próprio laravel factory(User::class, 8)->make(). Quanto a parte da lógica no Services, e também as exceptions que podem ser recebidas pelo controller, como: UserNotFoundException.
- Além disso, comecei a utilizar mais Requests do Laravel e Exceptions. Com isso filtro melhor as entradas, e controlo melhor as saídas. Todo o código de validação de um formulário, por exemplo, pode estar dentro de um Request do tipo: UserFormRequest. E lá a verificação pra saber se aquele usuário atual tem permissão pra isso além da validação de campos.
- Não colocar tudo num mesmo banco, trabalhar mais com relacionamentos. Ao invés de criar uma tabela com trocentas colunas, preferir separar em tabelas menores, de acordo com a necessidade e tipos de informações.
- Filtrar somente as colunas que preciso antes de buscar no banco com select: ->select(['id', 'name']).
- Usar mais o DB::table('table_name')->where()->first() ao invés de usar sempre as Models. Principalmente quando preciso poupar tempo.
No Node:
Se tem uma tecnologia que tenho utilizado e me apaixonado ao longo dos dias, essa tecnologia é o Node ️️️❤️.
- Não tinha tanta experiência com Node, o código que sabia escrever com ele era procedural, esse ano comecei a aprender orientação a objetos e a aplicar de uma forma mais organizada.
Bem, é isso! Espero que tenham gostado! Até a próxima!
Top comments (3)
Interessante. Como não faz tempo que programei em laravel, não consegui acompanhar tão bem as mudanças que você comentou, talvez se tivesse exemplos ou links para alguma documentação fosse mais fácil de entender, e quem sabe fosse de interesse até para quem é de outras tecnologias. Desejo que continue evoluindo.
Sim, eu preciso fazer um post mais genérico. Nesse caso acabei falando mais sobre o Laravel e Vue. Vou preparar mais posts do tipo!
Obrigado pelo comentário e dicas! :D
Pode ser um post específico sobre alguma tecnologia, porém se demonstrar melhor o que é essa coisa que você está falando ou como fez, quem tiver menos experiência vai conseguir entender melhor, e quem usa outra tecnologia poderia adaptar ou procurar a alternativa na tecnologia que está usando.