Как Валера Взял В Команду Стажера И Начал Учить Его Дизайну



Начинать Валера все еще работает руководителем группы в одной крупной ИТ-компании в одной крупной среднеазиатской стране.

В разработке несколько крупных проектов, и, судя по сияющим лицам специалистов по маркетингу и продажам, их скоро станет намного больше.

Валера вдохновлен той же идеей из приглашения на встречу, которое он получил от технического директора.

Темой встречи стало расширение направления образовательных систем.

На следующее утро ключевые сотрудники отдела собрались в конференц-зале.

Технический директор (для тех, кто с ним еще не знаком, его зовут Иван) сразу вник в суть дела: «Всем привет! Как вы знаете, некоторое время назад мы поставили перед собой цель расширить свое присутствие на рынке и с этой целью открыли новый офис продаж.

Что ж, эта стратегия сработала.

Через месяц мы подписываем договор на разработку и внедрение платформы дистанционного образования.

Проект очень интересный, но речь пока не об этом.

Чтобы осуществить это, нам необходимо срочно сформировать новую команду по направлению образовательных систем».

«Упс!» - пронеслось в голове Валеры.

Он четко понимал, что свободных разработчиков сейчас на рынке очень мало, и найти необходимое их количество за месяц будет практически невозможно.

Этими мыслями он поделился со своими коллегами.

Посовещавшись некоторое время, участники встречи пришли к следующему решению.

В новую команду будут выделены три сильных специалиста из других реферальных команд. И во все команды войдут стажеры – вчерашние студенты или пенсионеры, которых нужно будет пройти обучение.

Обучайтесь быстро, чтобы не повлиять на обязательства по всем проектам.

Валера становится лидером новой команды.

Решено.

Через две недели в новый офис новой команды нерешительно вошел молодой парень.

Он подошел к столу Валеры и представился: «Ержан — ваш стажер».

Валера впервые увидел человека, с которым раньше только переписывался по электронной почте, давал задачи и проверял их решения.

И с которым ему предстоит долгое время работать над одним из важнейших проектов компании.

— Садитесь, — махнул рукой наш герой в сторону стула.

«Я тот самый Валера, который последние полторы недели мучает тебя заочно.

В нашей компании существует правило, что за каждым стажером закрепляется наставник.

Он помогает обучающемуся в выполнении заданий, дает рекомендации, что и в каком порядке изучать.

В общем, моя задача рассказать вам все, что знаю сама.

По всем вопросам обращайтесь».

Ержан улыбнулся: «Отлично! Думаю, это поможет мне гораздо быстрее вникнуть в курс дела и начать решать реальные задачи».

Валера отметил про себя, что у парня правильная мотивация.

Мотивация мотивацией, но Валере еще нужно было понять, как за несколько недель из человека, побитого отечественной системой образования, превратиться в специалиста, способного самостоятельно решать проблемы.

И решать их качественно и в срок.

Для этого вам нужно будет систематизировать весь опыт, который Валера накопил за долгие годы своей карьеры, и постараться побыстрее передать его стажеру.

Задача непростая, но оно того стоит. Слушай, кто-нибудь потом напишет об этом книгу.

Вообще, на чем стоит сконцентрироваться? Что отличает плохого программиста от хорошего? Почему вы боитесь дать задание одному, зная, что вам придется постоянно подключаться, следить за статусом и переписывать половину кода, в то время как вы дали задание другому, объяснили детали и спокойно занимались своими делами? Может быть, один из них хорошо знает язык программирования, а другой не очень? Нет, это не то.

Валера насмотрелся на людей, которые изучили не одну книгу по языку программирования, но не смогли спроектировать простое приложение.

Итак, погодите.

дизайн.

Вот он! Хороший разработчик должен уметь проектировать.

И вам нужно в первую очередь сконцентрироваться на развитии этого навыка.

Теперь нам нужно передать это Ержану.

Валера начал неожиданно: «Требования всегда меняются».

Увидев удивленный взгляд своего собеседника, он продолжил: «Ваша главная задача как разработчика — реализовать требования пользователей создаваемой системы.

Итак, пользователи — существа очень непостоянные и никогда сразу не знают, что им нужно.

Только после того, как они увидят первую версию системы, их требования начинают проясняться и зачастую кардинально меняются.

И писать код следует так, чтобы каждый раз, когда вы узнаете, что функционал должен работать по-другому, вы были счастливы.

Потому что созданный вами дизайн позволит легко реализовать эти требования, и система станет немного лучше».

Валера еще некоторое время объяснял Ержану, почему так важен правильный дизайн.

В начале своей карьеры он говорил о работе с плохо спроектированными системами.

Необходимость хотя бы малейшего изменения в них вызывала панику среди всего коллектива.

Ведь никто не знал, где после этого изменения система сломается.

И хорошо, если испытатели сообщат о поломке.

Ситуации, когда об этом сообщали бизнес-пользователи, остались не среди самых приятных воспоминаний Валеры.

Валера резюмировал: «Система, которую мы начнем разрабатывать через несколько недель, большая и сложная.

И вы не будете сидеть и исправлять ошибки.

Вы будете полноценным участником разработки.

Так что готовьтесь погрузиться в мир гибкого объектно-ориентированного проектирования.

«Всегда готов!» — фраза, услышанная в каком-то фильме, выскочила из подсознания Ержана.

Он тоже подумал, что ему здесь начинает нравиться.



Первый день.

Первые истины

Когда на следующий день Ержан пришел на работу, первое, что он увидел, были две книги, лежащие возле монитора.

«Идеальный код» Стивена МакКоннелла и «Идеальный программист» Роберта Мартина.

Попросив Валеру объяснить, почему на столе оказались именно эти книги, он услышал в ответ: «Первая книга рассказывает о качествах хорошего кода.

Вторая книга рассказывает о качествах хорошего программиста.

Мне кажется, они идеально дополняют друг друга.

Одно не может существовать без другого.

Прочитав эти книги, вы сможете значительно ускорить свое развитие.

Плюс хорошие книги вдохновляют. Это важно для успеха».

Закончив с книгами, Валера вкратце объяснил, какую систему они будут разрабатывать.

Не так давно Министерство образования создало Институт дистанционного образования, перед которым была поставлена задача разработать новую модель предоставления образовательных услуг.

В результате родилась концепция платформы, на которой преподаватели разных вузов публикуют свои курсы, а студенты, исходя из учебной программы, выбирают необходимый им набор.

Каждый преподаватель указывает цену за прохождение своего курса.

А студенты, исходя из соотношения цены и качества, выбирают для себя лучший вариант. В институте полагают, что этот механизм будет стимулировать конкуренцию между преподавателями и в целом повысить качество дистанционного образования.

«И наша компания должна разработать платформу для запуска этой модели, — продолжила пояснение Валера, — Это будет веб-решение и мы будем писать его на платформе .

NET и языке C# в частности.

Предлагаю сейчас обсудить модули системы и выбрать тот, в разработке и проектировании которого вы будете участвовать».

После небольшого обсуждения коллеги решили, что это будет модуль проверки выполненных заданий.

Ноутбук Ержана по-прежнему находился в руках специалистов технической службы, которые установили на него все необходимые инструменты.

Поскольку его сдадут только завтра, Валера решил использовать это время не для обсуждения деталей конкретного задания, а для того, чтобы донести до Ержана те вещи, которые должен понимать каждый программист. И чем раньше он их поймет, тем лучше.

Валера начал со своего любимого вопроса: «Что такое объектно-ориентированное программирование и зачем его придумалиЭ» Ержан удивился простоте вопроса и сразу ответил: «Это знает любой студент. Объектно-ориентированное программирование позволяет описывать объекты реального мира в коде.

Предположим, есть машина, у нее есть колеса и другие механизмы.

Мы можем создать соответствующий класс и использовать его для управления автомобилем и использовать в программе».

Пришло время Валеры: «То, что ты сказал, правда.

Но это не главное.

Фактически, основная цель ООП — борьба со сложностью.

Позвольте мне объяснить, что я имею в виду.

До появления ООП доминирующей моделью разработки было процедурное программирование.

Но по мере усложнения систем процедурный подход начал давать сбои.

Поддержание и разработка кода стали отнимать много времени.

А всё потому, что процедуры не позволяли адекватно отделить компоненты системы друг от друга; изменение одних процедур повлияло на поведение других.

ООП было придумано для решения этой проблемы.

Объектный подход позволяет разделить программу на независимые и изолированные компоненты.

И изменение одних не влияет на поведение других.

Кроме того, человеческий мозг очень слаб и не может охватить всю систему в один момент времени.

А класс позволяет сконцентрироваться на отдельной части системы, разобраться в ней и работать с ней, снижая общую сложность задачи».

Подумав пару минут и вспомнив свой первый проект, Валера добавил: «Важно также понимать, что использование ООП-языка не дает автоматически всех этих преимуществ.

Я видел, как на C# был написан полностью процедурный код со всеми сопутствующими проблемами.

Вам необходимо понимать объектно-ориентированное программирование и объектно-ориентированное проектирование и уметь правильно их использовать.

Тогда вас ждет счастливая и плодотворная карьера.

И не думайте, что сейчас используется только ООП.

Существуют и другие подходы, каждый из которых используется в своей области.

Но для нас, как для разработчиков корпоративных систем, ООП очень важно».

Начав с ООП, следующим логичным шагом было рассказать Ержану о свободной связи (или, если использовать английскую терминологию, «свободной связи»).

Классы позволяют разделить системный код на отдельные части — это хорошо.

Но еще важнее, чтобы эти части знали друг о друге как можно меньше и были как можно более независимыми.

Тогда изменения в одном классе не повлияют на другой класс.

Кроме того, систему будет удобно разрабатывать команда программистов, распределяя между ними независимые компоненты.

Слабая связь — это качество, к которому следует стремиться изо всех сил.

Но сделать это сложнее, чем кажется.

Связи между компонентами системы могут проявляться по-разному, как явно, так и неявно.

После некоторого времени объяснений Валера взглянул на задумчивое лицо Ержана и поспешил его успокоить: «Не волнуйтесь, если вы не до конца понимаете, о чем я говорю.

Мы в компании являемся поклонниками гибких методов разработки и придерживаемся такого же подхода в дизайне.

Начиная с завтрашнего дня, вы приступите к настоящей задаче и постепенно оттачиваете свои навыки.

На сегодня теории достаточно.

Предлагаю вам прогуляться по офису, посмотреть, как здесь все устроено, познакомиться с людьми».

Ержан поспешил последовать совету Валеры.

Оставшееся время он провел в общении со своими новыми коллегами.

И каждый из них дал Ержану частичку новой информации.

Так он узнал, что существует волшебная аббревиатура SOLID, описывающая основные принципы объектно-ориентированного проектирования.

А еще оказывается, что умные люди придумали готовые рецепты решения различных задач по программированию.

Их называют шаблонами проектирования.

Конечно, Ержан не сразу многое понял; у него было только стойкое желание во всем этом разобраться и научиться писать крутой софт. Так прошел первый день Ержана в новой компании.

После того, как часы показали 18:00, он попрощался с коллегами и направился домой.

Но через несколько минут он вернулся, взял со стола «Совершенный код», еще раз помахал всем рукой и вышел из кабинета.

Продолжение следует… P.S. Это первая статья в серии статей о тимлиде Валере, стажере Ержане и гибком дизайне.

В следующих статьях будет описан тернистый путь, на котором Ержану придется реализовывать требования, писать много кода и одновременно изучать принципы гибкого объектно-ориентированного проектирования.

П.

П.

С.

Самую первую статью о Валере можно найти здесь.

Здесь .

П.

П.

П.

С.

Все сходства с реальными людьми и событиями вымышлены.

Теги: #дизайн #ООП #идеальный программист #Идеальный код #Валера #история #Разработка веб-сайтов #программирование #Идеальный код #дизайн и рефакторинг #ООП

Вместе с данным постом часто просматривают: