VOLTAR
Este episódio estava planeado para ser publicado em dezembro, antes das férias de Natal, por isso parece que sou eu o culpado pelo atraso. Continuei a adiar a publicação semana após semana, à medida que algumas tarefas de alta prioridade se foram intrometendo, mas hoje é O dia.
No último episódio, tentei comentar o artigo sobre a importância do humor no local de trabalho, mas entretanto apercebi-me de que merece muito mais crédito, pelo que vou escrever um post inteiro sobre o assunto em breve.
Coisas que me mantiveram ocupado nas últimas semanas:
a) Antes do Natal, comecei com o episódio de estreia de "Série de webinars "À prova de bala CTO (fique atento ao segundo episódio em fevereiro com SaaS CTOs(detalhes em breve no meu LinkedIn).
b) Ajustar o nosso plano de crescimento para 2021 com o objetivo de ultrapassar os nossos Rubi e a atividade principal da JS e desenvolver uma Magento e Produto Competência de conceção interno.
Já chega de auto-promoção, deixem-me convidar-vos para o 5º episódio da nossa série #TheCodestReview.
Tópicos equipa preparou para este momento:
Os comentários sobre a aplicação front-end e os commits convencionais são entregues esta semana pelo nosso React engenheiros enquanto Ruby 3.0.0 pela nossa equipa de sonho Ruby.
Atualmente, muitos programadores utilizam bibliotecas de IU já criadas e componentes reutilizáveis para poupar tempo. É uma boa prática e ajuda nós para poupar muito tempo, mas quando o nosso projeto torna-se maior - compreenderá que não é suficiente lidar com código.
Existem dois bons padrões de desenvolvimento back-end - Domain Driven Development (DDD) e Separation of Concerns (SoC). Também podemos utilizá-los na arquitetura de front-end.
No DDD estamos a tentar agrupar funcionalidades semelhantes e dissociá-las o mais possível de outros grupos (módulos).
Com o SoC, por exemplo, separamos a lógica, as vistas e os modelos de dados (por exemplo, utilizando o padrão de conceção MVC ou MVVM).
Há muitas boas práticas e padrões a utilizar, mas, para mim, esta forma é a preferida.
Quando utilizamos este padrão, obtemos esta imagem:
No início, o utilizador é redireccionado para o módulo correto pelo encaminhamento da aplicação. Cada módulo está completamente contido. Mas, como um utilizador espera utilizar uma aplicação e não várias pequenas aplicações, existirá algum acoplamento. Este acoplamento existe em caraterísticas específicas ou na lógica comercial.
E nós temos esta estrutura:
pasta app - camada de aplicação
activos - pasta para imagens, tipos de letra, ícones, etc.
componentes - aqui devem estar componentes para reutilização que não tenham uma lógica complicada
config - aqui armazenaremos o estado global
lib - pasta para funções complicadas e cálculo lógico
módulos - eis os nossos módulos
pubsub - local para armazenar esquemas para descrever a estrutura de dados.
styles - para o nosso código css/scss
Esta estrutura ajudar-nos-á a lidar com a nossa aplicação em crescimento e a ter menos bugs. Além disso, ajudará a tornar mais confortável o trabalho com módulos separados, a testá-los e a facilitar a refacção e a depuração (devido aos módulos separados).
Se analisarmos mais profundamente a arquitetura dos módulos e as suas ligações com a API, obteremos algo semelhante:
Na pasta "app", criaremos outra pasta "api" com o código para as chamadas à API e os dados que guardaremos em "config/store". Aqui guardamos dados estáticos e imutáveis que utilizamos em toda a aplicação.
Também na pasta "pubsub/schema", descreveremos tipos de dados específicos para JavaScript objectos.
Todos os módulos contêm dados que precisamos de utilizar (utilizadores, itinerários, tabelas, acções, etc.). Cada módulo está ligado ao nível da aplicação e recebe todos os dados necessários.
O front-end é o primeiro ponto de entrada para os nossos utilizadores. Com o aumento das funcionalidades dos nossos projectos de front-end, iremos também introduzir mais erros. Mas os nossos utilizadores esperam que não haja bugs e que as novas funcionalidades sejam rápidas. Isto é impossível. No entanto, ao utilizar uma boa arquitetura, podemos tentar alcançar este objetivo tanto quanto possível.
Imagina que estás no ponto de partida de uma empresa para a qual acabaste de ser contratado. Todas as pessoas são simpáticas consigo e tudo parece estar bem até ao momento em que lhe é apresentada uma base de código anterior ao JavaScript ser uma linguagem e ao Netscape carregar uma página durante o que parece ser uma eternidade.
A herança do código parece ser um grande problema quando se introduzem novos programadores num projeto. Ler o código é uma coisa, mas entender como a aplicação foi desenvolvida não é exatamente a mesma coisa. Muitas vezes os commits provam ser úteis e dão contexto para o porquê desses console.logs não terem sido capturados pelo linter ou porque aquele // TODO desagradável está lá para os filhos do desenvolvedor que inicialmente fez a anotação.
Vamos começar com a razão pela qual os commits convencionais são melhores do que as regras de commit não padronizadas.
Se contratarmos novos programadores para um projeto em que a maior parte dos commits consistem em mensagens do tipo "isto deve funcionar" ou "Sleepy fix for footer ASAP", o que é que lhe vem à cabeça?
Eu diria que são bandeiras vermelhas porque:
Uma vez que a sua equipa pode ter regras personalizadas aplicadas ao momento em que se efectuam as alterações, há menos espaço para erros, uma vez que a sua confirmação tem de ser sólida. Já não é apenas uma forma de fazer check-out. É uma assinatura que diz às outras pessoas que sabia o conteúdo do commit. Não é necessário mencionar que, se o trabalho que fez não estiver corretamente assinado, o mais provável é que resulte num erro e lhe seja apresentada uma mensagem
É possível que a sua equipa queira definir uma regra que impeça a utilização de determinadas palavras-chave, pelo que o ASAP ou quaisquer palavrões podem ser incluídos na lista negra.
O que é realmente útil no início do projeto é apresentar a todos a forma como o seu equipa de desenvolvimento gostaria de ver novos programadores a submeterem as suas alterações. Em seguida, crie uma ferramenta que os ajude a manterem-se a par do que todos concordaram.
Uma das ferramentas com que tive oportunidade de trabalhar foi commitlint e fez com que os commits convencionais se tornassem a minha prática de referência quando entro em novos projectos que não têm regras e a equipa está aberta à ideia de as introduzir.
Ao lidar com as configurações e espalhá-las pela sua equipe, você pode simplesmente criar um pacote npm e simplesmente fazer o mpn i -D em cada projeto. Isso certamente ajudará todos no projeto a estarem sempre na mesma página e, se necessário, andar de projeto em projeto entendendo quais foram as últimas mudanças (e por que elas foram feitas).
Então agora, depois de configurar tudo e entender porque é que pode ser uma boa ideia começar a usar o CC, a melhor parte seria programar à volta das regras que acabou de aplicar! Estamos a usar uma forma padronizada de como fazemos o commit, prestamos mais atenção ao que o commit realmente era, então porque não configurar hooks que permitam testes rápidos no staging quando uma flag está presente? Não queremos sobrecarregar os serviços e cortar os custos quando necessário e existem algumas razões para testar num servidor de produção em vez de num servidor local.
Vamos supor que está a trabalhar no PWA e que o SSL é necessário para testar todo o seu potencial e que tem um SSL na sua plataforma de testes. Tudo o que você precisa agora é apenas de um bom commit. Algo na linha de feat(PWA): manifest icons workbox setup upload iria despoletar toda a maquinaria de testes e movimentação de rodas dentadas. Nós não precisamos disso quando estamos apenas fazendo upload de alguns dados estáticos como manifest.json, então nós adicionamos uma flag [TEST_SKIP] como um postfix ao nosso commit. Isso permite que nosso CI apenas faça o upload de novos assets para o ambiente de testes e pule os testes. Você pode ler mais sobre isso aqui
Ao fim de algum tempo, poderá ver outros benefícios, como a facilidade de gerar CHANGELOG e um melhor controlo de versões com o controlo de versões semântico. Se isso não for suficiente para o convencer a mudar a sua forma de escrever mensagens de compromisso, talvez mergulhar os dedos dos pés em água fresca e fria e tentar utilizá-los no seu repositório privado durante algum tempo o faça mudar de ideias.
Feliz compromisso convencional!
Uma versão do Ruby 3.0.0 há muito esperada pela comunidade viu a luz do dia no Natal para que todos os desenvolvedores de Ruby pudessem encontrá-la debaixo da árvore de Natal quando acordassem de manhã. Na The Codest cultivamos a cultura de partilha de conhecimento organizando reuniões semanais de desenvolvimento onde os nossos engenheiros discutem tendências tecnológicas e as suas novas descobertas que merecem atenção. Abaixo pode encontrar um link para os slides do dia de demonstração onde o nosso engenheiro sénior de Ruby discutiu algumas mudanças importantes no Ruby 3.0.0 do seu ponto de vista subjetivo:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Para além disso, o nosso mentor Ruby contribuiu para a nova versão com o seu pedido pull que foi fundido com sucesso. Para mais informações sobre o tema dos métodos de controlo da privacidade, consulte o pequeno artigo do nosso Chefe de Desenvolvimento.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Muito obrigado por ler e, se chegou até aqui, agradeço o seu tempo e todos os comentários são mais do que bem-vindos no LinkedIn ou no meu e-mail.
Voltamos com o próximo episódio no final de fevereiro com a análise de um podcast que entrevista o CTO da Shopify, o homem por detrás de uma equipa de engenharia que trabalha na magnífica aplicação Ruby monolith!
Vemo-nos por aí.
Ler mais:
TheCodestReview #4 - sumo semanal de engenharia de software
Portuguese 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Spanish 
Dutch 
Estonian 
Greek 
Czech