Então você vasculha seu git confirmar o histórico usando git log -p filename.js mostrando alterações para um arquivo específico, tentando ver quem inventaria algo assim, e então seu coração cai - você é quem escreveu!
Este é um cenário comum para qualquer desenvolvedor, experiente ou novo. Se você não tiver atingido esse cenário, prometo que, se continuar com a codificação por tempo suficiente, você o fará.
Tornar-nos mais conscientes sobre nossos hábitos de codificação
Esse ponto de reflexão de seis meses é inevitável. É muito tempo que você provavelmente está usando para trabalhar em outras partes do projeto ou em outro projeto completamente. Provavelmente, você subiu de nível, o que mudou a maneira como você escreve o código.
Por outro lado, às vezes é preciso sair do código para ver a foto maior e ter uma melhor visão de como todas as peças se encaixam. Naturalmente, podemos nos aprofundar demais em uma solução e nos tornar um pouco restritos ao trabalharmos para resolver esses desafios.
De qualquer forma, embora parte da jornada do código esteja simplesmente ganhando mais experiência e aprendendo mais sobre o seu ofício, há outros pequenos hábitos com os quais você pode se acostumar desde o início que o ajudarão no caminho.
Então, vamos pular.
Melhorando a legibilidade do seu código
Qual é o desafio?
Parte da diversão de nosso ofício é que existem várias maneiras de fazer a mesma coisa. Pense um if declaração é muitas linhas? Bem, podemos escrever ternário estilo!
// Example ternary statementconst isFreezing = temperature <= 32 ? true : false;Mas, às vezes, isso prejudica a legibilidade do seu código. Embora pareça agradável e super limpo em uma linha, imagine que o ternário se torne mais complexo, mais tempo alguém terá que gastar para entender o que isso significa.
const minutes = 30;const cookie = { color: 'black'};const cookieStatus = minutes > 20 ? cookie.color === 'black' ? 'burned' : 'done' : 'not done';O que podemos fazer melhor?
Agora eu imagino que a maioria de nós pode descobrir o que cookieStatus está neste exemplo (spoilers: burned), mas pense no tempo que você gastou para descobrir isso. Seja 1s ou 2s extra, ele força você a gastar energia cognitiva adicional para ler o código.
Por outro lado:
const minutes = 30;const cookie = { color: 'black'};let cookieStatus;if ( minutes <= 20 ) { cookieStatus = 'not done';} else if ( cookie.color === 'black' ) { cookieStatus = 'burned';} else { cookieStatus = 'done';}Não, pode não ser tão clara ou inteligente quanto a declaração ternária de 1 linha, mas na próxima vez que você a visitar, menos precisará pensar sobre qual é a resposta. Também tornará muito mais fácil os bugs surgirem e passarem por seus revisores de código quando todas as suas alterações de código estiverem em um diff de git de 1 linha.
E sim, este é um exemplo simples, mas imagine isso em um cenário do mundo real, com lógica comercial importante, onde você pode enfrentar essas situações com frequência. Digamos que você precise adicionar outra condição - que o ternário vai ficar cada vez mais complexo! Você está apenas dificultando a depuração ou a extensão, onde o if As instruções podem continuar de uma maneira facilmente legível.
Pelo que vale, ternários e outros atalhos podem ser simples e eficazes no código, mas não abuse dessa eficácia e acabam dificultando as coisas.
Mantendo as coisas consistentes
Qual é o desafio?
Todos nós temos a nossa maneira favorita de codificar. Embora eu afirme que não incluir um ponto-e-vírgula no final do seu Javascript está completamente errado, você pode preferir escrever seu código o caminho errado sem eles.
// Jim's code stylefunction MyComponent() { function handleOnClick() { alert('Click!') } return ( )}// Creed's code styleconst MyComponent = () => ;Mas nem sempre é sobre o que você preferir. Ao trabalhar com uma equipe, as chances são de que a opinião de todos sobre a aparência do código é um pouco diferente. Você pode concordar com o ponto-e-vírgula, mas discorda do espaço em branco.
E ninguém está errado (exceto os não-colonos)! Existem argumentos válidos para a maioria dos estilos de código, seja a favor ou contra, mas a solução não é que todos escrevam seu código à sua maneira.
O que podemos fazer melhor?
Manter o código consistente é importante para manter a integridade do código. Um objetivo típico é "fazer com que a base de código pareça que uma pessoa escreveu".
O ponto não é que uma pessoa consiga o que quer, mas a equipe chegou a uma conclusão sobre um conjunto de regras que eles usariam e que todos seguiriam. Ter essa consistência fornece menos sobrecarga cognitiva à medida que as pessoas trabalham no código. Dá a todos a capacidade de saber o que esperar ao ler o código.
E conseguir isso não precisa ser difícil. Existem ferramentas que podem simplesmente verifique essas inconsistências gostar Eslint para Javascript. E melhor ainda, outras ferramentas de nível como Mais bonito naquela vai consertar isso pra você!
Qual é o desafio?
Acompanhar os comentários do seu código é uma maneira importante de contextualizar a lógica complexa. Por mais que todos desejemos que nosso código seja auto-documentado, esse raramente é o caso.
Muitas vezes nos encontramos lidando com um bloco de código que simplesmente não faz sentido. E mesmo que faça sentido por si só, talvez não possamos descobrir como isso se encaixa no restante do aplicativo.
O que podemos fazer melhor?
Ao fornecer um bom conjunto de comentários, você está configurando a próxima pessoa que toca esse código para entender melhor o que o código está fazendo antes que eles façam uma alteração.
// DONT CHANGE - WILL STOP MAKING MONEYconst shouldMakeMoney = true;function makeMoney() { if ( shouldMakeMoney ) { return noMoney; } return moreMoney;}Embora este seja um exemplo bobo, ele traz um caso do mundo real. As empresas dependem cada vez mais de manter um site confiável para ganhar dinheiro. Seja um negócio de comércio eletrônico ou um gigante de anúncios, esses sites contam com uma lógica comercial que determina coisas como custo, impostos, descontos e outras coisas relacionadas à matemática nas quais tendemos a não querer pensar, mas que poderia fazer ou interromper um negócio em a Internet.
Mas não é tudo sobre a empresa em que você trabalha. Tocar código antigo pode ser assustador. É ainda mais assustador quando ninguém da sua equipe estava por perto quando foi escrito, para que ninguém saiba o que faz!
Embora você possa não ser a próxima pessoa que toca esse código, tente ajudar seu futuro amigo que está enfrentando o próximo ticket que envolve esse código. Porque também há uma boa chance de você ser essa pessoa e desejar lembrar-se de como ela funcionou.
Documentando suas soluções
Qual é o desafio?
A documentação é semelhante a comentar seu código, mas de uma perspectiva diferente. Documentação e comentários são sobre encontrar maneiras de descrever uma solução de uma maneira legível por humanos que, em última análise, dará mais contexto. Mas a documentação é mais sobre a solução geral do que os detalhes da implementação.
Ter um aplicativo de alto desempenho é o objetivo de todos. Mas como chegamos lá? Há uma chance realista de que alguém tenha que trabalhar no mesmo projeto em que você está, integrando um novo membro da equipe. Como eles conseguirão manter esse alto desempenho se não souberem como ele funciona?
O que podemos fazer melhor?
Seja apresentando o novo membro da equipe ao projeto ou tentando compartilhar conhecimento com outra equipe, a documentação é uma parte importante da manutenção de um projeto. Isso ajuda a manter todos na mesma página, para que todos saibamos com confiança para o que estamos trabalhando.
Por exemplo, se ainda estivermos trabalhando com nosso projeto de comércio eletrônico com nossa lógica de negócios, haverá regras que o código precisará implementar. Embora os comentários possam fornecer detalhes em linha sobre como as regras foram implementadas, a documentação definiria essas regras.
/** * DOCUMENTATION * Order Total >= 25: Discount %10 * Order Total >= 50: Discount %15 * Order Total >= 100: Discount %20 * Order Total >= 75: Free Shipping */const orderSubTotal = 84.00;let orderTotal = orderSubTotal;// If the order total is under 75, apply shipping discountif ( orderTotal < 75 ) {
orderTotal = addShipping(orderTotal);
}
// If the order total reaches a threshold, apply given discount
if ( orderTotal >= 100) { orderTotal = applyDiscount(orderTotal, .2);} else if ( orderTotal >= 50 ) { orderTotal = applyDiscount(orderTotal, .15);} else if ( orderTotal >= 25 ) { orderTotal = applyDiscount(orderTotal, .1);}Este é um exemplo mínimo, mas podemos ver a diferença entre as regras no topo e como as aplicamos. A documentação deve explicar claramente quais são as regras, mas não deve se preocupar com como essas regras foram implementadas.
Por outro lado, os comentários podem não se importar com o que são as regras, mas precisam implementá-las de maneira eficiente e lógica. Deveríamos poder atualizar o código com as regras de negócios, como alterar o nível de desconto de nível superior de US $ 100 para US $ 80, sem precisar refazer o código.
Mas a documentação é muito mais do que regras de negócios - é uma maneira de qualquer pessoa entender seu trabalho de um nível superior. Isso pode incluir qualquer coisa, desde diagramas arquitetônicos até a teoria por trás do algoritmo principal.
Embora talvez o código não seja o melhor lugar para obter detalhes como esse, são informações realmente importantes que podem ajudar a incutir confiança no seu projeto e dar a outras pessoas a oportunidade de entender mais sobre o trabalho.
Criando solicitações pull efetivas
Qual é o desafio?
Solicitações pull (ou solicitações de mesclagem) são uma parte essencial do ciclo de vida de qualquer equipe de desenvolvimento. Ele fornece uma maneira de empacotar e apresentar seu código de maneira consumível para que seus colegas revisem e entendam seu trabalho.
Há muito o que fazer em uma solicitação pull de um único commit para a totalidade da próxima versão do seu site. É muito contexto que se espera que alguém entenda lendo apenas os commits.
O que podemos fazer melhor?
Os pedidos pull não precisam ser uma arte. Deve haver um objetivo principal da preparação que você coloca nele - fornecer contexto para suas alterações. No mínimo, ele deve responder às perguntas de "o quê" e "por que".
Podemos até usar ferramentas como modelos de solicitação pull para nos levar na direção certa. Definir um contorno do que você deseja explicar e as chances são de que as pessoas sigam esse esboço. Isso ajuda a evitar o fechamento de 1 linha " [ticket]"descrição ou, pior ainda, uma descrição vazia.
Com meus projetos, espero ter algumas perguntas respondidas antes de mergulhar em uma revisão de código:
- Qual é a mudança?
- O que isso afeta?
- Como reproduzo ou testo a alteração?
Apenas um pouco de detalhes sobre o conjunto de alterações pode fornecer o contexto muito necessário para aqueles que revisam seu código. É fácil olhar para o código, mas é mais difícil entendê-lo sem saber como ele se encaixa na imagem maior.
Endurecendo seu código com testes
Qual é o desafio?
Os testes são uma maneira de garantir que seu código seja executado da mesma maneira todas as vezes. Ser capaz de provar que a mesma entrada sempre terá a mesma saída ajudará a fornecer a você e à sua equipe um nível mais alto de confiança de que seu aplicativo não será interrompido com a próxima pequena alteração.
Sem eles, ficamos com um erro humano, onde não importa o quão bom é o seu engenheiro de controle de qualidade (mensagem aos meus testadores por aí), algo sempre passará despercebido. E isso não quer dizer que seus testes sempre detectem todos os problemas, mas podemos usar as ferramentas disponíveis para ajudar a evitá-lo.
O que podemos fazer melhor?
Onde os comentários são uma maneira de fornecer o contexto de como algo funciona, o teste é uma maneira de garantir que eles funcionem. Fornecer casos de teste repetíveis ajuda a impor isso.
function applyDiscount(value, discount) { const discountAmount = value * discount; return value - discountAmount;}expect(applyDiscount(10, .1)).toEqual(.9);expect(applyDiscount(532151235, .1054)).toEqual(476062494.831);Se eu enganar a matemática em nosso applyDiscount Na função acima, há uma alta probabilidade de o teste falhar (nunca diga nunca).
Mas o teste não precisa ser difícil. Existem muitas ferramentas por aí que ajudam de diferentes perspectivas. Onde você pode usar Jest para executar seus testes de unidade ou adicionar Enzima na parte superior para testar seus componentes do React, você também pode trazer Cipreste como uma solução de teste de integração que funcionará como um robô clicando no seu aplicativo para garantir que todos os componentes realmente funcionem juntos.
Existem também diferentes metodologias de teste. Enquanto você provavelmente vê a maioria das equipes escrever seus testes depois de ter uma solução funcional, algumas pessoas juram que desenvolvimento orientado a teste e pode escrever seus testes primeiro, onde o código precisa passar nos testes, e não o contrário. Essa é uma ótima maneira de definir os requisitos do código antes de mergulhar.
Seja qual for o método, capture os pontos com maior probabilidade de quebrar ou as funções que agregam mais valor aos negócios. Você ajudará a evitar uma potencial perda de negócios ou, ainda mais simples, uma dor de cabeça.
O que podemos aprender com isso?
Isso pode ser muito difícil de digerir, mas são pontos importantes a serem considerados à medida que você cresce como desenvolvedor. O início desses hábitos no início de sua carreira o ajudará naturalmente a desenvolver essas habilidades e a trabalhar dessa maneira por padrão.
E se você está atrasado em sua carreira, nunca é tarde para começar. Todos devemos nos esforçar para ser o melhor desenvolvedor que podemos ser e fazer o nosso melhor para ajudar a facilitar a vida de nosso companheiro de equipe, pois estamos nisso juntos.
Procurando mais para aprender?
Qual é o seu conselho para crescer como desenvolvedor?
Compartilhe comigo no Twitter!
