Conteúdo

1. Introdução
2. Principais práticas recomendadas
3. Rastreando Tendências da Indústria
4. Melhores práticas e sua carreira
5. Conclusão

1. Introdução

O software é uma indústria em ritmo acelerado. O tempo de vida de algumas habilidades realmente parece estar diminuindo com o tempo; linguagens e estruturas têm uma vida útil limitada. Um dos hábitos mais importantes a desenvolver, portanto, é manter uma compreensão das 'melhores práticas' atuais. As melhores práticas são padrões de técnicas, tecnologias assistivas, hábitos e plataformas que podem ajudar uma equipe de desenvolvimento de software a produzir software de maior qualidade com mais eficiência.

As melhores práticas mudam dependendo da hora e do ambiente em que o código é produzido. A primeira empresa em que estagiei produziu software de roteamento de fax para empresas gigantes. O processo de implantação pode ter envolvido o envio de um engenheiro ao local com um disco rígido para transferir uma nova versão. A empresa para a qual trabalho atualmente pode criar para servidores hospedados pela AWS várias vezes ao dia, dependendo de quantas alterações de código foram confirmadas em um determinado dia. Este é um exemplo de como o 'tempo de lançamento' foi comprimido nos últimos 25 anos para se tornar virtualmente instantâneo em alguns ambientes. Como tal, as melhores práticas para gerenciar mudanças muito rápidas também precisam evoluir.

Ao usar as melhores práticas, suporte de código e dívida técnica são menos onerosos para os programadores individuais e para as empresas como um todo. O código construído com as melhores práticas tende a ter uma vida útil mais longa, além de custar menos para manter. Além disso, é mais provável que a herança desse código seja uma solução viável para problemas para os quais o código não foi originalmente projetado. E, talvez o mais importante para uma organização, a rotatividade / compartilhamento de responsabilidades do desenvolvedor é muito mais fácil. Enquanto alguns desenvolvedores codificam para a segurança do trabalho, a codificação para sua própria obsolescência é melhor para sua reputação e confiabilidade do código.

As melhores práticas essenciais são a base da reputação de um bom programador. A primeira e mais importante prática recomendada é, na verdade, bastante ilógica: escreva menos código. Isso é reforçado ao tornar os ambientes - e as interações entre eles - tão simples e confiáveis ​​quanto possível. Enquanto faz isso, evite cometer erros básicos de segurança. Então, crie o hábito de testes de unidade, porque todo mundo gosta de dormir ... e se você não escreve testes de unidade, não consegue dormir com tanta segurança! Finalmente, se possível, configure um ambiente integrado de construção e teste. Tornou-se uma parte fundamental de qualquer abordagem de melhores práticas.

Lembre-se, porém, de que todas essas práticas vão mudar com o tempo e evoluir. Portanto, estar ciente das tendências do setor e permanecer à frente da curva é fundamentalmente importante para saber quais hábitos e ferramentas você deve adotar / promover ou deixar atrofiar.

Portanto, como um desenvolvedor experiente, ficar ciente das práticas recomendadas atuais - e combinar 'o que as crianças legais estão fazendo' com o que você já sabe - é uma habilidade essencial. Minhas fontes primárias pessoais para essas informações são anúncios de emprego, pesquisas de estouro de pilha e vários fóruns. Mas saber o que está acontecendo e aplicá-lo são tarefas distintas.

Geralmente, aprendizagem aplicar as melhores práticas é uma tarefa mais onerosa do que conhecimento o que eles são. O tempo envolvido na reaprendizagem de um hábito (por exemplo, lembrar de usar comentários suficientes) ou na reconstrução de um ambiente que atualmente seja confortável, muitas vezes parecerá caro ou frustrante de manter antecipadamente. E, infelizmente, é. Mas há muitas maneiras de aprender a aplicar as novas práticas recomendadas, e isso definitivamente vale a pena.

2. Principais práticas recomendadas

Independentemente da rotatividade do que é melhor fazer, algumas coisas sempre serão as principais práticas recomendadas com as quais a maioria dos desenvolvedores concordará:

• Escreva menos código
• Torne os ambientes o mais simples possível
• Evite problemas de segurança padrão
• Escreva testes de unidade básicos

Essas quatro práticas são fundamentais para ter código mais sustentável e reutilizável.

Escreva menos código

As bases de código tendem a inchar. Quando os problemas são encontrados, eles tendem a ser corrigidos o mais rápido possível, com impacto mínimo na execução do código de trabalho. Eu trabalhei em lugares onde pedaços críticos de código eram cercados por pequenas ramificações lidando com problemas de partes interessadas. Isso, é claro, é uma troca.

O código antigo geralmente tem problemas estruturais que limitam sua expansão ou reimplementação, mas ao mesmo tempo contém uma grande variedade de recursos extremamente específicos. Portanto, quando uma base de código está inchada, ela é inchada com correções para problemas do cliente ou relacionados à arquitetura. Como tal, destruir toda a sua base de código é sempre mais caro do que parece, e você quer trabalhar muito para manter o código / ambientes minimalistas.

A prática recomendada mais importante como desenvolvedor é escrever menos código, compartimentado de forma mais inteligente. Como costumava ser ensinado a mim quando era criança: Reduzir, Reutilizar, Reciclar. Reduza a quantidade de código que você escreve, reutilize o seu próprio e o de outros programadores regularmente e recicle-o em mais espaço no disco rígido quando possível.

Para ajudá-lo a fazer isso, leia o código de outras pessoas de vez em quando. Seu código irá melhorar, se você lê-lo criticamente, e o código dele irá melhorar se você mencionar os problemas que vê nele. Lendo com o intenção de fazer pequenas modificações (e até mesmo fazê-las) tornará esta tarefa muito mais significativa, então eu faço isso quando o tempo permite. Observe que, se você estiver fazendo uma limpeza não programada em um ambiente profissional, enviar patches para o código de produção costuma ser desaprovado. Eu sugiro conversar sobre o que você está fazendo com o mantenedor oficial com antecedência.

Aprender 'Design Patterns' pode ou não ajudá-lo a organizar seu código de forma mais eficaz, mas descobrir como os acadêmicos acham que as soluções para problemas comuns devem ser organizadas é uma boa maneira de fornecer esqueletos para uma organização futura. Finalmente, na estrutura do código, algo que sinto que devo sempre mencionar é: se você pensa em algo, e tem certeza de que é brilhante, você provavelmente está errado.

"Otimização prematura é a raiz de todo o mal" - Donald Knuth

Como alguém que mantinha uma base de código escrita por um desenvolvedor que acreditava em seus próprios poderes mágicos, posso atestar pessoalmente o fato de que eles falhavam com ele regularmente. Fundamentalmente, a maior parte do código é escrita uma ou duas camadas de abstração acima dos compiladores.

Os escritores de compiladores são profissionais de desempenho e lógica, com foco em otimizações de código em nível de assembly. Quando, nas linguagens de nível superior 95% + dos programadores profissionais usam, você está preocupado com a otimização, (geralmente) está cometendo um erro. Se você está indo além da programação com bons fundamentos, o que você pode querer é uma configuração de ambiente mais apropriada.

Os ambientes devem ser simples e sólidos

Quanto mais componentes exclusivos e complicados um sistema possui, mais difícil é entender e refatorar todo o sistema. Portanto, as melhores práticas modernas tendem a concentrar o código exclusivo em um sistema em partes fracamente acopladas, e essas partes fracamente acopladas são o mais simples possível de se trabalhar. Considere estes três ambientes, por exemplo:

À esquerda está uma pilha LAMP padrão. Por dez anos, as principais pilhas de programação para desenvolvimento web full-stack foram Linux ➡ Apache ➡ MySQL ➡ PHP. Essa pilha inclui tudo que você precisa para criar um aplicativo da web do lado do servidor que mostra ao usuário uma página HTML estática, e ainda há pessoas entregando dados com essa pilha hoje.

A pilha de software intermediária é uma abordagem mais moderna. Tão moderno que evita um ORM e tem desenvolvedores escrevendo consultas MongoDB / SQL brutas. Essa decisão foi tomada para aumentar a velocidade de desenvolvimento, às custas de alguns dos recursos que os ORMs incluem. O front-end dessa pilha de software inclui React, que é essencialmente um ambiente de desenvolvimento de compilação completo que usa npm para construir um código utilizável. Isso contrasta com a inclusão (comparativamente) do ambiente antigo de Javascript / Silverlight em páginas individuais.

A pilha de software à direita é ainda mais compartimentada do que as outras duas. O Rest Framework do Django é provavelmente usado para interagir com um cliente Angular usando o Padrão de design MVC. O Django tem um ORM embutido nele, e esse ORM pode se comunicar com qualquer banco de dados que você estiver usando, assim como o MongoDB. Neste exemplo, o Ngnix é escolhido por ser um pouco mais leve que o Apache em alguns aspectos. E este exemplo, como o exemplo anterior mais 'moderno', usa hospedagem em nuvem porque é mais barato ter alguém gerenciando suas falhas de hardware até que você esteja usando um tonelada (provavelmente literalmente) de hardware.

No geral, porém, esses ambientes tendem a abstrair sua complexidade em partes isoladas. Nenhum desenvolvedor ou técnico pode saber tudo. O resultado é que, com o tempo, o código mais complicado de escrever geralmente foi abstraído. Os principais exemplos são os componentes ambientais amplamente usados ​​que especialistas de classe mundial escrevem e mantêm em vez de desenvolvedores internos: servidores da web, redes, NOCs e mecanismos de banco de dados. Portanto, sua 'necessidade de saber' como desenvolvedor padrão raramente incluirá o armazenamento de milhões de pontos de dados em uma árvore B, descobrindo como evitar que um banco de dados tenha condições de corrida ou evitando vazamentos de memória durante a janela de 99.9999% de tempo de atividade de um servidor web.

Muitos ambientes modernos contêm ORMs, a ponto de o desenvolvimento de banco de dados ter valor reduzido como uma opção de carreira. Depois de escrever procedimentos armazenados contendo mais de 1000 linhas de código, ter alguém dizendo, “SQL é legal, mas você não pode fazer muito com ele” para mim uma vez foi ... desanimador. Mas há um motivo para isso: como prática recomendada, o código não deve ser armazenado em seu banco de dados. ORMs modernos como Entity Framework, modelos do Django e Hibernate (que não usei) abstraem o banco de dados do código. Definitivamente, há uma compensação entre ter um administrador de banco de dados capaz de ajustar a estrutura de dados para desempenho e ter programadores capazes de criar livremente.

Mas, principalmente, os ORMs também abstraem a comunicação entre dois sistemas: código e dados. Os padrões de comunicação costumam ser muito complexos. O resultado? Eles tendem a se tornar abstratos. Enquanto ensinava Python em um campo de treinamento, um de meus alunos queria usar a API do Twitter de maneira aprofundada. A API do Twitter era ampla e repleta de recursos. Dito isso, alguns recursos específicos só estarão disponíveis se você usar o OAuth 1 em vez do OAuth 2.

Acontece que onde OAuth 2 tinha algumas etapas simplistas e confiáveis, OAuth 1 era ... bizantino. Isso causou o desenvolvimento do padrão OAuth 2 mais simplista e várias bibliotecas projetadas para gerenciar o handshaking. Geralmente, faz muito sentido tentar manter seus métodos de comunicação o mais simples possível e seus dados limpos. Por esse motivo, as comunicações TCP / IP geralmente são feitas com bibliotecas e dados passados ​​com JSON. Os sites usam REST. Compartimentação e interfaces confiáveis ​​de baixo investimento são a norma, e devem ser.

E fazer com que essa comunicação de baixo investimento de tempo funcione consistentemente requer testes. Escrever testes não é divertido no início. Você sabe o que deseja fazer e conhece seus casos de uso, então por que escrever testes? Porque exige que você pense uma segunda vez e o enviará em uma direção melhor no geral.

Os testes de unidade não eram uma prática recomendada central até que a integração contínua fosse possível, mas agora que é, trabalhar com eles é fundamental. Os testes de ponta a ponta são mais difíceis de configurar, mas agora também são uma prática recomendada básica. Isso ocorre porque, à medida que o desenvolvimento fica mais rápido, os desenvolvedores se tornam responsáveis ​​por mais do sistema.

Se o sistema estiver quebrado, o tempo que você gasta consertando é tempo que você poderia usar para construir algo novo. Portanto, a longo prazo, o carregamento antecipado de todos os tipos de teste automatizado permite reduzir o tempo total gasto na manutenção do site. E, além disso, permite que você durma melhor (você não percebe o quanto o sono pode ser divertido até que você acorde às 3:00 da manhã para caçar um registro de transferência de dinheiro). Como o teste é tão importante, muitas equipes usam o Desenvolvimento Orientado a Testes, cuja base é escrever os testes antes você escreve uma única linha de 'código' que resolve seu problema.

Finalmente, ao tornar seu ambiente simples e sólido, recomendo a documentação. Não existe código autodocumentado. Escolher nomes de variáveis ​​simples e descritivos vai longe, mas colocar um pequeno bloco de explicação no início de uma classe ou função não vai matá-lo. Eu prometo. Em vez disso, pode ajudá-lo a localizar uma transferência de dinheiro nos registros no meio da noite.

Evite problemas simples de segurança

Ninguém sabe nada sobre segurança digital. Aposto cinco dólares que você pode colocar 'violação de dados' no mecanismo de busca de sua escolha agora mesmo e encontrar um. Isso ocorre parcialmente porque o mundo é grande e a segurança é difícil, mas principalmente porque qualquer sistema tem brechas de segurança. Portanto, seu trabalho principal como desenvolvedor não é realmente tornar seus sistemas à prova de balas, mas evitar colocar um grande sinal de 'venha aqui' neles.

As vezes em que meu código foi violado foram quando eu usei senhas padrão ou tive portas traseiras de desenvolvimento totalmente abertas que fechei apenas para que outra pessoa abrisse novamente. (Juro. Absolutamente. Nunca foi minha culpa, mesmo daquela vez.) Geralmente, você deseja evitar as coisas mais simples e espera que seja um alvo mais difícil do que o próximo aplicativo ou banco de dados.

A segurança da comunicação intra e interprocessos é onde estarão as suas falhas de segurança criadas pessoalmente. Portanto, estruturas REST e comunicações de objeto simplistas são padrões de mercado. Onde isso começa a dar errado é quando você pega objetos simples que você passou e os executa como entradas programaticamente. Por exemplo, pegando um objeto JSON da postagem HTTP, desserializando-o e lançando uma variável de lá em uma consulta diretamente como uma string. Isso significa que, ao passar variáveis, você deseja estar o mais certo possível sobre seu tipo.

Onde seu código termina - e suas bibliotecas começam - é onde os erros de segurança que você não produziu pessoalmente irão surgir. Quando vejo uma biblioteca desatualizada, também vejo as notas do patch para a nova versão. A razão pela qual a Microsoft corrige seu computador duas vezes por semana não é porque eles gostam de gastar dinheiro com programadores. É porque um sistema operacional tão amplamente usado como o Windows tem milhares de programadores tentando quebrá-lo o tempo todo. Se sua cópia local do Windows estiver desatualizada, você está se abrindo para mais vulnerabilidades. Seus servidores e estruturas não são muito diferentes.

No front pessoal, você também não quer que sua memória seja um ponto único de falha. Se você estiver encarregado de sistemas (o que, conforme o trabalho de 'desenvolvedor' fica maior, é mais provável), você eventualmente terá uma tonelada de senhas, chaves SSH, certificados de servidor, etc. para gerenciar. Eles geralmente são baseados em texto, então sugiro encontrar um gerenciador de senhas e usá-lo. (Gostar Caça Troy, Eu uso o KeePass e é grátis). Ele também gera senhas, para que você não tenha 'Dragons94!' como sua senha para 75 sites e sistemas diferentes. Use um gerador para fazer um grande, copie seu arquivo de senha de vez em quando e siga em frente. Além disso, alterne essas senhas e chaves regularmente. Não termine em Slashdot.

Finalmente, evite injeção de consulta. É simples de fazer e quase não é mencionado mais porque os frameworks ORMs / REST tendem a bloqueá-lo. Não perfeitamente, é claro, mas bem o suficiente. Se você for executar algo proveniente da comunicação entre ou dentro do processo, certifique-se de que seja apenas uma consulta antes de executá-la. Feito.

Controle de origem, integração de compilação e integração de teste

As práticas recomendadas centrais finais que eu definitivamente devo mencionar são o controle de origem, integração de construção e integração de teste. Se você não está usando o controle de origem, não sabe onde seu código está mudando ou como ele mudou. Além disso, se você não o estiver usando, ficará mais perdido do que o necessário.

Quanto à integração, Jenkins e TeamCity parecem que alguém inventou o fogo, se você ainda não os usou. Para mais leituras, isto é um bom começo. Ter um sistema que executa seus testes de unidade e cria para você significa que a implantação é confiável. A implantação sendo confiável significa que os lançamentos são mais uma questão de "O código e o cliente estão prontos um para o outro?", Em vez de "Quando, exatamente, podemos programar tudo isso para que realmente funcione?"

Eu fiz alguma automação de controle de qualidade para um grupo Wells Fargo há dez anos, e os lançamentos foram programados uma vez por trimestre, começando às 2h com 00 a 2 horas de implantação e 3-n [N sendo, em alguns casos, 4] horas de teste. Nem todos os testes que precisávamos fazer poderiam ser feitos com um servidor de integração agora, mas os próprios lançamentos teriam sido mais suaves com a tecnologia atual. E para usar uma tecnologia melhor, você precisa saber o que é e as tendências atuais.

3. Acompanhamento das tendências da indústria

A velocidade e a eficiência do processador podem ter dobrado a cada poucos anos durante décadas, mas a programação depende de humanos - e mudamos muito mais devagar. Se você ficar de olho nas novas ferramentas e práticas que outras pessoas estão usando para produzir software, também poderá adotá-las para ajudar na sua produtividade.

O melhor lugar para descobrir quais novas tecnologias e práticas são eficientes são as ofertas de empregos. Muitos empregos (especialmente em pequenas empresas) nunca chegam a painéis publicitários amplos, então, uma vez que uma empresa está anunciando agressivamente uma posição, ela procura algo específico que não consegue encontrar entre os contatos existentes de seus gerentes de desenvolvimento. Assim, quando uma empresa está disposta a correr o risco de contratar um desconhecido completo, eles geralmente tentam afirmar exatamente quais competências técnicas eles desejam que aquele desconhecido completo tenha.

Empresas menores e mais novas tendem a usar as tecnologias mais atualizadas. Isso ocorre principalmente porque a mudança de sua cultura os direciona para projetos de baixo investimento com retornos rápidos, mas também há vários outros fatores em ação, incluindo o seguinte:

• A rotatividade em empresas menores é maior e os trabalhadores de tecnologia têm mais facilidade para encontrar o próximo emprego com experiência atualizada
• Proprietários de projetos em pequenas empresas tendem a ter mais poder para escolher suas próprias tecnologias
• Projetos menores significam que usar um novo software é um risco menor

As empresas maiores tendem a contrastar com isso e adotar novas tecnologias de forma mais conservadora. Confiabilidade, relação custo / benefício e risco são muito mais importantes para uma empresa tradicional com requisitos de continuidade de negócios. Portanto, se você olhar as ofertas de emprego, muitas vezes perceberá que as grandes empresas estão dois a quatro anos atrasadas em termos de tecnologia de ponta.

Todo ano, Stack Overflow pergunta a todos os seus desenvolvedores em quais linguagens eles estão programando e desejam desenvolver. Se você descobrir o que outros programadores querem aprender, dois ou três depois será (se não muito complicado - estou olhando para você, CULisp) muito mais amplamente usado. Os desenvolvedores geralmente desejam permanecer empregados, então procuram alinhar seu aprendizado com as necessidades futuras dos empregadores em potencial. Assim, os desenvolvedores estão continuamente tentando substituir as porções mais ineficientes de seu tempo usando ferramentas mais eficientes. Dito isso, a parte mais demorada do desenvolvimento de software sempre será o ajuste de quais ferramentas e códigos pode fazer para a funcionalidade do usuário final, pessoas e empresas usar.

Se você for ainda mais fundo do que essas fontes básicas de informação, poderá descobrir que existem outros lugares para observar o que está por vir. Slashdot, Quora, Reddit e outros fóruns / locais de reunião online contêm mais informações - que geralmente não são confiáveis ​​e devem ser verificadas em outras fontes - do que os meios de comunicação padrão. Aprender qual idioma será o próximo passo é frequentemente uma questão de ler as tendências da indústria que os desenvolvedores ativos acreditam que valem a pena. Mas saber quais são essas tendências não é suficiente; você vai precisar praticá-los sozinho.

4. Melhores práticas e sua carreira

De certa forma, a melhor abordagem para aprender métodos de desenvolvimento de software é trocar de emprego. As tecnologias e práticas têm curvas de adoção semelhantes - íngremes no início, seguido por um crescimento lento se se tornarem amplamente utilizadas e, em seguida, um declínio lento. A maior diferença entre as várias tecnologias é se há ampla adoção e a duração do ciclo de vida. Portanto, se você estiver em um campo como o desenvolvimento de front-end, a curva de crescimento e adoção de uma tecnologia pode acontecer inteiramente em um período de anos, e o declínio não envolverá muito trabalho de manutenção. O resultado? Se você deseja permanecer relevante em sua carreira de desenvolvimento inicial, não pode descansar sobre os louros.

Como escolher seu próximo trabalho de engenharia

Geralmente, quando você está procurando uma nova posição, recomendo que você procure três coisas. Vamos decompô-los.

Aprendizagem: Em primeiro lugar, você deseja que a nova posição lhe ensine algo. Como um desenvolvedor experiente, você sempre terá a opção de escolher entre dois tipos de ambientes de trabalho: aqueles nos quais você tem vasta experiência ou novos. É mais provável que você receba mais por trabalhar com tecnologias que já conhece. Dito isso, se você misturar tecnologias com as quais está parcialmente familiarizado e tecnologias que não conhece, pode agregar valor e, ao mesmo tempo, adquirir talentos / marcadores adicionais em seu currículo.

Prazer: A segunda coisa mais importante sobre qualquer posição, tecnicamente, é escolher problemas e situações de que você goste. Quanto mais você gosta dos problemas que está resolvendo, mais disposto estará a expandir seu conjunto de habilidades e investir tempo / esforço para se destacar no que faz.

Adequação: Em terceiro lugar, conheça a natureza da empresa. As pequenas empresas tendem a dar a seus funcionários uma grande variedade de responsabilidades. Em uma empresa pequena o suficiente, você não pode ter um cargo preciso; Atualmente, sou responsável pelo gerenciamento de instâncias da AWS, processos de construção do TeamCity, administração de banco de dados, programação em cinco ou seis linguagens diferentes, notificações de lançamento, hotfixes, decisões arquitetônicas e assim por diante.

Em cargos anteriores, tive áreas únicas de responsabilidade (verificar e retificar resultados de reconciliação contábil para um departamento de faturamento interno, por exemplo) e descobri que quanto maior a empresa, mais meu tempo se concentrava em um único conjunto de tarefas. Geralmente, se você quiser aprofundar sua compreensão de um conjunto específico de tarefas, você será melhor atendido em uma grande empresa. Trabalhar com responsabilidades extensas e diversas (e uma rede de segurança limitada) geralmente acontecerá em uma pequena.

Na maioria das vezes, uma empresa manterá as tecnologias e práticas com as quais está trabalhando quando você começar a trabalhar nela (a menos que você seja contratado para implementar algo novo!). No entanto, quanto menor e mais flexível a empresa, maior a probabilidade de você ter autonomia para implementar qualquer ferramenta que achar adequada. Aproveite isso, pesquise as soluções mais viáveis ​​para seus problemas mais difíceis e faça com que funcionem.

Por outro lado, pode haver vantagens em trabalhar para uma empresa maior, se você pode obter permissão para implementar um novo sistema ou prática, você também pode obter treinamento sobre como fazê-lo. Além disso, é mais provável que uma falha desastrosa seja tolerada em uma empresa maior, de modo que o risco de adquirir familiaridade com uma nova tecnologia é significativamente menor.

Mais Educação

Algumas das melhores práticas são mais fáceis de adquirir em um ambiente escolar mais formal (ou outro ambiente educacional). Embora seja bastante fácil adquirir um novo idioma sozinho, às vezes é muito difícil se esforçar para aprender os meandros de tópicos mais profundos. Uma base teórica sólida é útil para manter uma carreira estável, assim como a gravidade da educação avançada ou de credenciais de campo de treinamento novas e quentes.

O mercado para programadores está crescendo. Não o vejo tão forte desde 1999. Se você gosta de programar por si só e o mercado entra em crise, diplomas avançados são um excelente investimento quando é mais difícil encontrar um emprego. Tornar-se mais versátil e compreender como as tecnologias são desenvolvidas o tornará mais empregável a longo prazo. Uma despesa após o trabalho (ou enquanto estiver desempregado) por 2 a 4 anos pode aumentar significativamente sua renda vitalícia, além de aumentar a segurança no emprego.

Mas se você estiver com pressa, os bootcamps também são um bom lugar para aprender tudo o que há de novo e que está por vir. Uma das 'melhores práticas' atuais para encontrar um novo emprego é ter um repositório GitHub sólido de código que você criou. Se você criar este repositório em um bootcamp, além de um ponto final interessante, esse boot camp pode ser um tempo bem gasto, mesmo para um desenvolvedor experiente. Codementor seria um ótimo lugar para obter orientação sobre como construir uma base de código GitHub para impressionar.

Enquanto desço a escada do "investimento de tempo", as conferências são um bom lugar para descobrir o que está na moda, além de poder fazer workshops com desenvolvedores que criaram a tecnologia mais recente. Amazon funciona mensalmente (no mínimo) eventos na AWS, e todos os tipos de outros eventos são programados regularmente. Os apresentadores e educadores em qualquer conferência serão tendenciosos a favor das tecnologias que passaram anos desenvolvendo, trabalhando ou são pagos para apoiar. Dito isso, porque eles são so investidos em uma tecnologia específica, eles geralmente são informativos e interessados ​​em ajudá-lo a expandir sua base de conhecimento com as tecnologias escolhidas.

Treinamento / certificação de tecnologia específica está sempre disponível. Eu sei, em algum lugar na minha cabeça, que minha vida seria muito mais fácil se eu tivesse passado seis meses conseguindo Oracle DBA certificado entre meus vinte e poucos anos. As pequenas empresas não respeitam muito as certificações, mas as grandes empresas veem as certificações como uma mitigação de seus riscos. Se você for certificado com uma tecnologia específica, é mais provável (aos olhos deles) que seja competente com aquela tecnologia específica de uma forma esperada. Portanto, obter a certificação pode ser um grande passo em direção a uma carreira relativamente estável em um mercado tumultuado. Como alerta, também pode ser um grande investimento em uma tecnologia que está desaparecendo do mercado de trabalho.

A contribuição de código aberto está sempre disponível. Embora o software de sistema operacional seja notoriamente confuso, trabalhar em vários projetos ajudará você a entender quais padrões ajudariam em um mundo ideal. Embora essa possa ser uma etapa assustadora para um desenvolvedor mais recente, vale a pena tentar. Tendo trabalhado com uma série de bases de código construídas profissionalmente, minha aposta é se você quisesse entrar e escrever comentários / documentação lógicos nos 10 principais projetos de código aberto, você poderia começar amanhã e ninguém reclamaria (contanto que suas contribuições fizessem senso!).

Eu descobri que ensinando por Codementador me ensinou muito. Cada pergunta que um aluno tinha era completamente nova para mim, e passei um bom tempo pesquisando e consertando coisas que não sabia que poderiam quebrar. Esse tipo de experiência foi espelhado durante o tempo que passei ensinando em um campo de treinamento.

A maneira absolutamente mais baixa de investimento para aprender alguns novos métodos de gerenciamento de código é ir para um hackathon. Eu fiz apenas um 'produto viável e divertido' (um jogo) durante esse hackathon, mas aprendi muito com uma grande variedade de outros programadores.

5. Conclusão

Como desenvolvedor, aprender e usar as melhores práticas é a base para manter uma carreira sólida. A única constante na indústria de computadores é a mudança, e ficar para trás na curva é caro. Observando continuamente a forma como a indústria muda, você pode produzir um código melhor com mais rapidez. Produzindo um código melhor com mais rapidez, você pode criar soluções mais eficazes.

Existem muitos recursos detalhando como outros melhorou a qualidade do códigoou construiu negócios em código, mas todas as tecnologias que você usa durante sua carreira certamente mudarão ou se transformarão enquanto você está construindo com elas. Fique atento ao seu ambiente e sua carreira pode prosperar.

Fonte: https://www.codementor.io/blog/updating-your-best-practices-7gzzfh3vrx