Как Валера взял в команду стажера и начал учить его проектированию
Начало Валера по-прежнему работает тимлидом в одной большой IT-компании одной большой среднеазиатской страны. В работе находится несколько крупных проектов и, судя по сияющим лицам специалистов по маркетингу и продажам, в скором времени их станет значительно больше. На эту же мысль Валеру наводит приглашение на совещание, которое он получил от технического директора. Тема совещания — расширение направления образовательных систем.На следующее утро в зале для совещаний собрались ключевые сотрудники направления. Технический директор (для тех, кто с ним еще не знаком, — его зовут Иван) сразу перешел к сути вопроса: «Приветствую всех! Как вы знаете, некоторое время назад мы поставили перед собой цель расширить присутствие на рынке и для этого открыли новый офис продаж. Так вот, эта стратегия сработала. Через месяц мы подписываем договор на разработку и внедрение платформы дистанционного образования. Проект очень интересный, но пока не об этом. Чтобы его потянуть, нам нужно срочно формировать новую команду в направлении образовательных систем.«Опачки!» — пронеслось в голове у Валеры. Он ясно понимал, что сейчас на рынке очень мало свободных разработчиков, и за месяц найти нужное их количество будет практически невозможно. Он поделился этими мыслями с коллегами. Подискутировав некоторое время, участники совещания пришли к следующему решению. Из других команд направления в новую будет выделено три сильных специалиста. И во все команды будут приняты стажеры — вчерашние студенты или старшекурсники, которых нужно будет обучить. Обучить быстро, чтобы обязательства по всем проектам не пострадали. Валера становится тимлидом новой команды. Решено.
Через две недели в новый кабинет новой команды неуверенно зашел молодой парень. Он подошел к столу Валеры и представился: «Ержан — ваш стажер». Валера впервые увидел человека, с которым до этого только переписывался в почте, давал задачи и проверял их решение. И с которым ему долгое время предстоит трудится на одном из самых важных проектов компании.
«Присаживайся» — махнул в сторону стула наш герой — «Я тот самый Валера, который заочно мучил тебя последние полторы недели. У нас в компании действует правило, что к каждому стажеру прикрепляется наставник. Он помогает стажеру в выполнении заданий, дает рекомендации, что и в каком порядке изучать. В общем, моя задача — рассказать тебе все то, что я знаю сам. Со всеми вопросами также обращайся ко мне». Ержан улыбнулся: «Супер! Я думаю, это поможет мне в разы быстрее войти в курс дела и начать решать реальные задачи». Валера отметил про себя, что у парня правильная мотивация.
Мотивация мотивацией, но Валере еще нужно было понять, как за несколько недель из человека, потрепанного отечественной системой образования, сделать специалиста, способного самостоятельно решать задачи. И решать их качественно и в срок. Для этого нужно будет систематизировать весь тот опыт, который Валера получил за долгие годы своей карьеры, и постараться быстро передать его стажеру. Задача не простая, но оно того стоит. Глядишь, кто-нибудь потом книгу про это напишет.
А вообще, на чем сконцентрироваться? Что отличает плохого программиста от хорошего? Почему одному ты боишься дать задачу, зная, что придется постоянно подключаться, отслеживать статус и переписывать половину кода, а другому дал постановку, объяснил детали и спокойно пошел заниматься своими делами? Может один из них хорошо знает язык программирования, а другой не очень? Нет, не то. Валера насмотрелся на людей, проштудировавших не одну книгу по языку программирования, но не умевших спроектировать простейшего приложения. Так, подождите… спроектировать… Вот оно! Хороший разработчик обязан уметь проектировать. И на развитии этого навыка нужно сконцентрироваться в первую очередь.
Теперь нужно донести это Ержану. Валера начал неожиданно: «Требования меняются всегда». Увидев удивленный взгляд своего собеседника, он продолжил: «Твоя основная задача как разработчика — реализация требований пользователей создаваемой системы. Так вот, пользователи — очень ветреные создания и никогда сразу не знают, что им нужно. Только после того, как они увидят первую версию системы, их требования начинают проясняться и зачастую сильно меняться. И ты должен писать код так, чтобы каждый раз, когда ты будешь узнавать, что функционал должен работать по-другому, ты радовался. Потому что созданный тобой дизайн позволит легко реализовать эти требования, и система станет чуточку лучше.»
Валера потратил еще некоторое время, объясняя Ержану почему правильное проектирование так важно. Он рассказал о том, как на ранних этапах своей карьеры работал с плохо спроектированными системами. Необходимость даже малейшего изменения в них вызывала панический страх у всей команды. Ведь никто не знал, в каком месте после этого изменения система поломается. И хорошо, если о поломке сообщат тестировщики. Ситуации, когда об этом сообщали бизнес-пользователи, не относились к самым приятным воспоминаниям Валеры.
Валера резюмировал: «Система, которую мы начнем разрабатывать через несколько недель, большая и сложная. И ты не будешь сидеть там на исправлении багов. Ты будешь полноценным участником разработки. Так что будь готов к погружению в мир гибкого объектно-ориентированного проектирования». «Всегда готов!» — выскочила из подсознания Ержана услышанная в каком-то фильме фраза. А еще он подумал, что ему начинает тут нравиться.
Первый день. Первые истины Когда на следующий день Ержан пришел на свое рабочее место, первое, что он увидел, было две книги, лежащие возле монитора. «Совершенный код» Стивена Макконнелла и «Идеальный программист» Роберта Мартина. Попросив Валеру объяснить, почему на столе лежат именно эти книги, в ответ он услышал: «Первая книга рассказывает о качествах хорошего кода. Вторая книга рассказывает о качествах хорошего программиста. Мне кажется, они отлично дополняют друг друга. Одного без другого не бывает. Прочитав эти книги, ты сможешь значительно ускорить свое развитие. К тому же, хорошие книги вдохновляют. Это важно для успеха.«Закончив с книгами, Валера вкратце объяснил, какую систему они будут разрабатывать. Не так давно Министерство образования создало Институт дистанционного образования, перед которым поставило задачу разработать новую модель предоставления образовательных услуг. В результате родилась концепция площадки, на которой преподаватели из разных вузов публикуют свои курсы, а студенты на основании учебного плана выбирают нужный для себя набор. Каждый преподаватель указывает цену прохождения своего курса. И студенты на основании отношения цены и качества выбирают оптимальный для себя вариант. Институт предполагает, что этот механизм приведет к стимулированию конкуренции между преподавателями и в целом повысит качество дистанционного образования.
«А наша компания должна разработать платформу для запуска этой модели» — продолжил объяснять Валера — «Это будет веб-решение и писать его мы будем на платформе .NET и языке C# в частности. Предлагаю сейчас обсудить модули системы и выбрать тот, в разработке и проектировании которого будешь участвовать ты.» После непродолжительного обсуждения коллеги решили, что это будет модуль проверки выполненных заданий.
Ноутбук Ержана до сих пор был у специалистов технической службы, которые устанавливали на него все необходимые инструменты. Так как отдадут его только завтра, Валера решил использовать это время, чтобы пока не обсуждать детали конкретной задачи, а вместо этого донести до Ержана те вещи, понимать которые должен каждый программист. И чем раньше он их поймет, тем лучше.
Валера начал со своего любимого вопроса: «Что такое объектно-ориентированное программирование и для чего его придумали?» Ержан удивился простоте вопроса и тут же ответил: «Это знает любой студент. Объектно-ориентированное программирование позволяет описать в коде объекты реального мира. Предположим, есть автомобиль, у него есть колеса и другие механизмы. Мы можем создать соответствующий класс и с помощью него управлять автомобилем и использовать его в программе.»
Настало время Валеры: «То, о чем ты рассказал, верно. Но это не главное. На самом деле, главная цель ООП — борьба со сложностью. Объясню, о чем я. До появления ООП доминирующей моделью разработки было процедурное программирование. Но по мере того, как системы становились сложнее, процедурный подход начал пробуксовывать. Сопровождение и развитие кода стало занимать очень много времени. А все из-за того, что процедуры не позволяли в должной мере отделить компоненты системы друг от друга; изменение одних процедур влияло на поведение других. ООП придумали для того, чтобы решить эту проблему. Объектный подход позволяет разделить программу на независимые и изолированные компоненты. И изменение одних никак не влияет на поведение других. К тому же, мозг человека весьма слаб и не может в один момент времени охватить всю систему целиком. А класс позволяет концентрироваться на отдельной части системы, понимать и работать с ней, уменьшая общую сложность задачи.»
Подумав пару мгновений и вспомнив свой первый проект, Валера добавил: «Еще важно осознавать, что использование ООП-языка автоматически не дает все эти преимущества. Мне доводилось видеть, как на том же C# писали полностью процедурный код со всеми сопутствующими проблемами. Нужно понимать объектно-ориентированное программирование и объектно-ориентированное проектирование и уметь их правильно использовать. Тогда тебя ждет счастливая и плодотворная карьера. И еще ты не подумай, что сейчас применяют только лишь ООП. Существуют и другие подходы, каждый из которых используется в своей области. Но для нас, как для разработчиков корпоративных систем, ООП очень важно.»
Начав с ООП, следующим логичным шагом было рассказать Ержану о слабой связанности (или loose coupling, если пользоваться англоязычной терминологией). Классы позволяют разделить код системы на отдельные части — это хорошо. Но еще более важно, чтобы эти части как можно меньше знали друг о друге и были максимально независимы. Тогда изменения в одном классе не будут влиять на другой класс. К тому же, систему будет удобно разрабатывать командой программистов, распределив независимые компоненты между ними. Слабая связанность — качество, к которому нужно стремиться всеми силами. Но сделать это сложнее, чем кажется. Связи между компонентами системы могут проявляться разными способами, как явно, так и неявно.
Спустя некоторое время, потраченное на объяснения, Валера посмотрел на задумчивое лицо Ержана и поспешил его успокоить: «Не переживай, если ты не до конца понимаешь, о чем я говорю. Мы в компании фанаты гибких методик разработки и в проектировании придерживаемся такого же подхода. Начиная с завтрашнего дня ты приступишь к реальной задаче и постепенно будешь оттачивать свои навыки. А на сегодня теории хватит. Предлагаю тебе пройтись по офису, посмотреть, как тут все устроено, и познакомиться с людьми.»
Ержан поспешил воспользоваться советом Валеры. Оставшееся время он потратил на общение со своими новыми коллегами. И каждый из них выдавал Ержану порцию новой информации. Так, он узнал, что существует магическая аббревиатура SOLID, описывающая основные принципы объектно-ориентированного проектирования. А еще оказывается умные люди придумали готовые рецепты для решения разных задач программирования. Они называются паттерны проектирования. Конечно, Ержан сразу мало что понял, у него лишь появилось стойкое желание во всем этом разобраться и научиться писать крутой софт.
Так прошел первый день Ержана в его новой компании. После того, как часы показали 18–00, он попрощался с коллегами и направился домой. Но через несколько минут вернулся, взял со стола «Совершенный код», еще раз махнул всем рукой и вышел из кабинета.
Продолжение следует…
P.S. Эта начальная статья из серии статей про тимлида Валеру, стажера Ержана и гибкое проектирование. В следующих статьях будет описан тернистый путь, на котором Ержан будет реализовывать требования, писать много кода и параллельно изучать принципы гибкого объектно-ориентированного проектирования.
P.P. S. Самую первую статью про Валеру можно найти здесь.
P.P. P.S. Все совпадения с реальными людьми и событиями вымышлены.
