Nós da Veeam temos um projeto educacional com o nome lacônico de Veeam Academy . É dedicado à prática de desenvolvimento em C #. Se você não entrar em detalhes, sua essência é a seguinte: aceitamos estudantes seniores e em três meses trazemos o conhecimento puramente teórico do instituto, de acordo com a realidade circundante. Isso é feito com a ajuda de palestras, nas quais eles revelam o significado prático da teoria chata que eles conseguiram dar na universidade e com a ajuda de um projeto comum, cujo desenvolvimento eles estão envolvidos durante o treinamento.
No caminho para o primeiro lançamento da Academia, enfrentamos muitos problemas interessantes, puramente organizacionais e jurídicos. (Se alguém não sabia, o treinamento é uma atividade licenciada, então você não pode começar a aprender algo, mesmo que realmente queira, para não aumentar o interesse das autoridades reguladoras.)
Mas de onde os alunos obtêm essas mesmas habilidades práticas, você pergunta? A resposta está em nossos desenvolvedores, que, de maneira completamente voluntária, atuam como consultores, fazem revisões de código para crianças e simplesmente compartilham suas experiências. Além disso, apenas desenvolvedores seniores participam dessa atividade. Foi com eles (depois de três graduações na academia) que decidimos conversar para descobrir:
- Por que eles gastam seu tempo valioso com os alunos?
- Como é ser um mentor iniciante?
- Como / por que / por que viver com código legado?
- O que falta na educação moderna?
- Por que as pessoas vão para o desenvolvimento de produtos in a box?
Fizemos uma pequena série de entrevistas em vídeo com o estilo Dud, e haverá um pequeno extrato textual das respostas mais interessantes. Duas entrevistas completas foram publicadas (elas estão no artigo), mas outras três serão publicadas em breve.
Atores:
Alexander Baranov - Gerente de Desenvolvimento, Veeam Backup & Replication.
Artyom Grigoriev - Desenvolvedor experiente.
Dmitry Babushkin - Desenvolvedor sênior.
Kirill Lukyanov - Chefe do Departamento de Desenvolvimento do Hyper-V, líder do projeto de uma maneira simples.
Philip Guzeev - Desenvolvedor experiente.
Como nasceu a idéia da Veeam Academy?
Alexander - A ideia foi conjunta. No decorrer de inúmeras entrevistas, surgiu um entendimento do que os candidatos estavam faltando. Muitos juniores vêm até nós (desenvolvedor júnior). Como regra, são pessoas que se formaram recentemente no instituto, com experiência de trabalho de aproximadamente 1 ano ou nenhum. Como regra, eles não têm prática. Isso significa que algo precisa ser feito para que, se esse déficit não for completamente eliminado, pelo menos as principais lacunas sejam preenchidas. Começamos a pensar em como encaixar nossa experiência existente em cursos concisos de dois ou três meses - esse foi o começo.
Os cursos de algoritmos e estruturas de dados a serem ministrados nas faculdades de matemática não são ruins em si mesmos. O problema é que eles costumam se isolar de aplicações práticas em desenvolvimento, portanto não são muito bem absorvidos. Estamos tentando estruturar um pouco esse conhecimento e dar uma ideia prática de como ele funciona. E não apenas “como a tecnologia funciona”, mas como o processo como um todo funciona: como a equipe trabalha, como as tarefas são distribuídas, como sincronizar os membros da equipe etc.
Como você chegou à Academia?
Artyom - Eles se ofereceram para participar da Academia como revisores, e pensei: “Por que não?”. Ao mesmo tempo, atualizo meus conhecimentos e ganho experiência em falar. Foi minha primeira experiência quase na universidade, então fiquei muito preocupado.
Por outro lado, a Academia é uma oportunidade de contratar mais funcionários e, de qualquer forma, é uma experiência interessante e uma oportunidade de entender como é transferir conhecimento.
Philip - concordou imediatamente, como sugerido. É sempre interessante ver o que as pessoas têm maneiras de pensar, perceber algo novo para si. E é sempre útil compartilhar seu conhecimento.
Cyril - Quando o projeto começou, era apenas uma idéia para atrair desenvolvedores para o processo. Isso fazia sentido porque enfrentamos constantemente problemas técnicos específicos na prática e conhecemos alguns aspectos que estamos prontos para compartilhar. Uma proposta foi recebida, concordei espontaneamente e, quando já havia começado a abordar isso com mais atenção, já havia metas e desejo de alcançá-las.
O que você fez na Academia?
Dmitry - Perguntas preparadas para testes on-line, participou da seleção e entrevista dos alunos e também atuou como mentor para alguns alunos.
Alexander - eu fiz o que pensei e planejei a princípio, o que devemos fazer e contar - e o que [nos candidatos] não têm, e que seria interessante para as pessoas que vêm a esta Academia.
Philip - Na Academia, eu fui e sou como mentor - uma pessoa que revisa o código dos alunos e os direciona para o verdadeiro caminho, dando todo tipo de conselho.
Não me arrependo do tempo gasto?
Dmitry - Não, é claro. Ajudei a contratar três caras talentosos, mesmo em departamentos vizinhos, mas no final, temos uma grande equipe, uma família, se você quiser. Quanto mais pessoas no próximo departamento, menos elas abandonarão suas tarefas para nós =)
Cyril - pensei -, é uma boa chance de melhorar minhas habilidades com a mesma sociabilidade e oratória. Todos sabemos que esse tópico é terrível para muitos desenvolvedores, por isso superei meus medos.
Como resultado, eu contratei dois estudantes, os caras estão trabalhando com sucesso.
Por que você se tornou um mentor?
Dmitry - Eu gosto de me desenvolver em várias direções, e foi uma ótima ocasião para me provar em tudo. Na época da juventude violenta, os pensamentos deslizaram para o pedagógico, mas não deu certo, embora permanecesse uma certa experiência.
Philip - Nada está acontecendo por nada. Por exemplo, as pessoas vêm para a Academia não apenas assim, mas, por exemplo, para ocupar algum lugar na equipe posteriormente. E o papel da mentoria, entre outras coisas, é selecionar uma pessoa válida na equipe.
O que falta nos estudantes modernos?
Dmitry - Muitos caras talentosos pensam bem, mas, infelizmente, apenas devagar. Eles ainda não tinham experiência prática, seu cérebro não foi reconstruído para programação. Eles não conseguem encontrar rapidamente soluções, precisam sentar-se em silêncio e pensar em um ambiente acolhedor. Isso não é um problema quando você resolve alguns problemas acadêmicos em casa, mas quando eles se fundem no processo de trabalho, essas pessoas podem simplesmente não conseguir.
Cirilo - Se você designar tópicos grandes, as principais lacunas no conhecimento depois das universidades são a programação multithread. Provavelmente a área mais desastrosa, a julgar pela análise de nossas tarefas de teste.
Mas acho que isso é consequência da falta de prática. Existe teoria suficiente por aí, mas nas universidades, em regra, elas são muito unilaterais. Por exemplo, em C #, eles executam tarefas, assinam chamadas e as analisam. Esse mecanismo é conveniente, mas não permite que você olhe por baixo do capô. O próprio aluno deve ir e começar a entender, mas quase ninguém entende. A curiosidade é uma coisa boa, mas muitas vezes simplesmente não há tempo suficiente para isso.
O que há de tão interessante nas revisões de código do aluno?
Artyom - Em princípio, é interessante ver o código de outras pessoas. Como não usamos muitas inovações no fluxo de trabalho, aprendi algo interessante sobre tecnologias relativamente novas.
Os alunos escreveram no sétimo sharpe, no décimo sétimo estúdio, respectivamente, houve alguns momentos que eu ainda não havia encontrado na prática. Por exemplo, assíncrono / espera.
Uma revisão de código é, digamos, a prática de escrever um bom código. Quando você escreve, involuntariamente pensa: "Bem, você pode entender, aqui é melhor, é pior, então eu vou refazê-lo, etc. E quando você olha o código de outra pessoa, não tem restrições de que precisa corrigir 10 erros antes do almoço. E você pode investigar calmamente onde é ruim, onde pode fazer melhor e onde refazê-lo completamente. Isso ajuda a analisar o processo de escrever código de fora e, no futuro, é mais fácil resolver problemas e como fazer um esquema de chamada, responsabilidade de classe etc.
O que você espera de um aluno para uma entrevista?
Dmitry - eu quero ver a abordagem dele. As pessoas vêm, dizem que lêem, por exemplo, Richter. Eu não li Richter, mas quando você começa a conversar com eles, fica óbvio que eles encontraram uma resposta para sua própria pergunta e isso é tudo - ou seja, eles não leram [pensativamente]. Eles folhearam um livro, mas não estão interessados no que ele escreve, não estão interessados em como o .NET Framework é organizado por dentro. Essa é uma abordagem válida se você for um especialista estabelecido. Mas se você viu o C # no seu primeiro ano e começou a descartar alguns detalhes de implementação, como tudo está organizado sob o capô, isso é uma garantia de que você começará a pisar no rake. E se, nesse momento, você entrar no projeto da equipe, isso inevitavelmente afetará seu resultado. Todo mundo vai repreendê-lo, sua motivação cairá e a questão surgirá sobre novos trabalhos.
Há outro aspecto de ter tempo livre. Mesmo que os olhos de [aluno] estejam ardendo, mas ele passará duas horas no caminho para a Academia, além de seu emprego de meio período, além de problemas de vida e um gato faminto em casa, fica claro que ele não tem tempo livre e apenas queima como um fósforo. três meses de estudo.
É difícil ensinar como escrever código "corretamente e conforme a necessidade"?
Philip - Você não pode dizer "está fazendo certo ou errado". Não existe tal coisa. Você cria código suportado ou código não suportado. Suponha que você tenha uma tarefa de redigir um projeto em 5 horas em um hackathon. E, é claro, você não pensará na beleza da arquitetura e na beleza do código. "Você estraga tudo" para trabalhar - e com razão. Por outro lado, se você trabalha em uma empresa [de uma grande empresa - ed.], Então você aloca tempo para tarefas e certos requisitos para o código, e é isso que estamos nos esforçando e procurando.
Alexander - Existem duas situações. Se uma pessoa já fez algo semelhante em outra empresa de alimentos, ela entrará com relativa facilidade. O mercado padroniza processos.
Outra coisa é quando você já tem experiência, mas você fez algumas outras coisas. Isso levanta a questão: "Como você deseja desenvolver mais?" Se seu objetivo é trabalhar em uma grande empresa, mudar para outro país, você terá que passar por um período de ruptura. É como um carro pessoal depois do transporte público (ou vice-versa): no começo é doloroso e triste, mas depois se torna muito confortável e conveniente.
Dmitry - De fato, se uma pessoa tem um nível mínimo de habilidade, ela não precisa "quebrá-lo". Mas quando programadores experientes chegam, eles já têm seu próprio conjunto de práticas, seu próprio estilo de código, que pode divergir do nosso - e as conversas começam: “Por que você está me proibindo de usar vars? Eu tenho um código tão bom, nem um único tipo é visível, e tudo está como deveria estar na programação funcional. ” Mas com essas pessoas é mais difícil.
E se este é um estudante, mesmo do ano passado, com uma dúzia de projetos no github, ele simplesmente não teve tempo para adquirir práticas cruéis. Bem, trabalhar com pessoas completamente "puras" é um prazer.
Os alunos podem surpreender agradavelmente?
Artyom - Digamos que, às vezes, houve situações em que você abre o código e há construções em todos os lugares que você nunca viu antes. Eu tive que me sentar com eles e descobrir como usá-los corretamente. Aconteceu que eu mesmo não entendi direito da primeira vez.
A Veeam Academy foi útil para você pessoalmente?
Dmitry - Sim, claro. Como sempre - quando você diz a alguém como fazê-lo, primeiro entende como fazê-lo. Em segundo lugar, você sistematiza seu próprio conhecimento e, mesmo no processo de palestras, encontra respostas para algumas perguntas que há muito o atormentam. Portanto, compartilhar seu conhecimento com outra pessoa é uma ótima maneira de se desenvolver.
Alexander - Antes de tudo, ficou claro o que as pessoas esperam, inclusive do local de trabalho futuro. Quando você, como líder, está no processo, você cozinha mais no desenvolvimento de negócios. E onde a situação é mais informal, como na academia, fica claro o que move as pessoas, o que elas querem e quais são seus interesses.
Você aprende, inclusive muito, sobre si mesmo, e isso é a coisa mais importante.
Por exemplo, você entende que muitas coisas precisam ser simplificadas. Quando você trabalha em uma área por um longo período, o olho fica embaçado e as coisas que são óbvias para você se tornam completamente incompreensíveis para outras pessoas, especialmente para iniciantes.
Philip - Quando você cozinha constantemente no meio de desenvolvedores de um certo nível, começa a falar em algum tipo de linguagem que é compreensível apenas para você. E quando chega uma pessoa que está entrando nesse ambiente, você começa a explicar tudo em algumas palavras mais simples, aprende a transmitir informações de uma maneira mais estruturada.
Trabalhando com os alunos, você também aprende paciência, algum tipo de compaixão e compreensão =) Mas então você começa a ver algumas coisas que ele mesmo sabia, mas esqueceu. Você precisa se aprofundar na tecnologia para transmitir melhor à pessoa o significado do que está acontecendo. Em vez disso, o significado de por que é melhor fazer assim, mas é melhor não fazer assim.
Desenvolvimento empresarial é sempre sobre legado?
Cirilo - afirmação absolutamente correta. Quando um projeto é escrito há 10 anos e está em constante evolução, uma certa porcentagem do código legado estará nele.
Outra questão é como diferentes empresas podem abordar isso.
Enquanto o módulo estiver funcionando, tentamos não entrar nele. Foi depurado há 5 anos e mais de uma versão vem trabalhando constantemente. Outra pergunta é quando você obtém um código no qual constantemente precisa alterar alguma coisa. Nesse caso, não nos é proibido melhorá-lo gradualmente: refatoração etc. 10 anos atrás, havia um padrão de linguagem diferente, outras construções lexicais. Ninguém se preocupa em aceitar, refatorar e transferir para novos designs.
O código rejuvenesce gradualmente, mas está tudo nas mãos do desenvolvedor. Você pode martelar um parafuso, resolver o problema atual e talvez isso seja suficiente para a empresa, porque o objetivo final na forma de um produto de trabalho será alcançado. Bem, o que há dentro ... Há muitas histórias na Internet, especialmente sobre o início do gamedev, quando apenas classes apareceram em C ++ ... você abre o código - há classes, há muitas inclusões em cada uma. É claro que agora eles chamariam isso de uma palavra muito específica.
Mas, em geral, com o código legado, você deve poder viver. Ele não precisa ter medo.
Dmitry - código legado, é claro, está presente e, é claro, você precisa de alguma forma viver com ele. Mas você não mora com ele por desespero, mas porque não faz sentido tocá-lo. Na maioria das vezes, o código legado é alguns componentes já depurados, mesmo que escritos em algum tipo de .Net 2.0. Eles funcionam há anos, não há nenhuma nova funcionalidade que precisa ser adicionada a eles - e por que tocá-los se eles funcionam e funcionam bem? ?
Há situações em que você vê um bug no código antigo que passou por várias versões, mas foi acionado repentinamente. É quando você começa a reescrever o código antigo, talvez cubra-o com testes de unidade para não quebrar nada. Ou você apenas confia nos testadores infinitamente. I.e. é claro que você simplesmente se diverte, não para o lançamento - mas todo o tipo de beta apenas para isso e inventado.
Quanto à Academia, este projeto também nos permite acompanhar os tempos. Chegam novos caras, eles acompanham ativamente as notícias do mundo do C #, .Net etc. Eles gostam de algumas construções novas, o "açúcar sintático" das versões mais recentes. E, de fato, por meio de seus líderes de equipe, eles forçam [promovem] esses designs no projeto. Sim, pode causar resistência, as pessoas podem não aceitá-lo imediatamente, mas é tudo temporário e, se um recurso realmente útil aparecer no novo quadro, ele entrará no processo.
Philip - Eu tenho que lidar com o que foi escrito há 10 anos. Você não vai conseguir nada disso. Naturalmente, nós nos esforçamos para atualizar nossa pilha, mas temos 180 projetos em desenvolvimento, vários milhões de linhas de código foram escritas durante esse período e é muito difícil simplesmente pular sobre ela. Nós devemos entender e de alguma forma aceitar isso.
Alexander - Uma vez li uma apresentação da Mercedes Benz sobre o motivo de serem tão conservadores e introduzir tecnologias com um certo atraso. A resposta é simples: tudo o que não beneficia o cliente vai "em um balde". O desenvolvimento da empresa segue o mesmo princípio. As primeiras "vítimas" da nova tecnologia devem ser analistas, desenvolvedores, um laboratório de teste ou qualquer pessoa, mas não o cliente. Qualquer tecnologia antes de aparecer no produto deve ser executada. Por fora, parece legado, mas por dentro não é. É que tudo o que é moderno é necessário primeiro testar "em gatos" e só depois aplicar na vida.
Artyom - Sim e não. Nosso produto tem 10 anos, portanto, temos muito legado, mas isso não significa que arrastamos cegamente os componentes antigos e não façamos nada com eles. Acontece que a reescrevemos completamente.
Então, como é a introdução de novos recursos?
Alexander - Antes de tudo, explique que problema você está resolvendo. Se você trouxe o projeto do veículo espacial lunar - isso certamente é ótimo, mas explique por que ele é necessário. Se você pode explicar por que isso será útil para nós, é claro que vamos implementá-lo.
Cyril - Primeiro você precisa entender o que é - porque Isso pode ter consequências. Se introduzirmos alguma nova biblioteca, não apenas os desenvolvedores estarão envolvidos aqui. Está incluído o departamento de testes, que precisará testar novamente toda a lógica que se baseava no antigo código de trabalho e agora mudamos tudo.
Portanto, a introdução de algo novo no desenvolvimento da produção é frequentemente associada a grandes despesas gerais. E se o ganho da implementação exceder esses custos, então, em regra, é tomada uma decisão sobre a implementação. E se pelo contrário, então por quê? Não há necessidade de se dar um tiro no pé.
E o fervor dos Jones e seu desejo de melhorar tudo?
Dmitry - Eles ainda não resolvem tarefas sérias e complexas devido à falta de competência. A tenra idade (em termos de desenvolvedor) é uma ótima oportunidade para se destacar, especialmente se você não acredita nos camaradas mais velhos. Se o preço da pergunta for de dois dias, durante os quais ele entenderá que sua idéia "engenhosa" não decolará e ele não lidará mais com esse lixo, então é melhor dar a ele a oportunidade de pisar nesse rake pessoalmente. É muito pior proibi-lo de fazer isso e, durante meses, ele pensará que "o líder desagradável da equipe me proibiu de cortar a coisa legal".
Cyril - Tudo o que é dado na Academia permite aos alunos, em primeiro lugar, olhar para a pilha de tecnologias modernas. Em segundo lugar, tudo o que damos, tentamos usar ao máximo.
Nosso produto não é jovem, mas quando um novo recurso é criado, ele é criado do zero, e o uso de novas tecnologias traz menos riscos. Então, deixe-os usá-lo.
Artyom - Novos recursos são bons para aplicar em novas áreas. Nosso projeto não é tão monolítico que resolve apenas um problema, e é isso. Tem muitas funções e sempre há um lugar para aplicar o novo.
Quando uma nova pessoa chega, elas recebem as primeiras tarefas educacionais, depois as pequenas. De qualquer forma, primeiro ele precisa se familiarizar com o projeto, porque é enorme. Parece que já existem mais de um milhão de linhas de código, mas posso mentir. De qualquer forma, para dar uma olhada em uma semana, e mesmo em um mês, ele não terá sucesso. Mas quando ele começa a entender, podemos fazer um experimento, por que não?
Como ser um júnior com um legado?
Philip - Em primeiro lugar, você não pode dizer que essas coisas estão completamente desatualizadas. Existem todos os tipos de "know-how" direto, ok, trabalhamos amplamente sem eles. Mas, em qualquer caso, uma pessoa aprenderá a maneira correta de codificar a organização e o design. Isso não vai a lugar nenhum.
Também ensinaremos como trabalhar com o legado. Essa também é uma habilidade muito importante. Você não pode pensar que virá e começará a projetar o melhor sistema do mundo. Não. Na maioria das vezes, chegando à empresa, você se encontra com um produto acabado. [ — .], [ — .].
— . backlog [ , — .], , . , - , , - .
-, . , , , .
, , ?
— Enterprise- , . , , , . , “ ”, “”. , enterprise[-]. , , , , . , Veeam 5 , SMB [small & medium businesses — .] Enterprise. enterprise[-], , , . , , .
. , enterprise. : , enterprise “”, . , , . , enterprise, . : - 5 ( ) , , , . , .
. , . , . , , .
— . , , - , , .
[.. — .] . , .
? , , . , , — . : , . .
, 2-3 . , . , Veeam, , - , - . — .. , , .
— , . , . , enterprise- , .
, , , . , Amazon , Facebook , , .
, enterprise. , .
— “, , ” , . . , . , , - , , , . , .
, , . , , .. , . . , , .
enterprise?
— , . , , , “ ”, .
— . - - . - , “”. . 8 , , . , .
— , enterprise. , , , . , , ..
— , — . , , .
?
— , . , . - , , .
, . — , . , , , . , . -, , , “” [ — .]. , , . .
?
— , . .
— , , .
— . -, . 15 - , , , [Microsoft Visual Studio — .], , - .
— , .
— , , . , , , . , , , .
, , , .