Chez Veeam, nous avons un projet éducatif avec le nom laconique de Veeam Academy . Il est dédié à la pratique du développement C #. Si vous n'entrez pas dans les détails, l'essentiel est le suivant: nous prenons des étudiants seniors et en trois mois apportons leurs connaissances purement théoriques de l'institut en accord avec la réalité environnante. Cela se fait à la fois à l'aide de conférences, où ils révèlent le sens pratique de la théorie ennuyeuse qu'ils ont réussi à leur donner à l'université, et à l'aide d'un projet commun, dont ils sont engagés dans le développement tout au long de la formation.
Sur le chemin du premier lancement de l'Académie, nous avons été confrontés à de nombreux problèmes intéressants, à la fois purement organisationnels et juridiques. (Si quelqu'un ne le savait pas, la formation est une activité autorisée, donc vous ne pouvez pas simplement commencer à apprendre quelque chose, même si vous le voulez vraiment, afin de ne pas augmenter l'intérêt des autorités réglementaires.)
Mais d'où les étudiants tirent-ils ces mêmes compétences pratiques, demandez-vous? La réponse réside dans nos développeurs, qui, sur une base entièrement volontaire, agissent en tant que consultants, effectuent des révisions de code pour les enfants et partagent simplement leurs expériences. De plus, seuls les développeurs seniors participent à cette activité. C'est avec eux (après 3 diplômes de l'académie) que nous avons décidé de parler pour découvrir:
- Pourquoi passent-ils leur temps précieux sur les étudiants?
- Comment vous sentez-vous d'être un mentor novice?
- Comment / pourquoi / pourquoi vivre avec un code hérité?
- Qu'est-ce qui manque dans l'éducation moderne?
- Pourquoi les gens vont-ils au développement de produits en boîte?
Nous avons fait une petite série d'entretiens vidéo avec Dud-style, et il y aura un petit extrait textuel des réponses les plus intéressantes. Deux interviews complètes ont maintenant été publiées (elles sont dans l'article), mais trois autres seront bientôt publiées.
Acteurs:
Alexander Baranov - Directeur du développement, Veeam Backup & Replication.
Artyom Grigoriev - Développeur expérimenté.
Dmitry Babushkin - Développeur principal.
Kirill Lukyanov - Chef du département de développement pour Hyper-V, chef de projet de manière simple.
Philip Guzeev - Développeur expérimenté.
Comment est née l'idée de Veeam Academy?
Alexander - L'idée était commune. Au cours de nombreuses entrevues, il est apparu que les candidats manquaient. Beaucoup de juniors viennent chez nous (développeur junior). En règle générale, il s'agit de personnes récemment diplômées de l'institut, ayant une expérience d'environ 1 an ou pas du tout. En règle générale, ils manquent de pratique. Cela signifie que quelque chose doit être fait pour que si ce déficit n'est pas complètement éliminé, au moins les principales lacunes seront comblées. Nous avons commencé à réfléchir à la manière d'intégrer notre expérience existante dans des cours concis de deux ou trois mois - c'était le début.
Les cours d'algorithmes et de structures de données à enseigner dans les facultés de mathématiques ne sont pas mauvais en soi. Le problème est qu'ils vont souvent à l'écart des applications pratiques en développement, donc ils ne sont pas très bien absorbés. Nous essayons de structurer un peu ces connaissances et de leur donner une idée pratique de leur fonctionnement. Et pas seulement «comment la technologie fonctionne», mais comment le processus dans son ensemble fonctionne: comment l'équipe fonctionne, comment les tâches sont réparties, comment synchroniser les membres de l'équipe, etc.
Comment êtes-vous arrivé à l'Académie?
Artyom - Ils ont proposé de participer à l'Académie en tant que critique, je me suis dit: «Pourquoi pas?». En même temps, je rafraîchirai mes connaissances et gagnerais de l'expérience de la parole. C'était ma première expérience presque de l'université, donc j'étais très inquiet.
D'un autre côté, l'Académie est une opportunité d'embaucher plus d'employés, et en tout cas c'est une expérience intéressante et une opportunité de comprendre ce que c'est que de transférer des connaissances.
Philip - Immédiatement d'accord, comme suggéré. Il est toujours intéressant de voir ce que les gens ont à penser, de remarquer quelque chose de nouveau pour eux-mêmes. Et il est toujours utile de partager vos connaissances.
Cyril - Lorsque le projet a démarré, ce n'était qu'une idée pour attirer les développeurs dans le processus. Cela avait du sens parce que nous sommes constamment confrontés à des problèmes techniques spécifiques dans la pratique et nous connaissons pas mal d'aspects que nous sommes prêts à partager. Une proposition a été reçue, j'ai accepté spontanément, et quand j'avais déjà commencé à aborder cela de manière plus réfléchie, il y avait déjà des objectifs et une volonté de les atteindre.
Qu'avez-vous fait à l'Académie?
Dmitry - A préparé des questions pour les tests en ligne, a participé à la sélection et à l'entretien des étudiants et a également agi comme mentor pour certains étudiants.
Alexander - J'ai fait ce que je pensais et planifiais au début, que devons-nous faire et dire - et ce que nous [les candidats] manquons, et que ce serait intéressant pour les gens qui viennent dans cette Académie.
Philip - À l'Académie, j'étais et je suis en tant que mentor - une personne qui révise le code des étudiants et les oriente vers le vrai chemin, en donnant toutes sortes de conseils.
Ne regrette pas le temps passé?
Dmitry - Non, bien sûr. J'ai aidé à embaucher trois gars talentueux, même dans les départements voisins, mais au final nous avons une grande équipe, une famille, si vous voulez. Plus il y aura de personnes dans le département suivant, moins elles se débarrasseront de leurs tâches pour nous =)
Cyril - je pensais - c'est une bonne occasion d'améliorer mes compétences de même sociabilité et prise de parole en public. Nous savons tous que ce sujet est terrible pour de nombreux développeurs, j'ai donc surmonté mes peurs.
En conséquence, j'ai embauché deux étudiants, les gars travaillent avec succès.
Pourquoi êtes-vous devenu mentor?
Dmitry - J'aime évoluer dans différentes directions, et ce fut une excellente occasion de faire mes preuves dans tout. À l'époque de la jeunesse violente, les pensées se sont glissées dans la pédagogie, mais cela n'a pas fonctionné, même si une certaine expérience est restée.
Philip - Rien ne se passe pour rien. Par exemple, les gens viennent à l'Académie non seulement comme ça, mais, par exemple, afin de prendre une place plus tard dans l'équipe. Et le rôle du mentorat, entre autres, est de sélectionner une personne valide dans l'équipe.
Qu'est-ce qui manque aux étudiants modernes?
Dmitry - Beaucoup de gars talentueux viennent qui pensent bien, mais malheureusement lentement. Ils n'avaient pas encore d'expérience pratique, leur cerveau n'était pas reconstruit pour la programmation. Ils ne peuvent pas trouver rapidement de solutions, ils doivent s'asseoir tranquillement et réfléchir dans une atmosphère chaleureuse. Ce n'est pas un problème lorsque vous résolvez certains problèmes scolaires à la maison, mais lorsqu'ils fusionnent dans le processus de travail, ces personnes peuvent tout simplement ne pas tirer.
Cyril - Si vous désignez de grands sujets, les principales lacunes dans les connaissances après les universités sont la programmation multithread. Probablement la zone la plus désastreuse, à en juger par l'analyse de nos tâches de test.
Mais je pense que c'est une conséquence du manque de pratique. Il y a assez de théorie autour, mais dans les universités, en règle générale, ils la donnent très unilatéralement. Par exemple, en C #, ils prennent la tâche, les appels asynchrones et les analysent. Ce mécanisme est pratique, mais ne vous permet pas de regarder sous le capot. L'élève lui-même doit partir et commencer à comprendre, mais presque personne ne le fait. La curiosité est une bonne chose, mais souvent il n'y a tout simplement pas assez de temps pour cela.
Qu'est-ce qui est si intéressant dans les revues de code étudiant?
Artyom - En principe, il est intéressant en soi de regarder le code des autres. Nous n'utilisons pas beaucoup d'innovations dans le flux de travail, j'ai donc même appris quelque chose d'intéressant concernant les technologies relativement nouvelles.
Les étudiants ont écrit sur le septième sharpe, dans le dix-septième studio, respectivement, il y avait des moments que je n'avais pas encore rencontrés dans la pratique. Par exemple async / wait.
Une révision de code est, disons, la pratique d'écrire du bon code. Lorsque vous l'écrivez vous-même, vous pensez involontairement: "Eh bien, vous pouvez l'obtenir, ici c'est mieux, ici c'est pire, alors je vais le refaire, etc." Et quand vous regardez le code de quelqu'un d'autre, vous n'avez aucune restriction dont vous avez besoin pour corriger 10 bugs avant le déjeuner. Et vous pouvez tranquillement fouiller là où elle est mauvaise, où vous pouvez faire mieux et où la refaire complètement. Cela aide à regarder le processus d'écriture de code de l'extérieur, et à l'avenir, il sera plus facile de résoudre les problèmes comme la façon de faire un schéma d'appel, la responsabilité de classe, etc.
Qu'attendez-vous d'un étudiant pour un entretien?
Dmitry - Je veux voir son approche. Les gens viennent, ils disent qu'ils lisent, par exemple, Richter. Je n'ai pas lu Richter, mais quand vous commencez à leur parler, il devient évident qu'ils y ont trouvé une réponse à leur propre question et c'est tout - c'est-à-dire ils ne l'ont pas lu [pensivement]. Ils ont feuilleté un livre, mais ils ne s'intéressent pas à ce qu'il écrit, ni à la façon dont le cadre .Net est organisé à l'intérieur. Il s'agit d'une approche valable si vous êtes un spécialiste établi. Mais si vous avez vu C # au cours de votre première année et commencé à brosser certains détails de mise en œuvre, comment tout est organisé sous le capot, c'est une garantie que vous commencerez à marcher sur le râteau. Et si à ce moment vous entrez dans le projet d'équipe, cela affectera inévitablement votre résultat. Tout le monde vous réprimandera, votre motivation diminuera et la question se posera de poursuivre le travail.
Il y a un autre aspect à avoir du temps libre. Même si ses yeux [d'élève] brûlent, mais il passera deux heures sur le chemin de l'Académie, plus son travail à temps partiel, plus des problèmes de vie et un chat affamé à la maison, il devient clair qu'il n'a pas de temps libre et il brûlera comme un match pour trois mois d'études.
Est-il difficile d'apprendre à écrire du code «correctement et selon nos besoins»?
Philip - Vous ne pouvez pas dire "vous le faites bien - ou mal". Il n'y a rien de tel. Vous créez du code pris en charge ou vous créez du code non pris en charge. Supposons que vous ayez la tâche de rédiger un projet en 5 heures sur un hackathon. Et, bien sûr, vous ne penserez pas à la beauté de l'architecture et à la beauté du code. «Vous vous trompez» pour travailler - et à juste titre. D'un autre côté, si vous travaillez dans une entreprise [d'une grande entreprise - ndlr], alors vous avez alloué du temps pour les tâches et certaines exigences pour le code, et c'est ce que nous recherchons et ce que nous recherchons.
Alexander - Il y a deux situations. Si une personne a déjà fait quelque chose de similaire dans une autre entreprise alimentaire, elle y entrera relativement facilement. Le marché standardise les processus.
Une autre chose est quand vous avez déjà de l'expérience, mais vous avez fait quelques autres choses. Cela soulève la question: «Comment voulez-vous vous développer davantage?» Si votre objectif est de travailler dans une grande entreprise, de déménager dans un autre pays, alors vous devrez endurer une période de rupture. C'est comme une voiture personnelle après les transports en commun (ou vice versa): au début, c'est douloureux et triste, mais ensuite cela devient très confortable et pratique.
Dmitry - En fait, si une personne a un niveau de compétence minimum, elle n'a pas à le «casser». Mais lorsque des programmeurs expérimentés viennent, ils ont déjà leur propre ensemble de pratiques, leur propre style de code, qui peuvent diverger des nôtres - et les conversations commencent «Pourquoi m'interdisez-vous d'utiliser var'y? J'ai un si bon code, aucun type n'est visible, et tout est comme il se doit dans la programmation fonctionnelle. » Mais avec de telles personnes, c'est plus difficile.
Et si c'est un étudiant, même de la dernière année, avec une dizaine de projets sur le github, il n'a tout simplement pas eu le temps d'acquérir des pratiques vicieuses. Et bien, travailler avec des gens complètement «purs» est un plaisir.
Les étudiants peuvent agréablement surprendre?
Artyom - Disons simplement que, parfois, il y a eu des situations où vous ouvrez le code, et il y a des constructions partout que vous n'avez jamais vues auparavant. Je devais m'asseoir avec eux et trouver comment les utiliser correctement. Il m'est arrivé de ne pas comprendre moi-même correctement la première fois.
Veeam Academy vous a-t-elle été utile personnellement?
Dmitry - Oui, bien sûr. Comme d'habitude - lorsque vous dites à quelqu'un comment le faire, tout d'abord, vous comprenez comment le faire. Deuxièmement, vous systématisez vos propres connaissances et même au cours de conférences, vous trouvez par vous-même des réponses à certaines questions qui vous tourmentent depuis longtemps. Partager vos connaissances avec quelqu'un d'autre est donc un excellent moyen de vous développer.
Alexander - Tout d'abord, il est devenu clair ce que les gens attendent, y compris du lieu de travail futur. Lorsque vous, en tant que leader, êtes dans le processus, vous cuisinez plutôt en développement des affaires. Et là où la situation est plus informelle, comme à l'académie, il devient clair ce qui motive les gens, ce qu'ils veulent et quels sont leurs intérêts.
Vous apprenez, y compris beaucoup, sur vous-même, et c'est la chose la plus importante.
Par exemple, vous comprenez que beaucoup de choses doivent être simplifiées. Lorsque vous travaillez dans un domaine pendant longtemps, l'œil devient flou et les choses qui sont évidentes pour vous deviennent complètement incompréhensibles pour les autres, en particulier les débutants.
Philip - Lorsque vous cuisinez constamment au milieu de développeurs d'un certain niveau, vous commencez à parler dans une sorte de langage qui ne vous est compréhensible. Et lorsqu'une personne arrive qui vient d'entrer dans cet environnement, vous commencez à tout expliquer en quelques mots plus simples, vous apprenez à transmettre des informations de manière plus structurée.
En travaillant avec les élèves, vous apprenez aussi la patience, une sorte de compassion et de compréhension =) Mais ensuite vous commencez à voir des choses qu'il savait lui-même, mais qu'il avait oubliées. Vous devez approfondir la technologie afin de mieux transmettre à la personne le sens de ce qui se passe. Plutôt, la signification de pourquoi il vaut mieux faire comme ça, mais il vaut mieux ne pas faire comme ça.
Le développement d'entreprise est toujours une question d'héritage?
Cyril - Déclaration absolument correcte. Lorsqu'un projet a été écrit pendant 10 ans et évolue constamment, un certain pourcentage de code hérité s'y trouvera.
Une autre question est de savoir comment différentes entreprises peuvent aborder cela.
Pendant que le module fonctionne, nous essayons de ne pas y entrer. Il a été débogué il y a 5 ans et plus d'une version fonctionne régulièrement. Une autre question est de savoir quand vous obtenez un code dans lequel vous devez constamment changer quelque chose. Dans ce cas, il ne nous est pas interdit de l'améliorer progressivement: refactoring, etc. Il y a 10 ans, il y avait une norme linguistique différente, d'autres constructions lexicales. Personne ne prend la peine de prendre, de refaçonner et de transférer vers de nouveaux modèles.
Le code rajeunit progressivement, mais tout est entre les mains du développeur. Vous pouvez marteler un boulon, résoudre le problème actuel, et ce sera peut-être suffisant pour l'entreprise, car l'objectif final sous la forme d'un produit fonctionnel sera atteint. Eh bien, ce qu'il y a à l'intérieur ... Il y a beaucoup d'histoires sur Internet, en particulier à l'aube de gamedev, lorsque seules les classes sont apparues en C ++ ... vous ouvrez le code - il y a des classes, il y a beaucoup d'inclusions dans chacune. Il est clair que maintenant ils l'appelleraient un mot très spécifique.
Mais en général, avec le code hérité, vous devez pouvoir vivre. Il n'est pas nécessaire d'avoir peur de lui.
Dmitry - Le code hérité, bien sûr, est présent et, bien sûr, vous devez en quelque sorte vivre avec. Mais vous ne vivez pas avec lui par désespoir, mais parce que cela n'a aucun sens de le toucher. Le plus souvent, le code hérité est des composants déjà débogués, même s'ils sont écrits sur une sorte de .Net 2.0. Ils fonctionnent pendant des années, il n'y a aucune nouvelle fonctionnalité qui doit leur être ajoutée - et pourquoi les toucher s'ils fonctionnent et fonctionnent correctement ?
Il y a des situations où vous voyez un bogue dans l'ancien code qui a passé plusieurs versions, mais s'est soudainement déclenché. C'est alors que vous commencez à réécrire l'ancien code, peut-être à le recouvrir de tests unitaires afin de ne rien casser. Ou vous faites sans cesse confiance aux testeurs. C'est-à-dire vous prenez juste un bon moment, bien sûr, pas pour la sortie - mais toutes sortes de bêta juste pour cela et inventé.
Quant à l'Académie, ce projet nous permet également de suivre le rythme. De nouveaux mecs arrivent, ils suivent activement l'actualité du monde de C #, .Net, etc. Ils aiment les nouvelles constructions, le «sucre syntaxique» des dernières versions. Et, en fait, par le biais de leurs chefs d'équipe, ils forcent [promeuvent] ces conceptions dans le projet. Oui, cela peut provoquer une résistance, les gens peuvent ne pas l'accepter tout de suite, mais tout cela est temporaire et si une fonctionnalité vraiment utile vient dans le nouveau cadre, elle entrera dans le processus.
Philip - Je dois faire face à ce qui a été écrit il y a 10 ans. Vous n'obtiendrez rien de tout cela. Naturellement, nous nous efforçons de mettre à jour notre pile, mais nous avons 180 projets en développement, plusieurs millions de lignes de code ont été écrites pendant cette période, et il est très difficile de simplement sauter par-dessus. Nous devons comprendre et en quelque sorte l'accepter.
Alexander - J'ai lu une fois une présentation de Mercedes Benz expliquant pourquoi ils sont si conservateurs et introduisent des technologies avec un certain retard. La réponse est simple: tout ce qui ne profite pas au client va «dans un seau». Le développement des entreprises suit le même principe. Les premières «victimes» de la nouvelle technologie devraient être des analystes, des développeurs, un laboratoire de test ou n'importe qui, mais pas le client. Toute technologie avant d'apparaître dans le produit doit être intégrée. De l'extérieur, cela ressemble à un héritage, mais de l'intérieur, ce n'est pas le cas. C’est juste que tout ce qui est moderne, nous devons d’abord le tester «sur des chats» et ensuite seulement l’appliquer dans la vie.
Artyom - Oui et non. Notre produit a 10 ans, nous avons donc beaucoup d'héritage, mais cela ne signifie pas que nous traînons aveuglément les anciens composants et ne faisons rien avec eux. Il arrive que nous le réécrivions complètement.
Alors, comment est l'introduction de nouvelles fonctionnalités?
Alexander - Tout d'abord, expliquez quel problème vous résolvez. Si vous avez apporté le projet du rover lunaire - c'est certainement génial, mais expliquez pourquoi il est nécessaire. Si vous pouvez expliquer pourquoi cela nous sera utile, alors, bien sûr, nous le mettrons en œuvre.
Cyril - Vous devez d'abord comprendre ce que c'est - parce que cela peut avoir des conséquences. Si nous introduisons une nouvelle bibliothèque, non seulement les développeurs sont impliqués ici. Le département de test est inclus, qui devra tester à nouveau toute la logique qui reposait sur l'ancien code de travail, et maintenant nous avons tout changé.
Par conséquent, l'introduction de quelque chose de nouveau dans le développement de la production est souvent associée à de gros frais généraux. Et si le gain de la mise en œuvre dépasse ces coûts, alors, en règle générale, une décision sur la mise en œuvre est prise. Et si au contraire, pourquoi? Pas besoin de se tirer une balle dans le pied.
Qu'en est-il de la ferveur des Jones et de leur désir de tout améliorer?
Dmitry - Ils ne résolvent toujours aucune tâche sérieuse et complexe en raison d'un manque de compétence. Le jeune âge (en termes de développeur) est une excellente occasion de se faire des bosses, surtout si vous ne croyez pas les camarades plus âgés. Si le prix de la question est de deux jours, pendant lesquels il comprendra que son idée «ingénieuse» ne décollera pas, et qu'il ne traitera plus de ces ordures, alors il vaut mieux lui donner l'opportunité de monter personnellement sur ce râteau. C’est bien pire de lui interdire de le faire, et pendant des mois, il pensera que «le méchant chef d’équipe m’a interdit de couper le truc cool».
Cyril - Tout ce qui est donné à l'Académie permet aux étudiants, tout d'abord, de regarder la pile des technologies modernes. Deuxièmement, tout ce que nous donnons, nous essayons de l'utiliser au maximum.
Notre produit n'est pas jeune, mais lorsqu'une nouvelle fonctionnalité est écrite, elle est créée à partir de zéro et l'utilisation de nouvelles technologies comporte moins de risques. Alors laissez-les l'utiliser.
Artyom - Les nouvelles fonctionnalités sont bonnes à appliquer dans de nouveaux domaines. Notre projet n'est pas si monolithique qu'il ne résout qu'un seul problème, et c'est tout. Il a de nombreuses fonctions et il y a toujours une place pour appliquer le nouveau.
Lorsqu'une nouvelle personne arrive, on lui donne d'abord des tâches éducatives, puis de petites tâches. En tout cas, il doit d'abord se familiariser avec le projet, car il est énorme. Il semble que déjà plus d'un million de lignes de code, mais je peux mentir. En tout cas, pour y jeter un coup d'oeil dans une semaine, et même dans un mois il ne réussira pas. Mais quand il commence à comprendre, nous pouvons faire une expérience, pourquoi pas.
Comment être un junior avec un héritage?
Philip - Premièrement, vous ne pouvez pas dire que ces choses sont complètement obsolètes. Il y a toutes sortes de «savoir-faire» directs, ok, on travaille en grande partie sans eux. Mais dans tous les cas, une personne apprendra la bonne approche de l'organisation et de la conception du code de notre part. Cela ne va nulle part.
Nous enseignerons également comment travailler avec l'héritage. Il s'agit également d'une compétence très importante. Vous ne pouvez pas penser que vous viendrez et commencerez à concevoir le meilleur système au monde. Non. Le plus souvent, en venant en entreprise, vous vous retrouvez sur un produit fini. [ — .], [ — .].
— . 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 — .], , - .
— , .
— , , . , , , . , , , .
, , , .