O hub está cheio de previsões e conselhos sobre o que fazer no próximo ano – que línguas aprender, em que áreas focar, o que fazer com a sua saúde. Parece inspirador! Mas toda moeda tem dois lados, e tropeçamos não apenas em algo novo, mas principalmente naquilo que fazemos todos os dias. “Por que ninguém me avisou!”, exclamamos irritados, geralmente voltando-nos para nós mesmos. Vamos acender o fogo sobre nós mesmos - compilamos para você uma lista do que NÃO fazer em 2020 (e talvez sempre).
Mas eles não perguntaram sobre a gravidade
Gostaríamos muito de ordenar as anti-recomendações, das mais importantes para as menos importantes. Mas são tão comuns, equivalentes e familiares a quase todas as pessoas que escreveremos ao acaso. Bom, vamos conferir a lista?
Não há necessidade de ir ao TI se tudo estiver bem
Não aprenda uma nova tecnologia para mudar de carreira ou recomeçar. Nosso tempo é maravilhoso porque você pode estudar, mudar de emprego, mudar radicalmente de área - e assim por diante, até a aposentadoria. É uma coisa legal e sedutora. Mas se você tem mais de 28-30 anos, não deve desistir de tudo para entrar em TI ou mudar para uma nova pilha (por exemplo, você escreve sistemas altamente carregados em Java e de repente decide entrar em redes neurais em Python). A razão é simples: não será fácil para você. Em primeiro lugar, há uma grande concorrência de especialistas que estão “sentados” nesta pilha desde o início de suas carreiras, em segundo lugar, você terá que se tornar um júnior novamente com um salário baixo e, em terceiro lugar, será moralmente difícil para você tornar-se um subordinado do nível mais baixo da hierarquia. Portanto, se você quiser seguir na outra direção, tente fazê-lo de acordo com seu trabalho e tarefas atuais, ou desenvolva novos conhecimentos como hobby, inicie um projeto favorito para que quando você chegar a um novo emprego você não seja mais um júnior.
Mudar pilha após pilha é apenas uma perda de tempo
Não se apresse entre pilhas de tecnologia para o seu desenvolvimento. Se você está escrevendo um projeto em uma linguagem, usando um determinado framework e bibliotecas, você não deve jogar tudo para o inferno e reescrevê-lo no Dart só porque acha interessante. Estabeleça como regra encontrar uma justificativa para a mudança de tecnologia - não apenas no nível “quero ou não posso”, mas também no nível financeiro e de engenharia.
Não há necessidade de se manter firme e virar bronze
Aderir a um idioma ou tecnologia e não aprender coisas novas é tão extremo quanto mudar sua pilha a cada nova tecnologia. Não deixe de estudar novas bibliotecas e frameworks, não seja teimoso em saber que tudo foi melhor inventado antes de você e concluído exclusivamente por você. Atualizações são lançadas constantemente para quase todos os idiomas, o que às vezes pode melhorar muito o seu projeto. Não tenha preguiça de monitorar a dinâmica da sua pilha e, assim que encontrar algo legal e útil, fique à vontade para arrastá-lo para o projeto!
Sua própria cabeça é boa, sempre boa
Não pense na cabeça dos outros, a sua é melhor. Infelizmente, alguns desenvolvedores sentam e esperam até receber uma tarefa para codificar do erro anterior até o final, sem tentar contribuir com algo próprio para o projeto, desenvolver uma nova função, testá-la e propor para produção. Por que se preocupar quando há um líder de equipe ou gerente de empresa que decidirá tudo sozinho? Se você se reconhece, então temos más notícias: uma posição passiva não ajudará nem na sua carreira nem no seu desenvolvimento. Você tem a chance de tentar ser um engenheiro de desenvolvimento, e não um codificador, em um projeto de combate real e entender para onde ir, o que está faltando, mas você prefere gastar seu tempo em outra coisa e fazer exatamente “daqui para agora." Essas pessoas sobrevivem cada vez pior na TI moderna, saem da animação suspensa.
Os usuários são pessoas terríveis
Não superestime os usuários do seu software: se você não estiver escrevendo para programadores, espere que o programa encontre mal-entendidos impenetráveis. Nos primeiros dias ou semanas, o usuário odiará seu software porque “o antigo não era tão estúpido”. Para evitar isso, faça ótimas documentações e tutoriais. Ao instalar ou comprar, sugira de forma muito intrusiva que os manuais devem ser lidos antes de começar a trabalhar com o programa, e não após travamento do banco de dados, perda da senha e autocontrole.
Você também não deve subestimar os usuários: eles são mais astutos, mais espertos e mais curiosos do que você imagina. Se você acha que o bug com o formato variável e a exceção no 138º pressionamento de Enter em intervalos de segundo não aparecerão, você está enganado - eles aparecerão e afetarão o funcionamento do seu aplicativo da maneira mais bizarra. Aplica-se a regra do amador: ele é quem melhor lida com os testes. Mas, por alguma razão, os usuários não gostam de encontrar bugs na produção – não há solidariedade de TI neles. Em geral, quanto mais confiante você estiver no seu software, melhor. Afinal, é melhor atrasar o lançamento de alguns recursos do que adicioná-los a um aplicativo funcional e torná-lo bruto de repente.
Pare de pesquisar no Google!
Pare de recorrer apenas ao Google. Nem vamos discutir - na área de desenvolvimento você pode encontrar muita coisa com uma solicitação direta a um mecanismo de busca. Quanto mais fundo você se aprofundar em busca de informações, mais dados “laterais” você receberá e mais aprenderá, pois aprenderá algo novo que não está relacionado ao seu pedido, mas provavelmente será necessário no futuro. Consulte materiais completos, livros, artigos, etc. Linguagens e bibliotecas têm especificações, comunidades, instruções e, assim, você obtém a maneira mais confiável de desenvolver habilidades de programador - basta ler a documentação e não procurar soluções locais e fragmentos de código de outras pessoas. E se a sua solução for mais ideal, mais rápida e mais interessante?
Confie, mas verifique
Não utilize bibliotecas e frameworks criados por desenvolvedores terceiros sem verificar o código e adaptá-lo para atender aos seus propósitos. Você não tem motivos para confiar incondicionalmente neste autor do código que você nem conhece. Sim, vários elementos maliciosos deliberados em códigos de terceiros não são tão comuns e você não deve sofrer de paranóia, mas copiar cegamente partes de software prontas em seu projeto pode levar a consequências imprevisíveis. Portanto, certifique-se de ler e analisar o código antes de usá-lo e testá-lo após implementá-lo.
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 este é um conselho ridículo e inútil? Mas mais de 700 participantes do bate-papo no Telegram, que se encontraram em uma recente situação desagradável com o fechamento de um conhecido data center, não pensaram assim - havia de tudo lá: de projetos favoritos a grandes sites governamentais. autoridades e bancos de dados corporativos 1C e de cobrança. Uma parte significativa está sem backups ou com backups no mesmo local. Portanto, distribua os riscos e armazene o backup pelo menos na hospedagem principal, em algum VDS confiável e no seu servidor local. Acabará sendo muito mais barato no longo prazo.
Pare de trazer o seu próprio em detrimento do projeto
Não faça o que você quer em um projeto de trabalho, mas faça o que os clientes precisam. Sim, é incrivelmente interessante e ótimo criar sua própria rede neural, treiná-la e implementá-la em seu software, mas se seus clientes precisarem de um gerenciador de contatos simples, isso será um exagero. Veja como funciona o projeto, leia a documentação, leia avaliações e solicitações de clientes e implemente o que agregará valor comercial ao projeto. Se você deseja criar algo científico ou extremamente complexo, comece com seu próprio projeto.
Não é um código, mas um feixe de nervosismo
Não escreva código ilegível e não documentado. Estamos familiarizados com esse truque: o desenvolvedor escreve o código o quanto quiser, confundindo-o deliberadamente um pouco para que nenhum de seus colegas possa entender o que ele escreveu - isso é uma espécie de vingança preventiva antes que algo aconteça. No entanto, você está colocando em risco não só a empresa (que lhe paga pelo seu trabalho), mas também a si mesmo: é provável que você mesmo não se lembre do que queria dizer com esse ofuscamento involuntário. É o mesmo com código não documentado: contando com sua lógica de nomenclatura de variáveis e funções e boa memória, depois de alguns anos você pode não se lembrar por que escolheu aquele loop, método, padrão específico, etc. Documentar seu código e sua boa estrutura é um ótimo serviço para seus colegas, seu empregador e, acima de tudo, para você mesmo.
Mantenha isso simples, idiota
Mantenha seu código, soluções e projetos simples. Não há necessidade de cercar uma estrutura complexa e produzir entidades sem significado especial. Quanto mais complexo for o seu código, mais você se tornará seu refém - será o mais difícil possível mantê-lo e desenvolvê-lo. É claro que o famoso princípio KISS (“Keep it simple, estúpido”) nem sempre é adequado, mas foi criado por uma razão: a simplicidade e a elegância do código são a chave para sua aplicação e reutilização bem-sucedidas.
Proteja-se
Não ignore a segurança – em 2020 ela é literalmente criminosa. Mesmo que sua empresa, desenvolvimento e você não sejam do interesse de invasores, você poderá ser afetado por problemas relacionados à derrota de algum segmento de rede, provedor de hospedagem, ataque ao data center, roubo de senhas de e-mail e comportamento inseguro de funcionários que podem roubar dados da empresa, roubando clientes ou o código do programa de todo o projeto. Se estiver ao seu alcance e dentro da sua área de atuação, tente proteger os projetos em que você está trabalhando. Bem, observe você mesmo a segurança da informação, isso nunca incomodou ninguém.
Não cuspa no poço
Não mexa com seu empregador. Hoje, a comunicação atingiu um nível tal que, por exemplo, todo o pessoal de RH da cidade se conhece à revelia e pode trocar qualquer informação em chats e grupos fechados (tanto para ajudar a encontrar um emprego como para escrever “Vasily Ivanov, arquiteto de sistemas, matou tudo antes de sair das contas, apagou backups e desligou a rede, a recuperação demorou 3 dias. Não o contrate." Assim, seu comportamento jogará exclusivamente contra você - e às vezes até mesmo a mudança para outra cidade ou capital não ajudará. Mesmo que você saia com rancor, não há melhor vingança do que se tornar um funcionário útil e legal de um concorrente :) E o mais importante, com total impunidade.
Você também não deveria fazer isso. Mas, como mostra a experiência, não vamos parar
Em geral, amigos, leiam os conselhos, mas façam o que acharem melhor - afinal, verdadeiras descobertas são feitas quando duvidamos de verdades já descobertas. Feliz Ano Novo, que seus projetos sejam bem-sucedidos, que sua carreira seja agradável, que seus colegas e gestores sejam adequados e que sua vida em geral seja bem-sucedida. Em geral, um brinde ao Ano Novo e ao novo código!
Com amor,
Equipe do RegionSoft Developer Studio
No novo ano continuaremos a trabalhar para você e desenvolveremos um poderoso sistema de CRM para desktop e um sistema de help desk e tickets simples e conveniente .
Fonte: habr.com