O que um especialista em TI não deve fazer em 2020?

Habr está cheio de previsões e conselhos sobre o que fazer no próximo ano - que idiomas aprender, em quais áreas reduzir, como lidar com sua saúde. Parece inspirador! Mas qualquer moeda tem dois lados, e tropeçamos não apenas em algo novo, mas na maior parte do que fazemos todos os dias. “Bem, por que ninguém me avisou!”, Exclamamos irritadamente, geralmente voltando-se para nós mesmos. Causamos fogo em nós mesmos - compilamos para você uma lista do que NÃO vale a pena fazer em 2020 (e talvez sempre).


E a gravidade não foi perguntada.

Gostaríamos muito de organizar as anti-recomendações em ordem, das mais importantes às mais insignificantes. Mas eles são tão difundidos, equivalentes e familiares a quase todos que escreveremos separadamente. Bem, verifique a lista?

Não há necessidade de ir para a TI se tudo estiver bem

Não aprenda novas tecnologias para mudar de profissão ou começar do zero. Nosso tempo é maravilhoso, pois você pode estudar, mudar de emprego, mudar fundamentalmente a esfera - e até mesmo até a aposentadoria. Isso é uma coisa legal e sedutora. Mas se você tem mais de 28 a 30 anos, não deve descartar tudo para entrar na TI ou sair para uma nova pilha (por exemplo, você escreve sistemas altamente carregados em Java e, de repente, decide sair em uma rede neural em Python). O motivo é simples: não será fácil para você. Em primeiro lugar, há uma alta concorrência de especialistas que estão nessa pilha desde o início de suas carreiras; em segundo lugar, você terá que se tornar um júnior com um salário baixo e, em terceiro lugar, será moralmente difícil se tornar subordinado ao nível mais baixo da hierarquia. Portanto, se você quiser avançar na outra direção, tente fazer isso de acordo com o trabalho atual e as tarefas atuais ou desenvolva novos conhecimentos como hobby, arquive um projeto de estimação para chegar a um novo emprego que não seja mais um júnior.

Mudar pilha para pilha - apenas o tempo a perder

Não corra entre as pilhas de tecnologia para o seu desenvolvimento. Se você escreve um projeto em um idioma, usa uma estrutura e bibliotecas específicas, não deve jogar tudo no inferno e reescrever no Dart, apenas porque lhe pareceu interessante. Estabeleça uma regra para encontrar uma justificativa para a mudança de tecnologia - não apenas no nível de querer não poder, mas também nos níveis financeiro e de engenharia.

Não há necessidade de manter sua posição e bronze

Descansar em um idioma ou tecnologia e não aprender um novo é o mesmo extremo que mudar a pilha com cada nova tecnologia. Certifique-se de estudar novas bibliotecas e estruturas, não seja teimoso no conhecimento de que tudo é melhor pensado em você e dopado exclusivamente por você. Para quase todos os idiomas, as atualizações são lançadas constantemente, o que às vezes pode melhorar bastante o seu projeto. Não tenha preguiça de seguir a dinâmica da sua pilha e, assim que encontrar algo interessante e útil, sinta-se à vontade para arrastar para o projeto!

Sua cabeça é boa, sempre boa

Não pense com a cabeça de outras pessoas, a sua é melhor. Infelizmente, alguns desenvolvedores estão esperando que recebam a tarefa de codificar do erro anterior até o fim, sem tentar introduzir algo próprio no projeto, desenvolver uma nova função, testá-la e oferecê-la na produção. Por que se preocupar quando há o chefe de um líder de equipe ou de empresa que decide tudo sozinho? Se você se reconhece, temos más notícias: uma posição passiva não ajudará na carreira nem no desenvolvimento. Você tem a chance de tentar um engenheiro de desenvolvimento, não um codificador, em um projeto de combate real e entender para onde se mover, o que está faltando, mas você prefere gastar seu tempo em outra coisa e fazer exatamente "a partir de agora". Tal na TI moderna sobrevive cada vez mais, sai da animação suspensa.

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 o programa encontre um equívoco impenetrável. Nos primeiros dias ou semanas, o usuário odiará o seu software, porque "o antigo não era tão estúpido". Para evitar isso, faça alguns documentos legais e materiais de treinamento. Ao instalar ou comprar, é muito intrusivo sugerir que os manuais devem ser lidos antes de você começar a trabalhar com o programa, e não após a falha do banco de dados, perda de senha e autocontrole.



Também não subestime os usuários: eles são mais espertos, inteligentes e curiosos do que você pensa. Se você acha que esse bug com o formato da variável e executado no 138º pressionamento de Enter com um intervalo de segundo não aparecerá, você está enganado - eles aparecerão e afetarão a operação do seu aplicativo da maneira mais bizarra. A regra amadora funciona: é ele quem lida melhor com os testes. Mas, por alguma razão, os usuários não gostam de encontrar erros na produção - não há solidariedade neles. Em geral, quanto mais confiante você estiver em seu software, melhor. No final, é melhor adiar o lançamento de alguns recursos do que adicioná-los a um aplicativo em execução e torná-lo repentino.

Pare de pesquisar no Google!

Pare de acessar o Google sozinho. Nem sequer discutiremos - no campo do desenvolvimento, uma solicitação direta ao mecanismo de pesquisa pode encontrar muito. Quanto mais você se aprofundar na busca de informações, mais dados secundários você obterá e aprenderá mais, porque aprenderá algo novo, não relacionado à sua solicitação, mas provavelmente necessário no futuro. Volte para materiais completos, livros, artigos, etc. Os idiomas e as bibliotecas têm especificações, uma comunidade, como, e assim você obtém a maneira mais confiável de desenvolver as habilidades do programador - basta ler a documentação e não procurar soluções locais e trechos de código de outras pessoas. E se a sua decisão for melhor, mais rápida e mais fria?

Confie, mas verifique

Não use bibliotecas e estruturas criadas por desenvolvedores de terceiros sem verificar o código ou adaptá-lo para seus próprios fins. Você não tem motivos para confiar incondicionalmente neste autor de código que você não conhece. Sim, vários elementos maliciosos intencionais no código de terceiros não são tão comuns e a paranóia não vale a pena sofrer, mas a cópia cega de partes finalizadas do software em seu projeto pode levar a consequências imprevisíveis. Portanto, não deixe de ler e analisar o código antes de usar e realizar 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 em que seu projeto está hospedado. Pense em conselhos engraçados e vaidosos? Mas mais de 700 participantes de bate-papo no Telegram que caíram em uma situação desagradável recente com a parada de um conhecido data center não pensavam assim - o que não estava lá: desde projetos para animais de estimação a grandes sites do estado. órgãos e bases corporativas 1C e cobrança. Uma parte significativa - sem backups ou backups no mesmo local. Portanto, distribua os riscos e armazene o backup pelo menos na hospedagem principal, em alguns VDS confiáveis ​​e no servidor local. No final, sairá muito mais barato.

Pare de trazer o seu próprio em detrimento do projeto

Não faça o que deseja em um rascunho de trabalho, mas faça o que os clientes precisam. Sim, é incrivelmente interessante e legal 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, será um excesso caro. Veja como o projeto funciona, leia a documentação, leia análises e aplicativos dos clientes e implemente o que dará valor ao negócio do projeto. Se você deseja criar algo científico ou super complicado, comece com seu próprio projeto.

Não é um código, mas um feixe de nervos

Não escreva código ilegível e não documentado. Estamos familiarizados com esse recurso: o desenvolvedor escreve o código como Deus o coloca na alma, o confunde deliberadamente um pouco para que nenhum dos colegas possa descobrir o que está escrito - uma vingança preventiva tão peculiar antes que algo aconteça. No entanto, você corre o risco não apenas da empresa (que paga o dinheiro pelo trabalho), mas também de si mesmo: é provável que você não se lembre do que queria dizer com essa ofuscação não intencional. A mesma coisa com o código não documentado: confiando na sua lógica para nomear variáveis ​​e funções e boa memória, depois de alguns anos você pode não se lembrar por que escolheu esse loop, método, padrão etc. Documentar o código e sua boa estrutura é um serviço interessante para colegas, empregador e, acima de tudo, para si mesmo.

Seja simples, estúpido

Não complique o código, decisões e projetos. Não é necessário cercar uma estrutura complexa e produzir entidades sem significado especial. Quanto mais complexo seu código, mais você se torna refém - será extremamente difícil mantê-lo e desenvolvê-lo. Obviamente, o famoso princípio KISS (“seja simples, burro”) nem sempre é adequado, mas não foi criado em vão: a simplicidade e a elegância do código são a chave para sua aplicação e reutilização bem-sucedidas.

Cuidado

Não ignore a segurança - em 2020 é literalmente criminal. Mesmo que sua empresa, desenvolvimento e você não estejam interessados ​​em invasores, você pode ser afetado por problemas associados à derrota de um segmento de rede, provedor de hospedagem, ataque a um data center, roubo de senhas de e-mail e comportamento inseguro de funcionários que poderiam roubar dados da empresa, retirar clientes ou o código do programa de todo o projeto. Se estiver ao seu alcance e pertencer à área de competência, tente proteger os projetos com os quais trabalha. Bem, observe você mesmo a segurança das informações, isso não incomodou ninguém.

Não cuspa no poço

Não leia seu empregador. Até o momento, as comunicações atingiram um nível que, por exemplo, todos os RHs da cidade estão familiarizados um com o outro à revelia e podem trocar informações em salas de bate-papo e grupos privados (como ajudar a encontrar um emprego e escrever "Vasily Ivanov, arquiteto de sistema, matou tudo antes de sair contas, apagou backups e desconectou a rede, a recuperação levou 3 dias. Não leve para o trabalho "). Assim, seu comportamento jogará exclusivamente contra você - e às vezes até a mudança para outra cidade ou capital não ajudará. Mesmo se você sair com ressentimento, não há melhor vingança do que se tornar um funcionário útil e legal de um concorrente :-) E o mais importante, completamente com impunidade.


Também não vale a pena fazer isso. Mas, como mostra a experiência, não vamos parar

Em geral, amigos, leia as dicas, mas faça o que achar melhor - porque descobertas reais são feitas quando duvidamos das verdades que já foram descobertas. Feliz Ano Novo, deixe seus projetos serem bem-sucedidos, uma carreira não chata, colegas e gerentes adequados e a vida como um todo bem-sucedida. Em geral, para o ano novo e para o novo código!

Com amor
Equipe do RegionSoft Developer Studio

No novo ano, continuaremos a trabalhar para você e a desenvolver o poderoso sistema de CRM para desktop RegionSoft CRM e o simples e conveniente suporte técnico e sistema de tickets da ZEDLine .