Como não ser um desenvolvedor medíocre!

Disclaimer: Eu não sou o melhor desenvolvedor, mas eu aprecio e raciocino as diferenças que fazem alguns desenvolvedores se destacarem do resto.

Foto de Joshua Earle no Unsplash

Escreva mais código

Se você quer ficar melhor em alguma coisa, então você tem que gastar tempo fazendo essa coisa, não há outra maneira triste. Não importa quantos artigos você leia, quantas vezes você leu os documentos, você não vai melhorar a menos que você coloque suas mãos e mente em ação. Esse padrão de design, que parecia difícil de implementar no início, pareceria uma caminhada de bolo depois de você ter praticado seu uso em múltiplos contextos.

Incorporar testes

Quando comecei a escrever testes para o meu próprio código, fiquei espantado ao ver a mentalidade que faltava para escrever bons testes. Escrever testes permitirá que você olhe para o seu código da maneira que você não imaginou no início, porque quando se trata de testes, você tem que pensar sobre como isso pode quebrar e você percebe que estava fazendo muitas coisas nessa função que você escreveu e Pode ser melhor dividir em várias funções porque é difícil criar um teste para uma função que faz várias coisas.

Vamos ver um exemplo abaixo

 postData da função (dados) { 
booleano válido = verdadeiro;
// verifique se os dados estão definidos
if (dados === indefinidos) {
válido = falso;
}
 // verifique se o email está bem formado 
if (! regex (data ['email']) {
válido = falso;
}
 // verifica se a senha tem pelo menos 8 caracteres. 
if (data ['senha']. comprimento <8) {
válido = falso;
}
 if (válido) { 
http
.post (`example.com / user / create`, data)
.then ((resposta) => {
// acrescentar à lista
this.users.append (response.userid);
})
.catch ((erro) => {
// mostra erros.
});
} outro {
showValidationError ();
}
}

Portanto, o método postData está fazendo várias coisas, como validar os dados, anexar à lista de usuários quando a promessa é resolvida e manipular erros. Escrever um teste de unidade para postData será difícil e confuso. Você pode dividi-lo em vários métodos e testar cada método separadamente para, por exemplo,

 postData da função (dados) { 
retorno http
.post (`example.com / user / create`, data);
}
 função validate (data) { 
// verifique se os dados estão definidos
if (dados === indefinidos) {
retorna falso;
}
 // verifique se o email está bem formado 
if (! regex (data ['email']) {
retorna falso;
}
 // verifica se a senha tem pelo menos 8 caracteres. 
if (data ['senha']. comprimento> = 8) {
retorna falso;
}
 retorno verdadeiro; 
}
 function appendUsers (userId) { 
this.users.append (response.userid);
}
 função main () { 
if (validate (data)) {
postData (data)
.then (data => appendToList (data.userId))
.catch (erro => handleError (erro))
} outro {
showValidationError ();
}
}

Você já pode ver porque escrever testes leva a um código de melhor qualidade, você teve que dividir seu método longo em várias unidades menores e cada unidade pode ser testada atomicamente.

Seja honesto

Seja honesto sobre o que você conhece completamente e o que você não sabe. Fingir que você sabe o que é in e out de uma API nunca irá ajudá-lo a melhorar e infactear você pode perder a cara em uma discussão se acontecer de você dizer algo estúpido por causa de sua falta de conhecimento sobre uma API ou um tópico.

Contribua para o código aberto

Contribuir para o código aberto pode expô-lo a cenários que podem nunca ocorrer no trabalho e, assim, limitar seus horizontes. Você pode aprender o que é necessário para executar um projeto em um cenário distribuído, introduzindo alterações não quebráveis ??e outras novas ferramentas de código aberto, etc. Os benefícios são infinitos e todos sabemos como o código aberto mudou a vida de todos direta e indiretamente.

por rawpixel em Unsplash

Esteja aberto para ajudar

Ajudar os outros por algo que você conhece faz de você uma pessoa "goto" para esse conceito / recurso / API e, assim, retira seu valor e importância na equipe. Esteja aberto para ajudar em coisas que você pode não ser o melhor, você pode acabar aprendendo algo valioso com a experiência.

Não seja esse cara

Escolha um projeto pessoal

Os projetos pessoais são uma ótima maneira de aprender novos frameworks e tecnologias que você talvez não experimente no trabalho. Com o seu projeto pessoal você é o gerente de produto, você é o desenvolvedor e o arquiteto, então você pode imaginar a quantidade de tomada de decisão que você terá que fazer. Você pode usar a experiência do seu projeto e sugerir novas estruturas e ferramentas no trabalho ou na sua comunidade e brilhar como um ??

pinguim trabalhador

Abaixe seu ego

Não deixe seu ego e seu cargo ficarem entre o caminho de seu aprendizado / aperfeiçoamento. Um arquiteto em uma organização xyz pode ser um desenvolvedor de software em alguma outra organização. Esteja sempre aberto a maneiras novas e diferentes de fazer aquilo que você acha que é ótimo. Você pode perder um algoritmo mais eficiente ou um design melhor para um recurso.

não seja o kanye na sua equipe

Entenda o "porquê"

Antes de aceitar e sustentar sua crença em um novo framework ou um padrão ou uma API, tente entender que “por que” existe em primeiro lugar. Tente chegar à intuição da própria existência de um conceito.

 var app = new Vue ({ 
el: '#app',
data: {
mensagem: 'Olá Vue!'
}
})

Acima está o primeiro exemplo de código que você encontra no site de documentos vue.js. Mesmo quando estou olhando para este exemplo muito básico, estou tentando raciocinar sobre as coisas abaixo na minha cabeça:

  • Por que uma new palavra-chave para criar o componente? Por que eles não têm um padrão de fábrica para criar objetos?
  • Parece que a propriedade el usa o id do elemento e por que ele usa # ? Isso significa que posso adicionar outros seletores de elementos, como atributo e classe?
  • data parecem um nome de propriedade muito genérico do objeto vue , o que ele está tentando representar exatamente?

Não dizer que você deve ser crítico nessa medida, mas desenvolver esse hábito ajuda a entender melhor a filosofia das coisas e, assim, melhorar sua compreensão.

Não seja preguiçoso

A preguiça pode aparecer no seu caminho para mostrar suas habilidades ou as coisas pelas quais você se importa, por exemplo, se você acredita que um refatorará o desempenho, vá em frente e faça, adicione comentários para salvar o tempo de outros desenvolvedores, documente a nova API que você criou . O tempo adicionado por você em seu código é igual ao tempo economizado para o outro desenvolvedor que está tentando entender o que você escreveu.

Resolva os desafios de codificação

Resolver desafios de codificação obriga você a pensar em coisas que tomamos como garantidas em nossa rotina. Eu estou falando sobre a complexidade de espaço e tempo do nosso código. Algumas pessoas argumentam que não é prático resolver desafios, já que a maioria das coisas é abstraída e você usará a API.

Mas eu discordo! Isso não só ajuda você a analisar criticamente o código, mas também permite que você tenha a confiança de criar o melhor código possível em termos de desempenho e outro benefício é que você estará sempre preparado para essa entrevista.

Alguns dos sites para resolver os desafios são hackerrank , leetcode , topcoder e spoj .

Encoraje as coisas boas

Se você gostou do commit do seu colega, então não hesite em deixar uma mensagem e apreciar a resposta que o ajudou no stackoverflow ou aplaudir o artigo no meio que lhe deu sabedoria gratuita ou estrelar aquele projeto interessante que você fez no github. Incentivar os outros ajuda a tirar o melhor proveito deles e, eventualmente, você também.

Não se esconda atrás da camada

Você encontrou um problema com a API que está consumindo na sua visualização, mas não pode corrigi-la porque é um desenvolvedor de front-end. É uma atitude ruim ter em minha opinião. Os princípios básicos de programação, como manter o código DRY, usar abstrações se você vir vários casos de uso para suas classes, capturar exceções para todos os caminhos de controle de fluxo, etc., se aplicam a quase todas as camadas da pilha. Mantendo os princípios básicos em mente, isso pode ajudá-lo a resolver problemas que você acha que não pode tocar porque não trabalha nessa parte da base de código.