DEV Community: Alex M.

Aprendizados de 1 ano de projeto em vue.js com escopo ultra caótico

Alex M. — Tue, 26 Jan 2021 17:47:17 +0000

tl;dr: Implemente Design System, componentize, faça componentes base, faça testes unitários / de integração, não ignore o log do terminal. O trabalho dos designers pode facilitar muito a vida do front.

Uma das coisas mais legais de trabalhar na Snowman Labs é que cada hora surge um pepino diferente pra gente resolver. E a gente gosta disso, faz parte da natureza do programador, eu diria. A gente já resolveu cada bucha que daria um artigo por si só.
O último projeto que participei foi um desafio técnico e tanto, por uma série de fatores. Várias coisas foram reescritas várias vezes, e a gente tinha noção de que isso ia acontecer, então cada tomada de decisão em relação a arquitetura foi feita com bastante cautela, tentando prever o que poderia mudar e o que a gente poderia fazer pra minimizar a quantidade de problemas e a eficácia do reaproveitamento.

Em determinado momento o sistema foi dividido em dois (repositórios diferentes) e depois mergeado de novo, o que colocou em teste nossas decisões. Felizmente, o merge foi muito menos doloroso do que poderia ter sido.

Um pouco de estatística de nerd: Tivemos 185 componentes de features (inteligentes e burros) e 47 na pasta core, ou seja, componentes que não pertencem à nenhuma feature específicam, totalizando 232 arquivos .vue na versão que foi entregue ao cliente. Ouso dizer que pelo menos a mesma quantidade de arquivos foi deletado por conta do escopo caótico do projeto (e descansam em paz no nosso git). O que não é necessariamente um problema, Agile é feito justamente pra lidar com esse tipo de problema.
Ao longo de alguns projetos de git que compuseram esse projeto, tivemos 2181 commits, distribuidos em 671 merge requests que foram de fato mergeados. Houve uma média de 2% de merge requests que foram fechados ao invés de serem mergeados na master.
A versão final do projeto possuía pouco mais de 20372 linhas de código na sua pasta de features, e 3004 na pasta core, que, graças a elas, poupamos de escrever muita coisa redundante na pasta de feature.

A componentização pesada ajudou bastante a gente a lidar com os problemas.
Slots não foram tão usados (foram fundamentais em pontos específicos, como forms e elementos de UI com miolo dinâmico), felizmente a maior parte das vezes conseguimos resolver com parametrizações.

Aqui vou deixar alguns pontos chave que aprendemos ou queremos reenforçar como aprendizado nesse projeto:

Pontos de valor

Designers podem ajudar (e muito) no desenvolvimento

O Design System ajuda a padronizar o tema e a componentização do sistema, facilitando a vida do dev front, auxiliando na tomada de decisão independente (fica muito mais fácil pro desenvolvedor). Felizmente, nesse projeto, tivemos designers competentes (vlw Rubens e Stoco) já deixando tudo preparado e sólido pra trabalhar. Às vezes o povo do front tem que colocar um botãozinho, ou um inputzinho. Com um Design System funcional e robusto, o front pode se aventurar em meter a mão na UI para coisas pequenas sem precisar encher o saco do designer pra alterar o protótipo praquela coisinhazinha ali. O que não é a melhor coisa pra se sair fazendo, mas sabe como é, o tempo urge e a sapucaí é grande.

Uma boa componentização (misturado com Design System) pode transformar criar telas novas em lego. Quando entrou um dev front na metade do caminho (fala, Puff!), com pouca experiência em vue (mas já em outros frameworks), fazer a parte de UI foi praticamente um drag and drop dos componentes que já existiam. A semântica e a simplicidade de usar os componentes (tanto os base quanto os da feature) permitiram que tudo fosse criado muito rápido, e sem ficar com cara de copicola em código que já tava funcionando. Com uma introdução bem rápida ao projeto, já dá pra tacar o pau. Se tiver tudo em storybook, melhor ainda! Não foi o caso desse projeto kkkkkkkk embora usamos em outro projeto anterior e gostamos bastante. Super recomendamos.

O front ama quando o designer faz as coisas já baseada num framework de UI

Nesse projeto decidimos trabalhar com o vuetify, que é baseado em material, e os designers montaram os componentes todos no vuetify . Sendo assim, quando a gente foi codar os componentes base, a gente praticamente só extendeu e customizou os componentes do framework. Isso poupou muito tempo e deu muito poder aos fronts, agilizando muito o desenvolvimento do look and feel geral do sistema, além de reduzir significantemente a quantidade de código escrito e repetido no sistema.

Vuetify + Componentes base para não precisar escrever CSS

Isso é uma das coisas mais legais de desenhar sistemas com Design System e componentes base (e designers competentes, claro. Valeu Rubens e Stoquinho). 90% dos componentes de página (sem exagero) possuem 0 CSS escrito. Tudo está como parâmetro de componente, customização ou defaults do vuetify e classes helpers do vuetify

Feature modules são uma ótima forma de organizar coisas

Como um teste, decidi propositalmente não usar feature module (tip #1, não tem link direto, infelizmente) no sistema para ver em que momento a organização sai do controle. Descobrimos rapidinho que, com 5 ou 6 features no sistema, você já começa a ficar incomodado e quer uma separação melhor. Além de ajudar bastante na orgnanização, ainda torna o namespacing menos verboso por conta da localização dos arquivos no filesystem.

Mixins sao poderosos e perigosos

Mixins são poderosos pois permitem lógicas de componentes serem reutilizadas e escritas em um lugar só, porém, nos frameworks de front em geral, essa feature deixa alguns problemas de DX ao ser utilizada. Pra mim, o mais marcante deles é não ter um namespace claro. Quanto mais mixins você tiver utilizando, mais você não vai ter a menor idéia de onde aquele trecho de código vem. Além de outros, como colisão de nome (princípio parecido com o de não usarmos prototype no js), etc.

Sintaxes alternativas para componentes e typescript

Vue2 não é muito bom pra lidar com typescript de forma vanilla, então o próprio core team e a comunidade criaram soluções pra você ter sintaxes alternativas (nada muito diferente) que suportam os toolings mais modernos e que tiveram maior adoção no decorrer dos últimos anos, como o vue-class-component, vue-property-decorator e o vuex-class.
O caso mais notório de ferramenta que tira proveito disso, com certeza é o typescript. Com essas tecnologias, usar typescript é 100% possível, e usando essas sintaxes alternativas, diria até que o código fica mais enxuto e claro do que o vue sem nada (@Action do vuex-class, pra mim, tem uma sintaxe mais agradável que mapActions do vuex cru, por exemplo).
Começamos o projeto sem, mas o Brunão começou a implementar usando isso e com uma curva bem pequena de aprendizado, aderimos felizes ao novo método de escrever componentes vue2.

Testes se pagam rapidamente

A comunidade de front só tem dado a devida atenção a testes de uns anos pra cá, sempre foi um inferno testar as coisas, e eu nem sempre fui a melhor pessoa para advogar o uso de testes kkkkkkkkk inclusive, até um tempo atrás, eu era explicitamente contra, com um tom de ironia mas um fundo de verdade.
Muito dos meus receios em começar a aplicar eram baseados totalmente em ignorância do ferramentário e desgosto em encarar a curva de aprendizado e o tempo extra ao desenvolver as features. Porém, quanto mais eu decidi encarar, mais foi ficando claro que o tempo investido vale a pena, pois traz segurança e te poupa muito tempo em descobrir ONDE alguma coisa não tá mais funcionando. Ainda há muito a estudar e pegar fluidez, mas quanto mais testes você faz, mais rápido fica fazê-los.

Jest first, depois cypress (eu acho)

Eu comecei usando cypress pois achava bem mais simples testar se algo estava funcionando simplesmente usando o próprio browser, mas depois de me aventurar com jest (usando vue-test-utils, percebi que: ele é bem mais rápido, e os testes tem uma função razoavelmente diferente (o cypress não te diz onde algo tá quebrado a nível de código, e sim a nível de "tem alguém usando isso aqui e não tá funcionando").
Eu comecei escrevendo testes pro sistema em cypress, mas toda vez que eu ia mexer, era leeeeento. Inclusive tive que pedir pra colocarem mais ram no meu maczinho (imac de 2011, guerreiro) pois eu não tinha ram suficiente pra rodar o cypress e todo o resto do ferramentário (e olha que eu nem usava o VSCode ainda).
Suspeito que dava pra ter feito tudo que eu fiz em cypress, usando jest, o que teria uma curva de dificuldade um pouco maior, mas o uso dos testes seria extremamente mais rápido e útil. Mas apenas suspeito. O próximo sistema vai ser feito "jest-first", vamos ver o que vem por aí, não dá pra saber ainda.

Módulo core pra coisas gerais (mas usar com cuidado)

Devido a uma decisão de arquitetura que tomamos, o sistema todo é cru, e a gente injeta os feature modules num sistema que, em seu estado inicial, só possui a feature de login. Portanto, temos um "módulo core" onde colocamos tudo que não pertence especificamente a módulo nenhum. Isso agiliza muito as coisas, porém tem seus drawbacks. Há de se mexer nesses caras com bastante cuidado, pois não se sabe exatamente quais partes do sistema utilizam ele. Entretanto, o fato de estar em "core" já deixa isso meio implícito. Há algfuma forma melhor de fazer isso? Não sei, não pensei direito ainda. A idéia de usar os core para extender em componentes de cada feature parece interessante, mas talvez desnecessariamente verbosa, mas é a primeira ideia que me passa em mente.

Performance e bundle size são pontos relevantes

Rapaz, a bundle final do sistema deu 13mb! Num sistema web! Lógico que isso não pode ficar assim. Imagina, ter que carregar 13mb só pra usar o sistema. Dito isso, fui atrás de técnicas pra reduzir o bundle e diminui de 13mb pra 2mb. Ainda dá pra dar uma escovadinha aqui ou ali, porém já temos um excelente ganho. Um dos grandes culpados é o vuetify, que se colocado de qualquer jeito adiciona um tamanho bem significativo ao sistema, mas o próprio vuetify te ensina formas de usar a biblioteca da forma mais enxuta possível. A forma que o vue2 foi desenhado não permite usar alguns recursos de redução de bundle do webpack, o que é somewhat triste, mas reclamar disso é pedir demais pelo trabalho dos caras. Inclusive, alguns dos problemas que existem nesse quesito, se bem me recordo, vão ser adereçados no vue3, então os caras já estão cientes e trabalhando nisso.

Negligenciar os logs do terminal... nem dá nada, até ser tarde demais

O build é feito, mas não consigo ver o output por conta dos erros do log

Eu não sei em que momento do projeto a gente parou de dar bola pros linters. Tem toda uma treta encima do eslint e sua compatibilidade com typescript (tslint foi descontinuado e virou outra lib que, enquanto estávamos desenvolvendo ainda estava bem imatura se bem me lembro) e numa mistura de prettier, eslint, typescript, chegou uma hora que nos embananamos e não deu pra dar conta mais. Isso sem contar com o fato de eu usar o Sublime Text antes (saudades), que no meu ubuntuzinho, não tinha a melhor das integrações com linter (parte porque meu ubuntu sempre vive meio quebrado). Mas tava tudo funcionando, né.

Daí chegou um ponto que começou a atrapalhar. Não conseguíamos ver o output do comando de build, não conseguíamos mais usar o logo como auxílio, regras de typescript quase não faziam sentido mais. Até tentei fazer uns refactors pra ir limpando essas coisas, mas a pressão do projeto me obrigava a avançar mais rápido do que meus refactors davam conta. Só fui sentir a dor de verdade quando fui otimizar a build final: tive que desativar o typescript e os linters pra fazer que o comando rodasse sem erro, e aí sim entendi alguns gargalos que não tinha noção antes (até tinha, mas não passava de "em ambiente de homolog leva muito tempo pra abrir o sistema", seguido por um "as otimizações necessárias ainda precisam ser feitas").
Não deixem chegar a esse ponto, menines.

Coisas que senti necessidade / Looking forward to:

Styled components

Tem várias strings gigantes de várias classes que foram repetidas em vários momentos. Com certeza dava pra agregar elas em unidades de classes semânticas (o que seria meio que dar um 360 no conceito de CSS funcional, mas há o debate de que CSS funcional é um 360 encima do style inline... enfim, discussão pra outro momento). O importante é que eu senti falta de aplicar isso no sistema a partir de um determinado momento. Tenho certeza que, com styled components, os templates ficariam significantemente mais enxutos e semânticos.

Typescript

Finalmente caiu a ficha sobre typescript. Quanto maior o código, maior a chance de você não saber o que tem naquela variável. Além da tipagem, typescript também documenta as coisas, facilita a vida de quem for mexer naquele código depois e não tiver tudo na ponta da língua. Meu uso de typescript nesse projeto deixou a desejar, mas já foi o suficiente pra entender o real valor desse negócio que eu tive tanta resistencia em usar, afinal, "vai demorar mais pra escrever as coisas!"

Usar mais o vuex...? Talvez?

Eu uso esse fluxograma que tem me servido bem como guia de tomada de decisão:

Porém, às vezes fico pensando se talvez desse para passar mais lógica de processamento para o vuex. Esse projeto não teve cache de dados, nem uma hierarquia complexa de componentes. Claro, há bastante informação no store, mas quase sempre era nas camadas de estrutura do projeto, e não nas features em si. Sempre quando vou ver outros projetos grandes, eu vejo umas stores ultra boladas, e fico pensando: será que eles tão jogando as coisas no vuex onde não precisa? Será que meu projeto realmente não precisa de vuex? Ou será que eu tô fazendo algo errado?

Conclusão

Espero que tenham tirado algum proveito. O Vue 2 dá pra fazer bastante coisa dahora, e consideravelmente mais simples, rápido e divertido que nos outros frameworks (sou enviesado pra falar por ser o framework que mais usei até agora? Imagiiiina...).
Muitas necessidades foram surgindo no meio do caminho da timeline do desenvolvimento do framework, e foram sendo adereçadas pela comunidade enquanto a ideia de uma forma mais nativa para se resolver era matutada em background pela galera do desenvolvimento do Vue 3, que já saiu e provavelmente vai ser usado no próximo projeto aqui na Snowman Labs.

Agilidade e eficiência no git com oh-my-zsh

Alex M. — Tue, 28 May 2019 20:17:37 +0000

Já dizia o FBI, Winners don't use GUI. Se você gosta daqueles negócio de git kraken, sublime merge, etc, tudo coloridinho e bonitinho, esse artigo não é pra você. Aqui só fica quem é hackudo com força, nerdão dos terminal, que quando garoto abria o cmd do windows e ficava digitando qualquer coisa na telinha preta até ter que formatar o windows pois apagou a system32 por acidente.

Você tá cansado de digitar os comandinho do git tudo, amiguinho? Seu workflow é orientado a git mas você não aguenta mais abrir o terminal pra ficar criando branch, dando comitinho e pushzinho? É um saco, né, digitar um monte de tralha e apertar tab várias vezes até achar a branch que você quer. Eu te entendo, eu também sofria disso. Sofria, pois agora com os poderes cabulosos do oh-my-zsh, meus problemas acabaram! Os seus ainda não, mas vão acabar assim que você ler esse artigo.

Primeiramente, instale o oh-my-zsh na sua máquina. Ele é lindo e você nunca mais vai querer trocar. Depois, leia com atenção os poderes que os plugins de git e git-flow dele possuem:

`gcd && ggpull`

Atalho para git checkout develop && git checkout origin git_current_branch, ou seja, acabou uma feature? Publicou, foi lá e fez o PR? Foi aceito, mergeado? Ótimo. Manda esse comando que sua develop já vai refletir a develop remota. Dependendo do seu fluxo essa pode ser a forma mais eficaz (caso você possa ir lá e aceitar o seu próprio PR por qualquer razão) ou não (precisa de um code review, precisa que alguém aceite o PR, etc.) antes de começar a trabalhar em outra feature.

`gapa [&& gc]`

Atalho para git add --patch (ou simplesmente -p). Olha, se você se sente confortável usando git commit -a, beleza. Mas eu sugiro que você dê uma olhada em como funciona o --patch ou -p, porque ele te dá um nível de controle incrível do que vai pra stage ou não. Depois que eu me acostumei a usar as letrinhas do comando, só uso isso agora. Ou dou gapa ou dou gc -p (git commit -p, infelizmente o plugin de git do ohmyzsh não tem plugin nativo para git commit -p, e gcp já se refere à git cherry-pick)

`gcb nome-da-branch`

Atalho para git checkout -b nome-da-branch. A agilidade que esse comando te dá é ótima. Nunca mais digitar git checkout branch e perceber que esqueceu a flag, daí reescrever o comando ou apertar setinha pra cima, colocar o cursor no lugar certo, digitar -b e dar enter. Com esse comando, não tem erro. Curto, prático e eficaz.

`gcam "mensagem do commit"`

Atalho para git commit -am ""mensagem do commit". OK, eu não aconselho você a usar esse comando, mas caso você viva la vida loka, full XGH, boladão sem freio, go fast break things, manda bala. Confesso que já usei muito, mas graças a Ancient Apparition me livrei desse mal que me afligia.

`/ggpu(sh|ll)/`

Atalho para git push origin git_current_branch e git pull origin git_current_branch, respectivamente. Esse, assim como o gcb, foi um dos comandos que mais fiquei feliz de aprender. Nunca mais precisar digitar as 2 primeiras letras do nome da branch e ficar apertando tab até achá-las! Nunca mais se perder! Hooray, agilidade!

`gcm`

Um dia eu fui um jovem plebeu que commitava coisas na master. Daí eu passei a criar branches a partir da master. Hoje o git frô me apresentou a solução e o caminho da luz para muitos problemas que me assolavam. Mas caso você ainda necessite ir até a master frequentemente, gcm é a forma mais ágil para isso.

`ggu`

Atalho para git pull --rebase origin git_current_branch Se você é do #TeamRebase, esse comando é seu novo amorzinho. ggu e pronto. Tá na mão, garotchenho.

`gl` e `gp`

Atalhos para git pull e git push. Versatilidade com rapidez. Depois de gl e gp, você pode argumentar à vontade com seu comando e ter o melhor dos dois mundos na ponta dos seus dedos.

`gdba`

Atalho para git branch --no-color --merged | command grep -vE "^(\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d Rapaz, use esse comando com cuidado. Ou não, como a gente bem, sabe, deu merda no git? cd ..... Esse comando joga fora toda a louça descartável que tá na pia, seu preguiçoso! Nem pra jogar os copinhos descartáveis fora, tsc tsc... Todas as branches que já foram mergeadas, exceto master, develop e dev (me corrigam se estiver errado), são apagadas, mas apenas em local. Ou seja, adeus pilha de branches velhas em local!

`gc!`

Atalho para git commit -v --amend. Um clássico. Digitei a mensagem errada e só percebi depois que saí? gc!, corrige, salva e sai. Quanto mais disléxico, mais útil.

`glo`

Atalho para git log --oneline --decorate. Ver todos os commits em oneline, com hash, merge e corzinha. Inclusive, eu sugiro que você teste e dê uma boa olhada em todos os possíveis atalhos para git log. Definitivamente vale a pena o tempo investido.

`gsta` e `gstaa`

Atalho para git stash push e git stash apply. Respectivamente, coloca tudo na stash mais recente, e pega a stash mais recente e aplica de volta ao projeto. Muito útil quando você tem problemas pra trocar de branch because you left some unstaged changes

`gwch`

Atalho para git whatchanged -p --abbrev-commit --pretty=medium. git whatchanged é bem parecido com ´git log´ mas vai mostrando os arquivos que foram alterados em cada commit. A flag -p faz com que as alterações dentro do código sejam exibidas também. --abbrev-commit mostra a hashzinha e --pretty=medium é uma formatação de commit. Uso ele mais raramente, mas é bom saber que existe quando preciso.

Seus próprios aliases

Eu absolutamente encorajo (e confesso que devia fazer mais também) seus próprios atalhos usando os comandos do zsh. Tem qualquer sequência de comandos que você digita frequentemente? Vai lá e faz um alias pra eles juntos. Sabe aqueles git log ou git status customizados que você adora usar? alias neles. Você pode fazer no arquivo do seu shell (.zshrc) ou no seu git, usando git config. Eu prefiro deixar nos meus dotfiles, pois fica mais fácil de carregar pra lá e pra cá. Por exempl, eu gosto de git log --oneline --decorate --no-merges, então deixo um alias gl=comando lá no fim do meu ´.zshrc´
Faça os seus também, cada keystroke a menos que você dá, é menos uma keystroke que leva para você se tornar um legítimo hack3rboy.

Ah, mas o git flow?

Que bom que perguntou. A gente tem agilidade pro git flow também, que também é agilidade. Recursive agilidade. Caraca.

Você precisa instalar o plugin do git flow no seu zsh.

Olha, esse dá pra gravar todo na cabeça simplesmente entendendo como funciona o esquema de abreviação deles.
Os comandos básicos:

g => git

fl => flow

Os tipos de branch:

f => feature

h => hotfix

r => release

Os comandos específicos do gitflow:

s => start

f => finish

p => publish

Logo, se eu quiser dar um git flow feature start nome-da-branch, é só eu dar g + fl + f + s, ou seja, gflfs. Memela na pepela, meus camaradas.

Agilidade na prática

git flow já deixa as coisas super simples para produzir algo na sua codebase. Olha só como, depois de ter os atalhos na ponta da língua, as coisas ficam ágeis para subir uma feature.

Primeiro, gflfs nome-da-feature para iniciar a feature.
Depois, codar.
Terminou? gapa && gc (ou gc -p).
Fez o commit? Tudo certo? gflfp publica em remote automaticamente, tudo certinho.
Sua branch remota foi aprovada e mergeada na develop remota? gcd && ggpull, e sua local já tá atualizada.

Pimba. Mais fácil que isso, só um clone seu fazendo isso por você.

E aí, tem alguma coisa pra adicionar? Futucou o git.plugin.zsh e achou alguma coisa útil que você usa bastante mas não tá no artigo? Deixa nos comentários, que quem achar esse artigo depois, vai ler ele com merge do seu conhecimento.