O Habr está cheio de previsões e conselhos sobre o que fazer no próximo ano — quais idiomas aprender, em quais áreas focar, como cuidar da saúde. Parece inspirador! Mas toda moeda tem dois lados, e tropeçamos não só em coisas novas, mas principalmente nas coisas que fazemos todos os dias. "Por que ninguém me avisou!", exclamamos irritados, geralmente nos dirigindo a nós mesmos. Estamos pedindo fogo — compilamos uma lista de coisas que você não deve fazer em 2020 (e talvez nunca).
Mas eles nem sequer perguntaram sobre a gravidade.
Gostaríamos muito de classificar essas recomendações negativas em ordem de importância, da mais importante à menos importante. Mas elas são tão disseminadas, tão semelhantes e tão familiares a quase todos, que as escreveríamos fora de ordem. Então, vamos à lista?
Não há necessidade de entrar na área de TI se tudo estiver indo bem.
Não aprenda uma nova tecnologia para mudar de carreira ou começar do zero. A beleza dos nossos tempos é que você pode aprender, mudar de emprego e até mesmo de área — mesmo depois de se aposentar. É algo maravilhoso e tentador. Mas se você tem mais de 28 ou 30 anos, não abandone tudo para entrar na área de TI ou mudar para uma nova pilha de tecnologias (por exemplo, você desenvolve sistemas de alta carga em Java e de repente decide migrar para redes neurais em Python). O motivo é simples: não será fácil. Primeiro, a concorrência é alta por parte de especialistas que trabalham com essa pilha desde o início de suas carreiras; segundo, você terá que voltar a ser um júnior com um salário baixo; e terceiro, será emocionalmente desafiador para você se tornar um subordinado no nível mais baixo da hierarquia. Portanto, se você quer seguir uma direção diferente, tente fazer isso dentro do contexto do seu trabalho e das suas tarefas atuais, ou desenvolva novos conhecimentos como hobby, trabalhando em um projeto pessoal, para que você possa começar seu novo emprego não mais como júnior.
Trocar de pilha é apenas uma perda de tempo.
Não fique alternando entre diferentes conjuntos de tecnologias no seu desenvolvimento. Se você está escrevendo um projeto em uma linguagem e usando um framework e bibliotecas específicos, não jogue tudo fora e reescreva em Dart só porque parece interessante. Estabeleça como regra encontrar uma justificativa para a troca de tecnologias — não apenas em termos de "quero" ou "não posso", mas também em termos financeiros e de engenharia.
Não há necessidade de se manter firme e ficar bronzeado.
Apegar-se a uma única linguagem ou tecnologia e não aprender novas é tão ruim quanto trocar de stack a cada nova tecnologia. Certifique-se de aprender novas bibliotecas e frameworks, e não seja teimoso a ponto de acreditar que tudo que é melhor já foi inventado e aperfeiçoado por você. Quase todas as linguagens são constantemente atualizadas, o que às vezes pode melhorar significativamente seu projeto. Não seja preguiçoso em monitorar o progresso da sua stack e, assim que encontrar algo interessante e útil, não hesite em incorporá-lo ao seu projeto!
Sua própria cabeça é boa, sempre boa.
Não pense como os outros pensam; a sua própria cabeça é melhor. Infelizmente, alguns desenvolvedores ficam sentados esperando a tarefa de codificar do último erro até o fim, sem tentar contribuir com nada de próprio punho, desenvolver uma nova funcionalidade, testá-la e colocá-la em produção. Para quê se dar ao trabalho quando se tem um líder de equipe ou gerente que cuidará de tudo? Se você se identifica com isso, temos más notícias: uma atitude passiva não ajudará em sua carreira ou desenvolvimento. Você tem a chance de testar suas habilidades como engenheiro de software, não como programador, em um projeto real de produção e entender para onde ir e o que está faltando, mas prefere gastar seu tempo em outras coisas e fazer exatamente o que precisa. Pessoas assim são cada vez mais insustentáveis na TI moderna; acorde desse estado de inércia.
Usuários são pessoas assustadoras
Não superestime os usuários do seu software: se você não está escrevendo para programadores, espere que seu programa seja recebido com total incompreensão. Nos primeiros dias ou semanas, os usuários vão odiar seu software porque "a versão antiga não era tão fácil de usar". Para evitar isso, crie uma documentação e materiais de treinamento excelentes. Ao instalar ou comprar o software, recomende fortemente que os usuários leiam os manuais antes de usar o programa, e não depois de uma falha no banco de dados, perda de senha ou falta de autocontrole.
Não subestime os usuários: eles são mais astutos, inteligentes e curiosos do que você imagina. Se você acha que aquele bug de formato de variável e o 138º erro de Enter não vão aparecer a cada segundo, está enganado — eles vão aparecer e impactarão seu aplicativo das maneiras mais bizarras. A regra do amador se aplica: são eles que fazem os melhores testes. Mas, por algum motivo, os usuários não gostam de encontrar bugs em produção — eles não têm nenhuma solidariedade com a equipe de TI. Em geral, quanto mais confiança você tiver no seu software, melhor. Afinal, é melhor adiar o lançamento de alguns recursos do que adicioná-los a um aplicativo em execução e, de repente, torná-lo inacabado.
Pare de pesquisar no Google!
Pare de depender exclusivamente do Google. É inegável que, no desenvolvimento, você pode encontrar muita coisa com uma busca direta. Quanto mais você se aprofunda, mais dados "extras" você obtém e mais aprende, pois descobre coisas novas não relacionadas à sua busca inicial, mas que provavelmente serão úteis no futuro. Consulte recursos abrangentes, livros, artigos e assim por diante. Linguagens e bibliotecas têm especificações, comunidades e tutoriais, e essa é a maneira mais confiável de desenvolver suas habilidades de programação — simplesmente lendo a documentação, em vez de procurar soluções locais e trechos de código de outras pessoas. E se a sua solução for mais otimizada, mais rápida e melhor?
Confie, mas verifique
Não utilize bibliotecas e frameworks criados por desenvolvedores terceirizados sem revisar o código e adaptá-lo às suas necessidades. Não há motivo para confiar implicitamente no autor do código se você não o conhece. Embora elementos maliciosos intencionais em código de terceiros sejam raros, não há necessidade de paranoia; copiar cegamente software existente para o seu projeto pode levar a consequências imprevisíveis. Portanto, certifique-se de ler e analisar o código antes de usar e realizar testes após a implementação.
Faça backups!
Pare de deixar de fazer backups ou de armazená-los nos mesmos servidores de terceiros onde seu projeto está hospedado. Acha esse conselho ridículo e inútil? Mas mais de 700 participantes de um chat no Telegram, que recentemente foram afetados pela infelicidade de uma queda de um data center conhecido, não pensaram assim — o problema envolvia desde projetos pessoais até grandes sites governamentais e bancos de dados corporativos de faturamento e 1C. Uma parcela significativa deles ou não tinha backups ou os armazenava nos mesmos servidores. Portanto, distribua o risco e armazene backups pelo menos em sua hospedagem principal, em um VDS confiável e em seu próprio servidor local. No final das contas, será muito mais barato.
Pare de trazer seus próprios pertences, pois isso prejudica o projeto.
Não faça o que você quer em um projeto de trabalho; faça o que seus clientes precisam. Sim, é incrivelmente interessante e divertido criar sua própria rede neural, treiná-la e implementá-la em seu software, mas se seus clientes precisam apenas de um gerenciador de contatos simples, será um gasto desnecessário. Aprenda como o projeto funciona, leia a documentação, leia as avaliações e solicitações dos clientes e implemente o que agregará valor comercial ao projeto. Se você quiser criar algo científico ou altamente complexo, comece com seu próprio projeto.
Não um código, mas um feixe de nervos.
Não escreva código ilegível e sem documentação. Já vimos esse clichê antes: um desenvolvedor escreve código como bem entende, deliberadamente ofuscando-o para que ninguém mais consiga decifrá-lo — uma espécie de vingança preventiva antes que algo dê errado. No entanto, você está colocando em risco não apenas a empresa (que lhe paga pelo seu trabalho), mas também a si mesmo: você pode nem se lembrar do que queria dizer com essa ofuscação não intencional. O mesmo vale para código sem documentação: confiando na sua própria lógica para nomear variáveis e funções e em uma boa memória, daqui a alguns anos você pode não se lembrar por que escolheu um determinado loop, método, padrão etc. Documentar seu código e estruturá-lo bem é um grande serviço prestado aos seus colegas, ao seu empregador e, principalmente, a você mesmo.
Mantenha isso simples, idiota
Não complique demais seu código, suas soluções e seus projetos. Evite criar estruturas complexas e gerar entidades sem sentido. Quanto mais complexo for o seu código, mais você se tornará refém dele — será extremamente difícil mantê-lo e desenvolvê-lo. É claro que o famoso princípio KISS ("Keep it simple, stupid") nem sempre se aplica, mas é um princípio bem estabelecido: simplicidade e elegância no código são a chave para sua implementação e reutilização bem-sucedidas.
Tome precauções
Não ignore a segurança — em 2020, isso é literalmente crime. Mesmo que sua empresa, seu desenvolvimento e você não sejam alvos de ataques, vocês podem ser afetados por problemas relacionados a um segmento de rede, um provedor de hospedagem, um ataque a um data center, o roubo de senhas de e-mail ou o comportamento inseguro de funcionários que podem levar ao roubo de dados da empresa, clientes ou todo o código do projeto. Se estiver ao seu alcance e dentro da sua área de especialização, tente proteger os projetos em que trabalha. E, claro, pratique boas práticas de segurança da informação — nunca fez mal a ninguém.
Não cuspa no poço.
Não seja grosseiro com seu empregador. A comunicação atingiu um nível tão alto hoje em dia que, por exemplo, todos os funcionários de RH de uma cidade se conhecem e podem trocar qualquer informação em chats e grupos fechados (desde ajudar alguém a encontrar um emprego até escrever: "Vasily Ivanov, um arquiteto de sistemas, excluiu todas as contas antes de sair, apagou backups e desativou a rede; levou três dias para restaurá-la. Não o contrate."). Portanto, seu comportamento só jogará contra você — e às vezes nem mesmo mudar para outra cidade ou para a capital ajudará. Mesmo que você saia com ressentimento, não há vingança melhor do que se tornar um funcionário útil e excelente de um concorrente. 🙂 E o mais importante, com total impunidade.
Também não vale a pena fazer isso. Mas, como a experiência demonstra, não vamos parar.
Em geral, amigos, leiam os conselhos, mas façam o que acharem melhor — afinal, as verdadeiras descobertas acontecem quando questionamos verdades já estabelecidas. Feliz Ano Novo! Que seus projetos sejam um sucesso, sua carreira seja empolgante, seus colegas e chefes sejam sensatos e sua vida, de modo geral, seja um sucesso. Então, um brinde ao Ano Novo e a um novo código!
Com amor,
Equipe do RegionSoft Developer Studio
No ano novo, continuaremos trabalhando para você e desenvolvendo um sistema CRM robusto para desktop. e um sistema de suporte e emissão de tickets simples e prático. .
Fonte: habr.com
