Sobre mim

Luiz Henrique Zanão Kota

Desenvolvedor Sênior na Catho

 

- Gradução em Design

- Pós-graduação em Engenharia web

 

- Desenvolvedor front-end a 10 anos

(4 anos na Catho)

Qual o problema em desenvolver em times grandes?

Não é bem assim...

Quanto maior o time, maior a dificuldade em manter todos sincronizados...

... e começam a acontecer alguns problemas...

Alguém alterou o arquivo X? Parou de funcionar no meu projeto...

O arquivo Y sumiu, quem apagou?

...comitei primeiro...

Comunicação

Mais pessoas trabalhando = mais pessoas para comunicar, então:

 

- Aumenta a possibilidade de código duplicado

 

- Dificulta a difusão das regras de negócio de cada produto

 

- Aumenta a chance de conflito de publicações da mesma aplicação

 

- Cada um tem suas preferências quanto a estilo de escrita de código

Adote um canal de comunicação que todos tenham acesso, e comunique tudo que possa afetar outras pessoas

Documente toda regra de negócio importante, além de como utilizar os projetos técnicos

Versionamento

de código

Mais pessoas trabalhando = mais pessoas alterando, criando e deletando arquivos, então:

 

- Aumenta possibilidade de mais de uma pessoa precisar alterar o mesmo arquivo

 

- Sem versionamento é bem provável que algum arquivo seja perdido e não tenha backup

Adote uma ferramenta de versionamento de código, preferencialmente que trabalhe com git

Somente a ferramenta não garante nada:

 

- Faça commits pequenos

 

- Descreva de forma adequada o que esta sendo comitado

Gerenciamento de dependências

Mais pessoas trabalhando = mais pessoas desenvolvendo produtos, então:

 

- Cada aplicação/funcionalidade/lib normalmente depende de outras libs/scripts

 

- Você que desenvolveu sabe, do que essa aplicação/lib depende, mas o novo colaborador que entrou hoje? E o resto do time durante suas férias? E quando você sair da empresa? E você mesmo daqui um ano?

 

- Liste todas as dependências do projeto

Adote um gerenciador de dependências

Padrão de escrita

Mais pessoas trabalhando = mais pessoas escrevendo código, então:

 

- Cada desenvolvedor possui sua preferência por editor/estilo de escrita, então a probabilidade nascer um frankstein é enorme

 

- Todo código seguindo um padrão facilita o entendimento de todos, além de ajudar na busca para verificar se um método ou funcionalidade já existe

“Cada linha de código deve parecer ser escrita por uma única pessoa, não importa o número de contribuidores”

Mac Giovanni

(http://pt.slideshare.net/maclevison/style-guides-44392715)

Adote um linter para validar seu código

git hook

Testes de unidade

A maioria utiliza testes de unidade no back-end, e por que não no Front-end?

Front-end não quebra?

Mais pessoas trabalhando = mais pessoas alterando o código que "funcionava", então:

 

- "Funcionava" porque para ele quebrar é muito fácil, basta ser alterado por alguém que não conhecia aquela regra a fundo

 

- Ou nós mesmos esquecermos de um detalhe durante a correção de bug, e corrigir um bug causando outro

 

- O teste de unidade garante que essas regras não sejam esquecidas, além de servir de guia para alguém que não conheça aquela funcionalidade

Adote uma stack de testes

Istanbul

coverage

Build automatizado

Ah mas Front-end trabalha também no processo de build?

Claro, o processo de build trabalha com todas as ferramentas, então o dev front-end também faz parte

Tudo que é manual está suscetível ao esquecimento, e será esquecido!

Automatize tudo o que for possível:

 

- Testes de unidade

 

- Minificação de código

 

- Compilação de código

 

- Instalação de dependências

Ferramentas para build automatizado

Você também pode usar:

Scripts

Monitoramento

Ah mas o que podemos monitorar no front-end?

É muito ruim quando precisamos uma ferramenta e ela não funciona como deveria, pois é...

Monitorar erros na aplicação é muito importante para corrigirmos bugs o mais rápido possível

Guarde log dos erros

TraceTit

(https://github.com/occ/TraceKit)

Sobre times

Todos trabalhando juntos, em sintonia, superam qualquer problema