Saudações a todos os estudantes e profissionais Java. Talvez minha história seja um exemplo para alguns de como fazer isso e para outros de como não fazer. É dia 19 de outubro de 2021 e hoje completei um período probatório (3 meses) como desenvolvedor Java middle em uma grande empresa. Eu não tinha experiência anterior em desenvolvimento Java. Até 4 de junho de 2020, eu não sabia nada sobre Java. Quando fui contratado como Javaísta, prometi que se passasse no período de estágio, escreveria uma história de sucesso. Este artigo será dividido em duas partes lógicas: Histórico de carreira (
capítulos 1-5, não relacionados a Java, mas no qual você pode adquirir conhecimento sobre sua carreira). Tornando-se um Javaísta (capítulos 6 a 9 - aprendendo Java, entrevistas, conseguindo um emprego, primeira experiência real). <h3>Capítulo 1. Economista</h3>Para entender com que nível de conhecimento cheguei ao JavaRush, preciso fazer uma nota biográfica sobre mim. 2013, novembro, 8h. Estou sentado em uma cafeteria em Taganka e repetindo instruções SQL. Em uma hora tenho uma entrevista para o cargo de economista líder do departamento financeiro do banco. Esta é a única entrevista para a qual fui convidado e preciso dar 100%. Por causa dele, voei de São Petersburgo e fiquei com parentes na cozinha, para não gastar minhas já pequenas economias. Passam-se 30 minutos, as panquecas com presunto e queijo são comidas e precisamos avançar em direção ao nosso sonho acalentado. Mas tudo está tremendo. E se eu falhar na entrevista? Ok, não foi. Vou ao banco, pego um passe e espero meus entrevistados na sala de reuniões. O tempo passa por muito tempo. Entra um homem de cerca de 35 anos e uma mulher da mesma idade. Eles se apresentam e pedem para falar sobre si mesmos: “Yuri, é um prazer”. Tenho 21 anos, estudo meio período em uma universidade em São Petersburgo, trabalhei 3 meses como caixa de banco. Percebi que não foi para isso que estudei, comecei a olhar o mercado de trabalho e vi que em Moscou os economistas têm o SQL como requisito. Então eu estudei, fiz cursos (Administração MS SQL - era isso que eu tinha, era isso que eu buscava), e vocês me ligaram. Eles falam sobre a empresa, o que fazem (a maioria das palavras são incompreensíveis) e depois pedem para você fazer um teste. O teste tem 3 questões sobre SQL: 1. Dada uma tabela, retire todos os registros com id = 10. 2. Dadas duas tabelas, conecte-as e exiba uma coluna de cada uma. 3. Agrupe os departamentos e indique o número de funcionários de cada departamento. É com muita vergonha que escrevo estes pedidos. Isto é seguido por uma discussão sobre minhas expectativas em relação ao trabalho. E eles me dizem a frase mágica: “Obrigado pela entrevista, ligaremos de volta”. Uma semana se passa e eles me oferecem para trabalhar com eles. Euforia, choque, alegria! E por quanto dinheiro: 70 mil rublos em mãos! Sim, serei rico! Venho para Moscou, me acomodo, alugo um quarto no centro. Os primeiros dias são eufóricos. Após 10 dias, começa a constatação: onde eu vim? Eu não entendo nada! Eu tinha que preparar relatórios gerenciais para todo o banco todos os meses. Naturalmente, para mim foi o mesmo que para você, caro leitor. Percebi os termos crédito interbancário, swaps, alocação de despesas, custos, etc. como escritos em latim. Ao longo do caminho, tive que dominar o lado técnico da questão: MS Access (todos os relatórios eram feitos lá através de VBA), MS SQL (como um novo armazenamento, em vez de Access), Oracle (que inicialmente chamei de Oracle, causando histeria entre programadores). E de repente começo a entender que o lado técnico me interessa muito mais. Há tentativas de criar consultas complexas (como resultado, o banco de dados trava em meus scripts e administradores furiosos correm por aí tentando descobrir quem fez isso). Mas o trabalho principal é financeiro, o que começa a me irritar. Depois de um mês e meio, estou escrevendo uma carta de demissão, pois não posso dar nenhum resultado (e eles realmente não esperavam nada de mim, para ser sincero). O chefe do departamento financeiro rasga e diz: “não se preocupe com porcarias”. Um mês depois, escrevo novamente um comunicado, e o chefe do departamento, que ficou chocado com tal atrevimento (que mais tarde se tornou presidente do conselho do banco), sinaliza com extremo espanto: o cara tem 21 anos, sem superior educação, eles receberam salário e confiança, mas ele se comporta assim. Os motivos da demissão foram mais dois fatores: o patrão, a cuja arrogância não consegui reagir com calma, e a cadeira desconfortável, onde minhas costas começaram a doer. Isso é incrivelmente engraçado, mas aqui está o motivo. Quando parei, pensei que agora ficaria ainda mais confortável. Mas não estava lá. <h3>Capítulo 2. 70 entrevistas</h3>Saindo do banco, respirei fundo. “Vou organizar desta forma, todos ficarão surpresos.” As entrevistas foram agendadas, os salários para eles eram mais altos e parecia que não haveria necessidade de fazer reportagens. São 4 entrevistas e ninguém me contrata. 5, 6 entrevistas são a mesma coisa. Eu morava com uma menina em um quarto alugado, ela conseguiu um emprego e pôde suprir minha falta de renda. Mas eu ainda não tinha ideia de quanto tempo não teria renda. Fui a entrevistas (vagas a la analista), e perguntaram principalmente sobre SQL e VBA. Para quem não sabe, VBA é uma linguagem de programação em Excel, Access e outros produtos MS Office. São realizadas 10 entrevistas - nada. 20, 30 - nada. Todo mundo fica constrangido com a falta de experiência e formação superior (o que me parece uma coisa pequena). 40 entrevistas e o desespero começa a surgir. Durante o período de 55-60 entrevistas começo a estudar 1C. A menina, que já se casou, pede para ir para São Petersburgo, pois pelo menos lá tem casa própria. E na 70ª entrevista, fui convidado para ser administrador de banco de dados 1C (com perspectiva de me tornar um desenvolvedor 1C) em uma pequena empresa na zona industrial de São Petersburgo por 50.000 rublos. Agora isso é crescimento na carreira! <h3>Capítulo 3. O Retorno da Lenda</h3>Olhando pela janela de um microônibus (transporte corporativo) na cinzenta zona industrial de São Petersburgo, e viajando uma hora e quarenta em um sentido, percebi que não poderia viva assim. O interesse em 1C desapareceu ao primeiro toque no sistema escrito por ele mesmo. Era necessário um plano. E amadureceu: à noite estudava SQL e ao mesmo tempo monitorava o conhecido canteiro de obras. O gatilho final para a demissão foi a situação: o diretor-geral não queria me deixar sair de férias planejadas, embora as passagens já tivessem sido adquiridas. Depois das férias, escrevo uma inscrição e envio novamente meu currículo para vagas em Moscou. Mais uma vez me oferecem uma entrevista em um grande banco no horário de Moscou. Novamente venho à cozinha dos meus parentes e vou para uma entrevista. Quando hr escreveu o endereço, não pude acreditar no que via - este era o prédio em que eu sonhava em trabalhar (na época da minha última residência em Moscou, ele estava em construção). O cargo foi denominado especialista-chefe de suporte a sistemas de informação. eu vou para o escritório Sou recebido por um homem de cerca de 30 anos, vestindo uma jaqueta elegante e jeans. Subimos até o 15º andar e, quando vi o panorama da cidade, fiquei sem fôlego: todos os arranha-céus stalinistas eram visíveis. Todo o estilo do prédio era muito moderno: no escritório do patrão havia adegas refrigeradas, aquários da moda, uma pintura de uma mulher nua em estilo preto e branco. Isso causou um efeito “uau”. A conversa com o patrão não aconteceu como de costume: durante cerca de 40 minutos ele falou sobre o que estava acontecendo no banco. Eu não entendi nada, mas balancei a cabeça. Quando perguntei: quando você vai começar a me perguntar? Ele não estava prestando atenção. Mais uma vez, à minha pergunta “quando é a entrevista técnica?”, a resposta foi “sim, vamos contratá-lo mesmo assim, se você não aguentar, vamos demiti-lo”. Foi dito com um sorriso, e percebi que tudo, o sonho havia se tornado realidade novamente! <h3>Capítulo 4. Encontrando-se em TI </h3>Quando cheguei ao novo local, entendi imediatamente por que me contrataram. Descreverei um retrato típico de um funcionário do departamento: idade média de 55 anos, moscovita, educação na Universidade Estadual de Moscou, trabalho em um instituto de pesquisa de defesa na época soviética e transição para o setor bancário nos anos 90, trabalha aqui há 20 anos. Metade são homens, metade são mulheres. Eles entraram em completa dissonância com os interiores circundantes. Estávamos envolvidos na manutenção de programas de relatórios para contabilidade. Naturalmente, tudo isso estava em antigos scripts VBA e SQL escritos por desenvolvedores no final dos anos 90 e início dos anos 2000. Era 2015 e a automação era através do MS Access. Ou seja, parecia extremamente pobre. Mas havia uma nuance - eles forneciam o que o cliente (contabilidade) queria. E exatamente na hora certa e na forma exigida. Só eles sabiam como funcionava, e mesmo Onotole não conseguia imaginar a complexidade dos seus desenvolvimentos. E qualquer gerente de TI, mesmo com a maior vontade, não poderia demiti-los - o contador-chefe ia à diretoria do banco e defendia qualquer funcionário que atendesse aos interesses do departamento de contabilidade. O gerente queria que eu fizesse o papel de um cavalo de Tróia: estudei todos os seus desenvolvimentos e depois migrei os dados para o novo sistema. Então os antigos funcionários podem ser demitidos e eu posso ser transferido para um novo sistema. Primeiro, mergulhei em seus processos e observei o código VBA. Gradualmente aprendi a ler código VBA. Um ano depois eu já sabia escrever o código sozinho. Tarefa típica: dado um banco de dados, extrair dados dele e colocá-los no Excel em um determinado formato. Agora, como disse Zadornov, respire fundo: todos os relatórios do departamento (e são 50 relatórios diários e 20 mensais!) Foram executados manualmente! Karl, você entende que as pessoas mudam as datas para +1 todos os dias com as mãos em 50 relatórios! Eles sentam, aguardam o resultado de um relatório por 1 a 10 minutos e lançam outro! Além disso, os relatórios diários devem ser lançados em um determinado horário, e Deus não permita que você se atrase! Eles não apenas fazem relatórios, mas também executam procedimentos manualmente no banco de dados sem usar variáveis! Ou seja, ao invés de usar a variável @startDate = '2015-01-01', eles vão alterar a mesma data manualmente em 20 lugares! Depois de ver tudo isso, comecei a aprender Python, e junto com VBA, SQL e agendador de tarefas, automatizei tudo isso em dois anos. Não apenas automatizou, mas também acelerou muitos relatórios: se você abandonar o MS Access + VBA em favor do MS SQL + TSQL, poderá obter um aumento múltiplo na produtividade. Meu recorde está acelerando a criação de relatórios em
100uma vez! Mas meus colegas ficaram extremamente insatisfeitos com essa automação, então fui declarado inimigo do povo (eles queriam ficar quietos até a aposentadoria). O tempo passou e a migração dos dados foi bem-sucedida. O gerente me valorizava muito: se no início da minha carreira eu chegava ao trabalho às 8h, depois de um tempo eu poderia chegar a qualquer hora até as 12h, aumento constante de salário e cargo, pagamento pelo trabalho nos finais de semana mais do que o dobro do valor, táxi para casa se chegar atrasado no trabalho, comunicações móveis, enfim - a elite! <h3>Capítulo 5. A Gaiola Dourada</h3>De repente, depois de 3,5 anos, um novo gerenciamento de TI chega e diz que o sistema para o qual migrei os dados não é mais necessário. Mas o antigo sistema permanecerá. Meu gerente está subindo na carreira e me convida para mudar para um departamento mais progressista. Em reunião com o chefe do departamento progressista, entendo que a pilha de tecnologia deste departamento é desconhecida para mim: Oracle, .net, C#, Linux, etc. + Antipatia pelo potencial chefe. Digo ao meu gerente que não estou interessado no departamento progressista e ele convenientemente se esquece de mim. E então a questão é: o que fazer a seguir? A renda já era decente, o desenvolvedor Junior não me contrataria por esse salário. Depois de pensar sobre minhas habilidades, percebi que precisava entrar no aprendizado de máquina. Tudo foi interessante até o primeiro encontro com a estatística matemática, o que só causou desgosto no instituto. É isso, estupor por seis meses! O tempo passou e um dia, enquanto caminhava, pensei em um site que exibisse bons restaurantes no mapa de Moscou. Comecei a aprender HTML, CSS, JS. Passei 3 meses estudando; não tinha conhecimento para criar um site completo, mas poderia praticar no trabalho. Nasceu uma ideia: criar um portal para contadores para que eles pudessem baixar qualquer relatório por meio de um botão. Demorou 2 meses para criar o portal, e a aplicação web SPA (aplicativo de página única) nasceu em React js com backend Node.js. Executei scripts SQL (eu não conhecia frameworks como Hibernate), lancei Python e armazenei informações adicionais no MongoDb (por exemplo, sobre usuários do site). Externamente, o site parecia muito decente (bootstrap 4, animação da moda). Ainda estou orgulhoso deste projeto. Mas quando mostrei meu código aos desenvolvedores web do banco, eles ficaram surpresos. NÃO É UMA CLASSE PRÓPRIA! Apenas recursos, apenas hardcore! Eles me elogiaram, mas disseram que ainda preciso estudar muito para me tornar um desenvolvedor middle full stack. Tentei conseguir um emprego como analista, mas não houve ofertas especiais. Eu penso: não estava lá, vou postar meu currículo de desenvolvedor full stack. As ligações chegaram, mas durante as entrevistas eu voei como madeira compensada sobre Paris: por exemplo, eu não sabia o que eram HashMap, HashSet e por que eram necessários. Não havia a menor ideia sobre OOP, padrões de programação, algoritmos, testes, Git. Lembrei-me de sentimentos de vergonha há muito esquecidos pela ignorância de coisas básicas. De repente, surge uma oferta para um emprego como chefe de análise de clientes em uma empresa financeira. Uma semana antes do país fechar devido à pandemia. Consegui emprego em uma empresa financeira, mas havia um sentimento duplo: por um lado, o salário alto era quente, por outro, haveria um desenvolvimento mínimo na parte técnica. Uma semana se passou depois que o dispositivo foi instalado e o trabalho remoto foi introduzido. Como os dias não úteis não se aplicavam ao setor financeiro, trabalhámos normalmente. O novo chefe revelou-se uma pessoa muito maluca: ofereceu-se para raspar o Facebook, criar suas próprias redes neurais para estudar clientes (sem um cientista de dados na equipe). Novos funcionários foram oferecidos para aprender Python em uma semana, etc. Dias de folga não remunerados tornaram-se a norma. Foi estúpido pedir demissão: onde você conseguirá um emprego durante uma pandemia? Mas a paciência acabou depois de 2 meses, quando foi anunciado que não haveria bônus trimestrais. A nuance é que quando combinamos o salário, na hora da contratação, o RH disse que o salário é dividido em salário (60%) e bônus trimestral (40%), que é sempre pago. Ficou claro que a escolha errada havia sido feita e que precisávamos começar a procurar um novo emprego. <h3>Capítulo 6. Começando a dominar Java</h3>Um belo dia de maio recebo um convite para uma entrevista para a vaga “Desenvolvedor”. Uma empresa do setor de seguros precisa de uma pessoa que desenvolva produtos de seguros. É necessária experiência em programação, mas por se tratar de um desenvolvimento “único” da empresa, não há necessidade de uma linguagem específica. Git e assim por diante também são necessários. Marquei uma entrevista para dois dias e estudei o básico do Git nas horas vagas. Durante a entrevista, fui questionado sobre Python, JS, Git, SQL. Respondi tudo menos o conceito de “sobrecarga de métodos”, e fui convidado para trabalhar em 2 semanas. Acontece que a empresa comprou o sistema há muito tempo. escrito em Java (frente e verso), com o qual você pode criar processos de negócios sem conhecer uma linguagem de programação (mais precisamente, usando a linguagem de programação Jelly integrada). Parece bom, mas na verdade tudo estava distorcido. Digressão lírica: qualquer tecnologia tem sua época e sua escala. Fazer todos os relatórios de 2000 apenas no Excel é legal. Fazer a mesma coisa em 2021 não é muito bom. Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar por outro lado, haverá um desenvolvimento mínimo no lado técnico. Uma semana se passou depois que o dispositivo foi instalado e o trabalho remoto foi introduzido. Como os dias não úteis não se aplicavam ao setor financeiro, trabalhámos normalmente. O novo chefe revelou-se uma pessoa muito maluca: ofereceu-se para raspar o Facebook, criar suas próprias redes neurais para estudar clientes (sem um cientista de dados na equipe). Novos funcionários foram oferecidos para aprender Python em uma semana, etc. Dias de folga não remunerados tornaram-se a norma. Foi estúpido pedir demissão: onde você conseguirá um emprego durante uma pandemia? Mas a paciência acabou depois de 2 meses, quando foi anunciado que não haveria bônus trimestrais. A nuance é que quando combinamos o salário, na hora da contratação, o RH disse que o salário é dividido em salário (60%) e bônus trimestral (40%), que é sempre pago. Ficou claro que a escolha errada havia sido feita e que precisávamos começar a procurar um novo emprego. <h3>Capítulo 6. Começando a dominar Java</h3>Um belo dia de maio recebo um convite para uma entrevista para a vaga “Desenvolvedor”. Uma empresa do setor de seguros precisa de uma pessoa que desenvolva produtos de seguros. É necessária experiência em programação, mas por se tratar de um desenvolvimento “único” da empresa, não há necessidade de uma linguagem específica. Git e assim por diante também são necessários. Marquei uma entrevista para dois dias e estudei o básico do Git nas horas vagas. Durante a entrevista, fui questionado sobre Python, JS, Git, SQL. Respondi tudo menos o conceito de “sobrecarga de métodos”, e fui convidado para trabalhar em 2 semanas. Acontece que a empresa comprou o sistema há muito tempo. escrito em Java (frente e verso), com o qual você pode criar processos de negócios sem conhecer uma linguagem de programação (mais precisamente, usando a linguagem de programação Jelly integrada). Parece bom, mas na verdade tudo estava distorcido. Digressão lírica: qualquer tecnologia tem sua época e sua escala. Fazer todos os relatórios de 2000 apenas no Excel é legal. Fazer a mesma coisa em 2021 não é muito bom. Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar por outro lado, haverá um desenvolvimento mínimo no lado técnico. Uma semana se passou depois que o dispositivo foi instalado e o trabalho remoto foi introduzido. Como os dias não úteis não se aplicavam ao setor financeiro, trabalhámos normalmente. O novo chefe revelou-se uma pessoa muito maluca: ofereceu-se para raspar o Facebook, criar suas próprias redes neurais para estudar clientes (sem um cientista de dados na equipe). Novos funcionários foram oferecidos para aprender Python em uma semana, etc. Dias de folga não remunerados tornaram-se a norma. Foi estúpido pedir demissão: onde você conseguirá um emprego durante uma pandemia? Mas a paciência acabou depois de 2 meses, quando foi anunciado que não haveria bônus trimestrais. A nuance é que quando combinamos o salário, na hora da contratação, o RH disse que o salário é dividido em salário (60%) e bônus trimestral (40%), que é sempre pago. Ficou claro que a escolha errada havia sido feita e que precisávamos começar a procurar um novo emprego. <h3>Capítulo 6. Começando a dominar Java</h3>Um belo dia de maio recebo um convite para uma entrevista para a vaga “Desenvolvedor”. Uma empresa do setor de seguros precisa de uma pessoa que desenvolva produtos de seguros. É necessária experiência em programação, mas por se tratar de um desenvolvimento “único” da empresa, não há necessidade de uma linguagem específica. Git e assim por diante também são necessários. Marquei uma entrevista para dois dias e estudei o básico do Git nas horas vagas. Durante a entrevista, fui questionado sobre Python, JS, Git, SQL. Respondi tudo menos o conceito de “sobrecarga de métodos”, e fui convidado para trabalhar em 2 semanas. Acontece que a empresa comprou o sistema há muito tempo. escrito em Java (frente e verso), com o qual você pode criar processos de negócios sem conhecer uma linguagem de programação (mais precisamente, usando a linguagem de programação Jelly integrada). Parece bom, mas na verdade tudo estava distorcido. Digressão lírica: qualquer tecnologia tem sua época e sua escala. Fazer todos os relatórios de 2000 apenas no Excel é legal. Fazer a mesma coisa em 2021 não é muito bom. Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar crie suas próprias redes neurais para estudar clientes (sem um cientista de dados na equipe). Novos funcionários foram oferecidos para aprender Python em uma semana, etc. Dias de folga não remunerados tornaram-se a norma. Foi estúpido pedir demissão: onde você conseguirá um emprego durante uma pandemia? Mas a paciência acabou depois de 2 meses, quando foi anunciado que não haveria bônus trimestrais. A nuance é que quando combinamos o salário, na hora da contratação, o RH disse que o salário é dividido em salário (60%) e bônus trimestral (40%), que é sempre pago. Ficou claro que a escolha errada havia sido feita e que precisávamos começar a procurar um novo emprego. <h3>Capítulo 6. Começando a dominar Java</h3>Um belo dia de maio recebo um convite para uma entrevista para a vaga “Desenvolvedor”. Uma empresa do setor de seguros precisa de uma pessoa que desenvolva produtos de seguros. É necessária experiência em programação, mas por se tratar de um desenvolvimento “único” da empresa, não há necessidade de uma linguagem específica. Git e assim por diante também são necessários. Marquei uma entrevista para dois dias e estudei o básico do Git nas horas vagas. Durante a entrevista, fui questionado sobre Python, JS, Git, SQL. Respondi tudo menos o conceito de “sobrecarga de métodos”, e fui convidado para trabalhar em 2 semanas. Acontece que a empresa comprou o sistema há muito tempo. escrito em Java (frente e verso), com o qual você pode criar processos de negócios sem conhecer uma linguagem de programação (mais precisamente, usando a linguagem de programação Jelly integrada). Parece bom, mas na verdade tudo estava distorcido. Digressão lírica: qualquer tecnologia tem sua época e sua escala. Fazer todos os relatórios de 2000 apenas no Excel é legal. Fazer a mesma coisa em 2021 não é muito bom. Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar crie suas próprias redes neurais para estudar clientes (sem um cientista de dados na equipe). Novos funcionários foram oferecidos para aprender Python em uma semana, etc. Dias de folga não remunerados tornaram-se a norma. Foi estúpido pedir demissão: onde você conseguirá um emprego durante uma pandemia? Mas a paciência acabou depois de 2 meses, quando foi anunciado que não haveria bônus trimestrais. A nuance é que quando combinamos o salário, na hora da contratação, o RH disse que o salário é dividido em salário (60%) e bônus trimestral (40%), que é sempre pago. Ficou claro que a escolha errada havia sido feita e que precisávamos começar a procurar um novo emprego. <h3>Capítulo 6. Começando a dominar Java</h3>Um belo dia de maio recebo um convite para uma entrevista para a vaga “Desenvolvedor”. Uma empresa do setor de seguros precisa de uma pessoa que desenvolva produtos de seguros. É necessária experiência em programação, mas por se tratar de um desenvolvimento “único” da empresa, não há necessidade de uma linguagem específica. Git e assim por diante também são necessários. Marquei uma entrevista para dois dias e estudei o básico do Git nas horas vagas. Durante a entrevista, fui questionado sobre Python, JS, Git, SQL. Respondi tudo menos o conceito de “sobrecarga de métodos”, e fui convidado para trabalhar em 2 semanas. Acontece que a empresa comprou o sistema há muito tempo. escrito em Java (frente e verso), com o qual você pode criar processos de negócios sem conhecer uma linguagem de programação (mais precisamente, usando a linguagem de programação Jelly integrada). Parece bom, mas na verdade tudo estava distorcido. Digressão lírica: qualquer tecnologia tem sua época e sua escala. Fazer todos os relatórios de 2000 apenas no Excel é legal. Fazer a mesma coisa em 2021 não é muito bom. Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar <h3>Capítulo 6. Começando a dominar Java</h3>Um belo dia de maio recebo um convite para uma entrevista para a vaga “Desenvolvedor”. Uma empresa do setor de seguros precisa de uma pessoa que desenvolva produtos de seguros. É necessária experiência em programação, mas por se tratar de um desenvolvimento “único” da empresa, não há necessidade de uma linguagem específica. Git e assim por diante também são necessários. Marquei uma entrevista para dois dias e estudei o básico do Git nas horas vagas. Durante a entrevista, fui questionado sobre Python, JS, Git, SQL. Respondi tudo menos o conceito de “sobrecarga de métodos”, e fui convidado para trabalhar em 2 semanas. Acontece que a empresa comprou o sistema há muito tempo. escrito em Java (frente e verso), com o qual você pode criar processos de negócios sem conhecer uma linguagem de programação (mais precisamente, usando a linguagem de programação Jelly integrada). Parece bom, mas na verdade tudo estava distorcido. Digressão lírica: qualquer tecnologia tem sua época e sua escala. Fazer todos os relatórios de 2000 apenas no Excel é legal. Fazer a mesma coisa em 2021 não é muito bom. Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar <h3>Capítulo 6. Começando a dominar Java</h3>Um belo dia de maio recebo um convite para uma entrevista para a vaga “Desenvolvedor”. Uma empresa do setor de seguros precisa de uma pessoa que desenvolva produtos de seguros. É necessária experiência em programação, mas por se tratar de um desenvolvimento “único” da empresa, não há necessidade de uma linguagem específica. Git e assim por diante também são necessários. Marquei uma entrevista para dois dias e estudei o básico do Git nas horas vagas. Durante a entrevista, fui questionado sobre Python, JS, Git, SQL. Respondi tudo menos o conceito de “sobrecarga de métodos”, e fui convidado para trabalhar em 2 semanas. Acontece que a empresa comprou o sistema há muito tempo. escrito em Java (frente e verso), com o qual você pode criar processos de negócios sem conhecer uma linguagem de programação (mais precisamente, usando a linguagem de programação Jelly integrada). Parece bom, mas na verdade tudo estava distorcido. Digressão lírica: qualquer tecnologia tem sua época e sua escala. Fazer todos os relatórios de 2000 apenas no Excel é legal. Fazer a mesma coisa em 2021 não é muito bom. Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar Um site de empresa em HTML puro era legal em 1999, mas não em 2021. Então, a tecnologia que a empresa utilizava na época de sua criação (2005) era muito bacana - o Java era responsável tanto pela parte servidor quanto pela parte cliente (as chamadas páginas servlet Java). Além disso, se você criar um novo processo de negócios (que possui sua própria UI), ele será armazenado dentro do banco de dados e não no código de um arquivo. Para entender o quão inconveniente isso é, imagine que você escreve código Java na ideia do Intellij, salva-o no banco de dados e depois. quando você deseja executar seu código, o kernel do programa vai para o banco de dados e lê seu código a partir daí. Conseqüentemente, você não pode depurar totalmente seu aplicativo. Dica nº 1: quando quiser enviar código para o testbench, você precisa criar
SQL скрипт, que conterá seu código. Desagradável, mas tolerável? Entusiasmo #2: O banco de dados consiste em mais de 200 tabelas que possuem conexões entre si. Isso significa que você precisa saber em quais tabelas inserir seu código e quais entidades precisam ser criadas em outras tabelas. A saída é um script SQL com aproximadamente 1.000 linhas. Isso é realmente nojento. Cuidado com o legado. Resumindo, percebendo que era tudo em Java, fui para o JavaRush (finalmente chegamos ao tema do site!). Junho-julho de 2020. Os primeiros 10 níveis foram fechados rapidamente (talvez um mês), porque não havia nada de fundamentalmente novo. Então a velocidade diminuiu. Julho a outubro de 2020. Níveis 10-20 fechados. Outubro-março de 2021. Níveis 20-30 fechados. Agora começa a diversão: em março de 2021, comecei a olhar as vagas de Java e percebi que havia muitas palavras desconhecidas ali. Algum tipo de Spring, SpringBoot, Hibernate, JUnit. Tendo comprado videocursos em um site conhecido, acabei de tocar no Spring e pensei que agora sei e posso fazer tudo. Depois disso, me deparei com o curso TopJava de Grigory Kislin. No site dele você pode tentar realizar uma tarefa de teste e, se tiver sucesso, poderá fazer o curso. Neste curso, você cria uma aplicação web completa e até mesmo a publica na Internet. Por esse dinheiro, eles farão uma revisão (revisão do código por um programador mais experiente), darão feedback e darão dicas em caso de problemas. Cheguei ao dever de casa 3 e desisti. O motivo é simples: exigem muito de você, mas não lhe dão nenhum conhecimento. Os requisitos do dever de casa são muito confusos. As informações são apresentadas de forma extremamente inconsistente. Na minha opinião subjetiva, este curso é necessário para desenvolvedores bastante experientes que vêm de outras linguagens semelhantes. Porque em seu curso praticamente não há explicação sobre as tecnologias que ele pede para utilizar. Você também precisa conhecer bem o Git (tudo é enviado para o seu repositório pessoal). No final de abril de 2021, estou postando um currículo para desenvolvedor Java (com o salário desejado no nível médio+), no qual indico que no meu último emprego programei em Java (menti). No mesmo dia, o banco recebe a inscrição para o cargo de desenvolvedor Java. <h3>Capítulo 7. Entrevistas Java e aprimoramento de habilidades</h3>Então, qual era o plano? Preciso conseguir um bom salário, pois já estou acostumado a viver com uma renda considerável + empréstimos. Portanto, cargos juniores não são adequados para mim. Você precisa conseguir um emprego intermediário. Mas quem vai me contratar sem experiência? A decisão veio naturalmente: minha carteira de trabalho diz que trabalhei por um ano como desenvolvedor e mais 4 anos como especialista no departamento de TI em meu cargo anterior. Então, direi que estou desenvolvendo em Java há um ano. E se perguntarem sobre novos produtos, direi que o antigo Java (7) estava lá e não suportava nada. Antes da minha primeira entrevista (remota), eu estava nervoso. Não tenho experiência, tenho pouquíssimo conhecimento e estou pedindo muito dinheiro. Eu penso: não importa, experiência negativa também é experiência. Entro em contato via Skype e serei entrevistado por dois chefes de departamento. O que me deixou ainda mais assustado. As perguntas começaram: OOP, dispositivo HashMap, fluxos, estruturas de dados, o que é Spring, Hibernate, AOP. E se antes do Sping era mais ou menos tolerável, na Primavera desmoronou completamente. As pessoas me perguntam: como você se desenvolveu na primavera se você realmente não sabe disso? Eu: Copiei, colei, funciona e obrigado por isso. Esta resposta os divertiu. Aí perguntaram sobre SQL, no qual eu era como um pato na água. Em seguida veio o Git e uma pergunta sobre rebase, cherry-pick (que eu também não sabia) e finalizei sobre JS, já que estava listado no meu currículo. Lá também houve um fracasso total, porque perguntaram sobre OOP JS. Com base no resultado da entrevista, ficou claro que meu conhecimento não era comme il faut e, portanto, não me qualificaria para esta vaga. À noite, o RH escreve que minha candidatura foi aprovada e está pronto para me ligar. Na verdade, engasguei com um hambúrguer no McDonald's. Fiquei feliz, mas depois de 3 dias o RH informou que havia escolhido outro candidato. Pela primeira vez na minha experiência, uma oferta foi retirada. Após a primeira entrevista em Java, intensifiquei meu jogo: fiz um curso (e concluí completamente!) de Git da Colt Steele em um conhecido site de venda de cursos em vídeo. Isso mudou minha percepção do Git. Em seguida, fiz um curso (brilhante) de Zaur Tregulov sobre Spring+Hibernate. Esquema de treinamento: assisto como no vídeo, faço o mesmo no meu computador, mas nomeio as variáveis e classes de forma diferente para não copiar estupidamente o código de outra pessoa. Eu carrego todo o meu trabalho no meu Github (praticando Git). Era meados de maio e as ligações do RH começaram. Começamos a agendar entrevistas uma por uma. Muitos convites tiveram que ser cancelados pelos seguintes motivos: O RH não leu a descrição do meu currículo e me convidou para um cargo sênior. Também vale a pena mencionar uma casta separada de RH: aqueles que confundem Java com JavaScript. É por isso que escrevi Desenvolvedor Java Médio no título do meu currículo. <h3>Capítulo 8. Lista de perguntas típicas e como acontecem as entrevistas</h3>Comecei a ir às entrevistas e gradualmente formei um conjunto de perguntas básicas no meio. Obrigatório: 0. OOP - definição, fale sobre cada princípio de OOP (+dê um exemplo da vida real). 1. Equals e hashcode – qual é o contrato (relacionamento) entre eles? 2. HashMap - como entender em qual bucket um objeto irá entrar, o que é uma colisão, em qual estrutura de dados os dados são armazenados dentro do HashMap, o tamanho padrão, como o número de buckets aumenta. 3. Stream - quais tipos de operações, qual a diferença entre elas, dê um exemplo de cada tipo de operação. 4. Pool de strings, pool de números inteiros - o que é? 5. Pilha, pilha - o que é, qual a diferença? 6. Diferenças entre Runnable, Thread, Future. 7. Volátil, atomicidade. 8. Sólido, Beijo, Seco - definições, exemplos da vida real. 9. Modificadores de acesso em Java. 10. Qual é a diferença entre uma classe abstrata e uma interface. A interface pode ser privada? 11. Interfaces funcionais. 12. Liste todos os métodos Object e diga por que eles são necessários. Recursos do método clone. 13. O que é serialização e desserialização. 14. Tente capturar com recursos - descreva o que é, diga usando a interface Closeable. 15. Diferenças entre Final, finalmente, finalizar? 16. Sobrecarga, A substituição do método é a diferença. 17. Por que String se tornou imutável, conte-nos sobre StringBuilder e StringBuffer. 18. O que é complexidade de tempo O(1), complexidade de memória. 19. Estruturas de dados: fale sobre map, set, queue, deque, list e sua implementação em Java (treeMap, hashSet, hashMap, arrayList, linkedList, PriorityQueue, BlockingQueue), descreva a complexidade (pior, média, melhor) de inserção, pesquisa, removendo um elemento em cada estrutura. 20. Tipos de dados primitivos em Java. Por que cada um deles é necessário? 21. Tipos de erros. Exceções verificadas e não verificadas. 22. O que é JVM, JRE, JDK? 23. Com quais colecionadores você trabalhou? Maven - Ciclo de vida da construção. 24. Spring - Definições Ioc, Di, Ciclo de Vida do Bean, Contexto, Anotações @Bean, @Configuration, @Autowired, @Advice, @Aspect, @Service, @Repository. 25. Genéricos – definição do que é limite inferior e superior? 26. Padrões de programação - pelo menos Singleton (disposição para dizer por que isso às vezes é um antipadrão) + Builder, Adapter, Factory, Decorator, Proxt. Desejável: 26. Testes - tipos de testes com quais bibliotecas (JUnit) foram trabalhadas. O que é Mock, Stab, Spy? 27. Spring boot - por que é necessário, prontidão para fazer um aplicativo SpringBoot online. 28. Hibernar - por que é necessário, Entidade, coluna de junção, carregamento lento versus carregamento rápido, níveis de cache (difícil). 29. Descanso de primavera - por que é necessário, como criar endpoints @post, @get. Como ler parâmetros/corpo da solicitação? Como enviar em formato json? 30. Estruturas de dados – árvores, seus tipos. 31. Algoritmos – tipos de ordenação. Além do Java, eles podem perguntar: 1. (Obrigatório!) Git - por que é necessário, operações de mesclagem, rebase, seleção seletiva, push, pull, commit, log, checkout, ramificação, redefinição, reversão, atualização. 2.SQL - capacidade de escrever uma consulta: unir duas tabelas em uma (inner join, left join). 3. Bancos de dados - 3 formulários normais, índices (por que são necessários, tipos), chave primária, chave estrangeira Como é uma típica entrevista remota: hr envia um link para zoom (Skype, Google Meeting). A certa altura você se conecta e tem de 1 a 3 pessoas lá (especialista técnico, chefe, RH). Em casos particularmente teimosos, até 8 pessoas. Primeiro você conta sobre você, depois a parte técnica, depois uma história sobre a vaga e adeus (dizem quando entrarão em contato ou quais serão os próximos passos). Durante as despedidas, você pode pedir feedback sobre conhecimentos. Perguntei: “Você pode me dizer, durante minhas respostas, onde seus ouvidos doem?” Muitas pessoas respondem, mas esteja preparado para ser rejeitado. Durante a entrevista eles avaliam: 1. Sua capacidade de expressar pensamentos e conhecimento da língua russa (conheço um caso em que um candidato foi rejeitado devido ao pouco conhecimento da língua russa). 2. Experiência anterior (eles podem perguntar meticulosamente o que você fez em seu último emprego). 3. Uma reação adequada quando você é pressionado (houve uma entrevista em que as pessoas começaram a falar desrespeitosamente: ignorando minhas respostas, tentando incutir suas posições, etc. Terminei a entrevista 15 minutos após o início, e eles: foi uma entrevista estressante!) 4. Nível do seu conhecimento. Entrarei em mais detalhes aqui. Conhecer as definições de um tema é apenas 10% do que se espera de você. É preciso entender como funciona (pelo menos no nível superior). Disponibilidade para explicar em que ponto do desenvolvimento você escolherá esta ou aquela solução. Isto é muito mais importante do que a precisão da sua definição. Analisarei esta tese usando dois exemplos. Primeiro exemplo: durante uma entrevista fui questionado sobre o HashMap e dei a definição: “esta é uma estrutura de dados que armazena pacotes de chaves e valores”. Aí o entrevistador perguntou: qual a diferença do TreeMap? Resposta: A diferença é que o HashMap faz o hash da chave e devido ao hash, o acesso é rápido. O entrevistador imediatamente pediu para nos contar a estrutura interna do HashMap e ao mesmo tempo perguntar sobre hashCode e equals. E isso irá se aprofundar até que você esteja satisfeito com a resposta ou pare. Aprendi a responder corretamente sobre o HashMap somente após 2 meses de entrevistas e um curso sobre estruturas de dados em hexlet. Segundo exemplo: o conceito SOLID. Eles me pedem para dar uma definição que memorizei. Mas assim que se tratou de exemplos da vida real, os problemas começaram.
Внимание!Se você não sabe, não invente, mas diga o seguinte: não conheço esse assunto, mas posso presumir que funciona assim. Muitos especialistas técnicos ficam furiosos quando uma pessoa fala de heresia como se entendesse o assunto. 5. Seu nível de entusiasmo durante a discussão sobre o trabalho. Espera-se que você se interesse e faça perguntas sobre a vaga (não apenas inventadas). 6. Às vezes, o humor (apenas no tópico) e os interesses comuns ajudam você a se comunicar. Sinta-se à vontade para falar sobre seus hobbies; talvez o entrevistado também adore Dota/futebol/fantasia. E isso é uma vantagem para você como candidato. Conheço casos em que uma comunidade de interesses fez vista grossa ao fraco treinamento técnico do entrevistador (Você é um cara normal, nós vamos treiná-lo). <h3>Capítulo 9. Conseguir um emprego, batismo de fogo</h3>As entrevistas ocorreram do final de abril até meados de julho. As primeiras entrevistas foram embaraçosas, mas gradualmente a situação melhorou para um nível aceitável. Estudar perguntas comuns e comentários se fizeram sentir. As primeiras 25 entrevistas não tiveram sucesso. Depois disso, começaram os momentos de desespero. Sentimentos: e se não me contratarem por esse salário? De repente, as coisas começaram a disparar: no espaço de uma semana, três empresas apresentaram propostas. Escolhi uma empresa cujas especificidades eu conhecia, além de ter um bom salário e a oportunidade de trabalhar remotamente. Durante minha entrevista, foram feitas cerca de 30 perguntas sobre o núcleo Java e Spring, 97% das quais respondi corretamente. Depois disso houve comunicação com autoridades superiores e após 1,5 semanas consegui um emprego com eles. Em primeiro lugar, quando você chega a qualquer trabalho, você começa a ter acesso a todos os sistemas necessários e a instalar as ferramentas necessárias. Demorou uma semana e meia e recebi a primeira tarefa: mudar o texto estático da sala de aula. Quando abri o projeto, passei mal: eram muitos módulos dentro de um projeto, muitas aulas, testes, etc. Nesse ponto eu estava perdido, mas um segundo desenvolvedor me ajudou e me atualizou. O bug foi corrigido em 10 minutos, publicado no Git, um pull request foi feito (uma solicitação para mesclar duas ramificações onde outros desenvolvedores verificam seu código) e depois mesclado na ramificação principal. Acontece que nem tudo é tão difícil. Até a primeira tarefa completa... Na hora de planejar as tarefas para as próximas duas semanas, me disseram: você fará a integração com outro sistema, que está localizado no OpenShift. Foi aí que as coisas ficaram realmente assustadoras: OpenShift é um conjunto completo de tecnologias: Docker, Kubernetes, Linux e assim por diante. O suor frio escorria pelas minhas costas: bem, eu trabalhava como jawista. Imediatamente após a reunião liguei para o desenvolvedor, que me tranquilizou: os adaptadores para este sistema haviam sido escritos e bastava importar determinadas classes para o meu projeto, após o que pude utilizar a integração com segurança. Foi divertido de novo, até que o desenvolvedor mostrou uma integração típica: vi mais de 20 classes criadas para integração semelhante. Além disso, anotações inéditas @Value, @Builder, @NoArgsConstructor, @Getter, foram notadas @Sl4f - acabou sendo o projeto Lombook (leia na Internet). Quando o desenvolvedor me explicou como fazer isso, tentei anotar as conexões de todas as classes e nada ficou na minha cabeça. O momento mais constrangedor foi a falta de conhecimento do Intellij Idea: como pesquisar globalmente um projeto, refatoração de código, etc. Depois de assumir a tarefa, entendi porque a OOP é necessária: para uma quantidade tão grande de código é necessário dividi-lo em classes; métodos que não são usados fora da classe devem ser declarados privados para não serem executados acidentalmente em outra classe, etc. Depois de escrever minha integração por analogia com outra integração, aprendi sobre a existência do CheckStyle - um plugin especial que verifica o estilo do seu código e você não poderá compilar seu projeto até corrigir erros (por exemplo, espaços extras, nomes de variáveis com letras maiúsculas, nomes de variáveis muito curtos). Depois de derrotar o CheckStyle, enviei meu código para revisão aos desenvolvedores seniores e corrigi meus erros em uma semana. No geral, tive muita sorte de ter um bom relacionamento na minha equipe com o segundo desenvolvedor, que explicou muitas coisas. Um mês depois do aparelho, minha primeira integração foi lançada no estande Integração-Funcional (é testado o funcionamento de todos os aplicativos juntos), e tudo funcionou lá! Vitória! A próxima tarefa foi criar uma classe que permitisse ocultar dados por chave em JSON. Por exemplo: existe json {text:"JavaRush"} -> processamento -> {text:"****Rush"}. Há duas complicações aqui: pode haver aninhamento {text:{mytext:"JavaRush"}}, e o que é mais desagradável é aninhamento dentro do array: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush"}, {mytext: "JavaRush"} "} ] } (é claro que você precisa ocultar todo o text.mytext). Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil. Tentei anotar as conexões de todas as classes e nada ficou na minha cabeça. O momento mais constrangedor foi a falta de conhecimento do Intellij Idea: como pesquisar globalmente um projeto, refatoração de código, etc. Depois de assumir a tarefa, entendi porque a OOP é necessária: para uma quantidade tão grande de código é necessário dividi-lo em classes; métodos que não são usados fora da classe devem ser declarados privados para não serem executados acidentalmente em outra classe, etc. Depois de escrever minha integração por analogia com outra integração, aprendi sobre a existência do CheckStyle - um plugin especial que verifica o estilo do seu código e você não poderá compilar seu projeto até corrigir erros (por exemplo, espaços extras, nomes de variáveis com letras maiúsculas, nomes de variáveis muito curtos). Depois de derrotar o CheckStyle, enviei meu código para revisão aos desenvolvedores seniores e corrigi meus erros em uma semana. No geral, tive muita sorte de ter um bom relacionamento na minha equipe com o segundo desenvolvedor, que explicou muitas coisas. Um mês depois do aparelho, minha primeira integração foi lançada no estande Integração-Funcional (é testado o funcionamento de todos os aplicativos juntos), e tudo funcionou lá! Vitória! A próxima tarefa foi criar uma classe que permitisse ocultar dados por chave em JSON. Por exemplo: existe json {text:"JavaRush"} -> processamento -> {text:"****Rush"}. Há duas complicações aqui: pode haver aninhamento {text:{mytext:"JavaRush"}}, e o que é mais desagradável é aninhamento dentro do array: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush"}, {mytext: "JavaRush"} "} ] } (é claro que você precisa ocultar todo o text.mytext). Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil. Tentei anotar as conexões de todas as classes e nada ficou na minha cabeça. O momento mais constrangedor foi a falta de conhecimento do Intellij Idea: como pesquisar globalmente um projeto, refatoração de código, etc. Depois de assumir a tarefa, entendi porque a OOP é necessária: para uma quantidade tão grande de código é necessário dividi-lo em classes; métodos que não são usados fora da classe devem ser declarados privados para não serem executados acidentalmente em outra classe, etc. Depois de escrever minha integração por analogia com outra integração, aprendi sobre a existência do CheckStyle - um plugin especial que verifica o estilo do seu código e você não poderá compilar seu projeto até corrigir erros (por exemplo, espaços extras, nomes de variáveis com letras maiúsculas, nomes de variáveis muito curtos). Depois de derrotar o CheckStyle, enviei meu código para revisão aos desenvolvedores seniores e corrigi meus erros em uma semana. No geral, tive muita sorte de ter um bom relacionamento na minha equipe com o segundo desenvolvedor, que explicou muitas coisas. Um mês depois do aparelho, minha primeira integração foi lançada no estande Integração-Funcional (é testado o funcionamento de todos os aplicativos juntos), e tudo funcionou lá! Vitória! A próxima tarefa foi criar uma classe que permitisse ocultar dados por chave em JSON. Por exemplo: existe json {text:"JavaRush"} -> processamento -> {text:"****Rush"}. Há duas complicações aqui: pode haver aninhamento {text:{mytext:"JavaRush"}}, e o que é mais desagradável é aninhamento dentro do array: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush"}, {mytext: "JavaRush"} "} ] } (é claro que você precisa ocultar todo o text.mytext). Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil. Para uma quantidade tão grande de código, é necessário dividi-lo em classes; métodos que não são usados fora da classe devem ser declarados privados para não serem executados acidentalmente em outra classe, etc. Depois de escrever minha integração por analogia com outra integração, aprendi sobre a existência do CheckStyle - um plugin especial que verifica o estilo do seu código e você não poderá compilar seu projeto até corrigir erros (por exemplo, espaços extras, nomes de variáveis com letras maiúsculas, nomes de variáveis muito curtos). Depois de derrotar o CheckStyle, enviei meu código para revisão aos desenvolvedores seniores e corrigi meus erros em uma semana. No geral, tive muita sorte de ter um bom relacionamento na minha equipe com o segundo desenvolvedor, que explicou muitas coisas. Um mês depois do aparelho, minha primeira integração foi lançada no estande Integração-Funcional (é testado o funcionamento de todos os aplicativos juntos), e tudo funcionou lá! Vitória! A próxima tarefa foi criar uma classe que permitisse ocultar dados por chave em JSON. Por exemplo: existe json {text:"JavaRush"} -> processamento -> {text:"****Rush"}. Há duas complicações aqui: pode haver aninhamento {text:{mytext:"JavaRush"}}, e o que é mais desagradável é aninhamento dentro do array: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush"}, {mytext: "JavaRush"} "} ] } (é claro que você precisa ocultar todo o text.mytext). Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil. Para uma quantidade tão grande de código, é necessário dividi-lo em classes; métodos que não são usados fora da classe devem ser declarados privados para não serem executados acidentalmente em outra classe, etc. Depois de escrever minha integração por analogia com outra integração, aprendi sobre a existência do CheckStyle - um plugin especial que verifica o estilo do seu código e você não poderá compilar seu projeto até corrigir erros (por exemplo, espaços extras, nomes de variáveis com letras maiúsculas, nomes de variáveis muito curtos). Depois de derrotar o CheckStyle, enviei meu código para revisão aos desenvolvedores seniores e corrigi meus erros em uma semana. No geral, tive muita sorte de ter um bom relacionamento na minha equipe com o segundo desenvolvedor, que explicou muitas coisas. Um mês depois do aparelho, minha primeira integração foi lançada no estande Integração-Funcional (é testado o funcionamento de todos os aplicativos juntos), e tudo funcionou lá! Vitória! A próxima tarefa foi criar uma classe que permitisse ocultar dados por chave em JSON. Por exemplo: existe json {text:"JavaRush"} -> processamento -> {text:"****Rush"}. Há duas complicações aqui: pode haver aninhamento {text:{mytext:"JavaRush"}}, e o que é mais desagradável é aninhamento dentro do array: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush"}, {mytext: "JavaRush"} "} ] } (é claro que você precisa ocultar todo o text.mytext). Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil. os nomes das variáveis são muito curtos). Depois de derrotar o CheckStyle, enviei meu código para revisão aos desenvolvedores seniores e corrigi meus erros em uma semana. No geral, tive muita sorte de ter um bom relacionamento na minha equipe com o segundo desenvolvedor, que explicou muitas coisas. Um mês depois do aparelho, minha primeira integração foi lançada no estande Integração-Funcional (é testado o funcionamento de todos os aplicativos juntos), e tudo funcionou lá! Vitória! A próxima tarefa foi criar uma classe que permitisse ocultar dados por chave em JSON. Por exemplo: existe json {text:"JavaRush"} -> processamento -> {text:"****Rush"}. Há duas complicações aqui: pode haver aninhamento {text:{mytext:"JavaRush"}}, e o que é mais desagradável é aninhamento dentro do array: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush"}, {mytext: "JavaRush"} "} ] } (é claro que você precisa ocultar todo o text.mytext). Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil. os nomes das variáveis são muito curtos). Depois de derrotar o CheckStyle, enviei meu código para revisão aos desenvolvedores seniores e corrigi meus erros em uma semana. No geral, tive muita sorte de ter um bom relacionamento na minha equipe com o segundo desenvolvedor, que explicou muitas coisas. Um mês depois do aparelho, minha primeira integração foi lançada no estande Integração-Funcional (é testado o funcionamento de todos os aplicativos juntos), e tudo funcionou lá! Vitória! A próxima tarefa foi criar uma classe que permitisse ocultar dados por chave em JSON. Por exemplo: existe json {text:"JavaRush"} -> processamento -> {text:"****Rush"}. Há duas complicações aqui: pode haver aninhamento {text:{mytext:"JavaRush"}}, e o que é mais desagradável é aninhamento dentro do array: {text: [ {mytext: "JavaRush"}, {mytext: "JavaRush"}, {mytext: "JavaRush"} "} ] } (é claro que você precisa ocultar todo o text.mytext). Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil. Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil. Resolver esse problema acabou sendo bem difícil, mas consegui! Aqui o segundo desenvolvedor diz: cubra esse desenvolvimento com testes. Havia perplexidade nos olhos. Foi assim que conheci a biblioteca JUnit em combate. A essência do teste unitário: você tem dados de entrada, passa-os para um método e compara os dados recebidos com o resultado correto (cria uma variável com o resultado correto). Escrevi 11 casos para minha biblioteca, nos quais verifiquei se a aplicação não travou com uma NullPointException e se esconde corretamente os dados com qualquer tipo de aninhamento. Após concluir esta tarefa, recebi uma nova integração, cuja peculiaridade era a seguinte: tive que exportar um Spring Bean de uma biblioteca externa. Nesse ponto, tornei-me um cliente regular do site Stack OverFlow. Uma vez, até um desenvolvedor oficial do Spring respondeu. Após implementar esta integração, meu período de teste chegou ao fim. O patrão me parabenizou pela aprovação no período probatório e comecei a escrever este artigo. No total, foram necessárias 8 horas para escrever este artigo) Obrigado pela atenção, espero que o artigo tenha sido útil.
GO TO FULL VERSION