O Habr está cheio de previsões e conselhos sobre o que fazer no próximo ano — quais linguagens aprender, em quais áreas se especializar, como cuidar da própria saúde. Parece inspirador! Mas toda medalha tem dois lados, e tropeçamos não apenas em algo novo, mas na maior parte do tempo no que fazemos todos os dias. "Por que ninguém me avisou!", exclamamos irritados, geralmente dirigindo-nos a nós mesmos. Chamamos a atenção para nós — reunimos uma lista do que NÃO se deve fazer em 2020 (ou talvez sempre).
E a gravidade não foi perguntada.
Gostaríamos muito de organizar as anti-recomendações em ordem, do mais importante ao menos significativo. Mas elas são tão comuns, equivalentes e conhecidas que vamos escrever de maneira aleatória. Bem, vamos checar a lista?
Não entre na TI se tudo está bem.
Não estude uma nova tecnologia para mudar de profissão ou começar do zero. Nossa época é ótima porque você pode aprender, mudar de emprego e até mudar completamente de área — e assim até a aposentadoria. Isso é incrível, sedutor. Mas se você tem mais de 28-30 anos, não deve largar tudo para entrar na TI ou mudar para uma nova pilha (por exemplo, se você escreve sistemas de alta carga em Java e de repente decide migrar para redes neurais em Python). A razão é simples: será difícil para você. Primeiro, a competição é alta por especialistas que estão nesse stack desde o início da carreira; segundo, você terá que recomeçar como júnior com um salário baixo; terceiro, será moralmente difícil ocupar uma posição tão baixa na hierarquia. Portanto, se você deseja avançar em outra direção, tente fazer isso dentro do seu trabalho atual e das tarefas correntes, ou desenvolva novos conhecimentos como um hobby, crie um projeto paralelo para chegar a um novo emprego já não como júnior.
Mudar de stack só faz perder tempo.
Não fique pulando entre stacks de tecnologias para o seu desenvolvimento. Se você está escrevendo um projeto em uma linguagem, utilizando um determinado framework e bibliotecas, não deve abandonar tudo e reescrever em Dart só porque te parece interessante. Adote como regra encontrar justificativa para mudar de tecnologia — não apenas no nível do "quero-não posso", mas também no nível financeiro e de engenharia.
Não se prenda às suas convicções e endureça.
Aderir a uma única linguagem ou tecnologia e não aprender algo novo é uma extremidade, assim como mudar de stack a cada nova tecnologia. Devem sempre estudar novas bibliotecas e frameworks; não sejam teimosos ao pensar que tudo de bom já foi inventado antes de vocês e aperfeiçoado apenas por vocês. Praticamente toda linguagem recebe atualizações constantes, que às vezes podem melhorar significativamente seu projeto. Não se acomodem com a dinâmica do seu stack e, assim que encontrarem algo incrível e útil, implemente-o no projeto!
A própria cabeça é boa, sempre é boa.
Não pensem com a cabeça dos outros, a sua é melhor. Infelizmente, alguns desenvolvedores sentam e aguardam instruções para codificar do erro anterior até o final, sem tentar adicionar algo pessoal ao projeto, desenvolver uma nova função, testar e sugerir para produção. Por que se esforçar quando há a cabeça do líder de equipe ou do gerente da empresa que resolverá tudo? Se você se reconheceu aqui, temos más notícias: uma postura passiva não ajudará na sua carreira nem no seu desenvolvimento. Você tem a chance de experimentar suas habilidades como engenheiro de desenvolvimento, e não apenas como codificador em um projeto real, e perceber para onde deve ir, o que está faltando, mas prefere gastar seu tempo em outra coisa, fazendo exatamente 'do início ao fim'. Esses, no setor de TI atual, sobrevivem cada vez pior; saiam do estado de letargia.
Os usuários são pessoas terríveis.
Não subestime os usuários do seu software: se você não está escrevendo para programadores, espere que o programa enfrente uma incompreensão intransponível. Nos primeiros dias ou semanas, o usuário vai detestar seu software, porque 'o antigo não era tão atrapalhado'. Para evitar isso, ofereça uma documentação excelente e materiais de treinamento. Na instalação ou na compra, insista de forma muito clara que os manuais devem ser lidos antes de começar a trabalhar com o programa, e não após o colapso do banco de dados, a perda da senha e a autorregulação.
Não subestime os usuários: eles são mais espertos, mais inteligentes e mais curiosos do que você imagina. Se você acha que aquele bug no formato da variável e a exceção na 138ª entrada com um intervalo de um segundo não vão aparecer, você está enganado — aparecerão e afetarão o funcionamento do seu aplicativo de maneiras mais inusitadas. A regra do dilettante se aplica: é ele quem lidará com os testes melhor. Mas os usuários, por algum motivo, não gostam de encontrar bugs em produção — não existe solidariedade na área de TI. Em geral, quanto mais confiante você estiver no seu software, melhor. Afinal, é melhor adiar o lançamento de algumas funções do que adicioná-las a um aplicativo em funcionamento e torná-lo repentinamente instável.
Chega de googlar!
Pare de recorrer apenas ao Google. Não vamos discutir — na área de desenvolvimento, você pode encontrar muito com uma pesquisa direta no mecanismo de busca. Quanto mais fundo você cavar em busca de informações, mais dados laterais você obterá e mais aprenderá, porque acabará sabendo algo novo que não está relacionado à sua consulta, mas que pode ser útil no futuro. Busque materiais completos, livros, artigos etc. As linguagens e bibliotecas têm especificações, comunidades, tutoriais e assim você obtém a maneira mais confiável de desenvolver suas habilidades de programação — apenas ler a documentação, em vez de procurar soluções locais e fragmentos de código de terceiros. E se a sua solução for mais otimizada, mais rápida e melhor?
Confie, mas verifique
Não use bibliotecas e frameworks criados por desenvolvedores de terceiros sem antes verificar o código e adaptá-lo para os seus objetivos. Você não tem fundamentos para confiar cegamente nesse autor de código, que você nem conhece. Sim, elementos maliciosos intencionais em código de terceiros não são tão frequentes, e não há necessidade de ser paranoico, mas a cópia cega de partes prontas de software para o seu projeto pode levar a consequências imprevisíveis. Portanto, sempre leia e analise o código antes de usá-lo e realize testes após a implementação do código.
Faça backups!
Pare de não fazer backups ou mantê-los nos mesmos servidores de terceiros onde seu projeto está hospedado. Você acha que é um conselho engraçado e desnecessário? Mas mais de 700 participantes de um grupo no Telegram, que se viram em uma situação desagradável com a interrupção de um famoso data center, não pensavam assim — tinha de tudo: desde projetos pequenos até grandes sites de órgãos governamentais e bases corporativas 1C e de faturamento. Uma parte significativa — sem backups ou com backups armazenados lá mesmo. Portanto, distribua os riscos e armazene o backup pelo menos no seu principal serviço de hospedagem, em um VDS confiável e no seu servidor local. No final, isso sairá muito mais em conta.
Chega de prejudicar seu projeto.
Não faça no projeto de trabalho o que você gostaria, mas faça o que os clientes precisam. Sim, é extremamente interessante e incrível criar sua própria rede neural, treiná-la e integrá-la ao seu software, mas se seus clientes precisam de um simples gerenciador de contatos, isso será um luxo dispendioso. Veja como o projeto funciona, leia a documentação, analise os feedbacks e solicitações dos clientes e implemente o que dará valor comercial ao projeto. Se você quer fazer algo científico ou extremamente complexo, comece pelo seu próprio projeto.
Não é código, é um novelo de nervos.
Não escreva código ilegível e não documentado. Conhecemos essa tática: o desenvolvedor escreve o código da maneira que quiser, deliberadamente o torna um pouco confuso, para que ninguém dos colegas consiga entender o que foi escrito — uma espécie de vingança preventiva antes que algo aconteça. No entanto, você está colocando em risco não apenas a empresa (que paga por seu trabalho), mas a si mesmo: é bastante provável que você mesmo não lembre o que queria dizer com essa ofuscação não intencional. O mesmo se aplica ao código não documentado: confiando em sua lógica de nomeação de variáveis e funções e em boa memória, depois de alguns anos, você pode não recordar por que escolheu exatamente aquele loop, método, padrão, etc. Documentar o código e ter uma boa estrutura é um ótimo serviço para os colegas, para o empregador e, acima de tudo, para si mesmo.
Mantenha-o simples, idiota.
Não complique o código, as soluções e os projetos. Não é necessário criar uma estrutura complexa e gerar entidades sem um significado especial. Quanto mais complicado for seu código, mais escravo dele você se torna — será extremamente difícil mantê-lo e desenvolvê-lo. Claro, o famoso princípio KISS ("Keep it simple, stupid") nem sempre se aplica, mas não foi criado em vão: a simplicidade e a elegância do código são a chave para seu uso e reutilização bem-sucedidos.
Use proteção
Não ignore a segurança — em 2020 isso é literalmente criminoso. Mesmo que sua empresa, seu desenvolvimento e você não interessam a criminosos, você pode ser afetado por problemas relacionados à falha de algum segmento da rede, provedor de hospedagem, ataque a um data center, roubo de senhas de e-mail e comportamento inseguro de colaboradores que podem roubar dados da empresa, levar clientes ou o código de todo o projeto. Se estiver ao seu alcance e dentro de suas competências, procure proteger os projetos com os quais trabalha. E cuide da sua própria segurança da informação, isso nunca fez mal a ninguém.
Não cuspa no poço
Não faça mal ao seu empregador. Atualmente, as comunicações atingiram um nível em que, por exemplo, todos os RHs da cidade se conhecem virtualmente e podem trocar qualquer informação em chats e grupos fechados (como ajudar alguém a conseguir emprego, ou escrever "Vasiliy Ivanov, arquiteto de sistemas, antes de sair apagou todas as contas, apagou os backups e desligou a rede, a recuperação levou 3 dias. Não contratem-no"). Assim, seu comportamento será prejudicial a você — e às vezes uma relocação para outra cidade ou capital não ajuda. Mesmo que você saia se sentindo ofendido, não há melhor vingança do que ser um colaborador útil e incrível para a concorrência 🙂 E o principal, completamente impune.
Isso também não é uma boa ideia. Mas, como a experiência mostra, não vamos parar.
E, na verdade, amigos, leiam os conselhos, mas façam como acharem melhor — pois as verdadeiras descobertas acontecem quando duvidamos das verdades já estabelecidas. Parabéns pelo Ano Novo, que seus projetos sejam bem-sucedidos, que sua carreira não seja entediante, que seus colegas e supervisores sejam razoáveis, e que a vida, de maneira geral, flua bem. Em resumo, um brinde ao Ano Novo e ao novo código!
Com amor,
a equipe da RegionSoft Developer Studio
No novo ano, continuaremos a trabalhar para você e a desenvolver um poderoso sistema de CRM para desktop. e um helpdesk simples e conveniente, além de um sistema de tickets. .
Fonte: habr.com
