Этот длинный текст посвящен моему опыту обучения начинающих разработчиков Ruby и Rails. Однако идеи должны работать с другими объектно-ориентированными языками.
TL; DR: Учите людей создавать маленькие простые вещи. После этого все остальное становится намного проще.
На момент написания этой статьи я обучал разработчиков Ruby on Rails около 3 лет и занимался разработкой около 6 лет (насколько я знаю, не так уж и долго). В основном это устаревшие приложения, а это означает, что моя основная работа - рефакторинг этого страшного кода, который вы просто хотите закрыть и уйти как можно быстрее. Время от времени мы разрабатываем новые вещи с нуля. Руководство считает его проактивным. На самом деле мы просто сохраняем рассудок.
В университете я изучал ООП, наблюдая, как класс Student наследуется от класса Person, унаследованного от класса LivingBeing, наследуемого от Thing класс. Потрясающий! Итак, ООП - это все о наследовании, не так ли? Это имеет смысл, если вы рассмотрите статью Классификация и таксономия библиотекарей, с которой, как я полагаю, началась объектная ориентация (следовало уделять этому больше внимания). класс). Фактически, наследование является частью трех столпов ООП: инкапсуляция, специализация и полиморфизм (по специализации ). Сложные имена, правда? Это довольно быстро усложняется.
Как только вы начнете больше узнавать о ООП и передовых методах, вы познакомитесь с шаблонами проектирования. Ваш класс слишком велик? Для этого есть образец. Ваш код становится сложным? Эй, вы можете просто использовать один из этих шаблонов проектирования программного обеспечения для решения своей проблемы: Creational, Abstract, Builder, Factory, Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Цепочка ответственности, команда, интерпретатор, итератор, посредник, сувенир, наблюдатель, состояние, стратегия, шаблон и посетитель! Это должно быть довольно легко для новичка, не так ли?
Итак, в моей нынешней компании мы нанимаем людей прямо из университета. На самом деле мы ИТ-специалисты университета, так что в этом есть смысл. Большинство из них все еще учатся на втором курсе или около того, не имея большого опыта программирования. У компании (также известной как университет) не так много денег, поэтому, как только люди немного научатся на работе, они получат более выгодные предложения в другом месте, и мы получим новую партию новых разработчиков. И вскоре они должны коснуться производственного кода. Это означало, что наше обучение должно быть эффективным. Важно понимать, что эффективно не обязательно означает быстро.
Как нам подходить к обучению?
Обучаете Руби?
Нет. В Интернете достаточно хороших бесплатных руководств по Ruby. Есть Ruby Koans, Code School, Codecademy. Есть деньги? Об этом тоже написано много замечательных книг. То же самое и с Rails. Мы пытались проводить собственные вводные курсы, но это было полным провалом. Просто доверяйте сообществу.
Вместо того, чтобы сосредоточиться на том, чтобы новички изучали Ruby и Rails в первые несколько дней и заставляли их писать производственный код вместе с нами (что, очевидно, не будет работать так хорошо), мы решили действовать очень медленно. Мы начали сжигать примерно месяц или два (или три) на тренировках. Наша первая и основная тема? Объекты.
Представьте себе класс. Сколько предметов вы видите в этом классе? Но стиль объектно-ориентированного программирования: ученик - это объект, а учитель - это объект. Урок - это объект. Не каждый объект виден, не каждый объект является «вещью». Некоторые из них можно придумать, чтобы лучше организовать наши мысли. Передовой опыт - это систематизация наших мыслей.
Далее: строить мелочи. У нас есть очень крошечное задание: мы заставляем людей писать код. Само задание не имеет значения. Язык тоже не должен, пока он объектно-ориентированный. Просто выберите что-то, что связано с большой логикой. Мы даем им задание, а затем начинаем задавать вопросы. Что, если бы мы добавили эту логику? Что, если мы удалим эту логику? Помогите им понять последствия решений, связанных с кодированием.
Затем мы начинаем говорить с ними о принципе единой ответственности. Да, я знаю, мы еще не собирались говорить о SOLID. Конечно, назовите это Высокая сплоченность и Низкая связь и объясните, что это такое. Им следует думать об этом при каждом методе, а не только на уровне класса.
Затем мы реорганизуем их код вместе с ними. Мы делаем это просто. Это важно, люди должны понимать, что ООП - это простота. Объекты должны передавать сообщения, объясните им, что это на самом деле означает. Покажите им, насколько просто становится, когда вы начинаете скинуть информацию с нужных объектов, а не переходить к процедурным. Затем мы объясняем им, как они начали многое понимать о GRASP только благодаря этому рефакторингу. Но не зацикливайтесь на жаргоне, здесь важно то, что они узнают о создании мелких вещей. Опять же, Высокая связанность и Низкая связь.
Теперь самое сложное (но для меня самое лучшее). Мы импровизируем с тем, что, по нашему мнению, им нужно научиться, и подкрепляем то, чего, по нашему мнению, им не хватает. Обучение - это сугубо человечное дело, серебряной пули не бывает, вы должны понимать, как думает каждый, кого вы тренируете, чтобы иметь возможность оптимизировать свое и ваше время. С этого момента начните давать более крупные задания, попросите их сделать учебник по рубину и рельсам (но не отказывайтесь от них, пока они это делают), переделайте задания в рубине, попросите их объяснить свои решения по кодированию, чтобы вы можете почувствовать, чего им не хватает.
SOLID станет очень простым для понимания, если вы узнаете об единоличной ответственности и мелочах. MVC? Такой же. Все шаблоны 127365123? Это просто отличные способы решения проблем, основанные на изначальных идеях GRASP. Поскольку они уже хорошо это понимают (каламбур), им будет гораздо лучше изучить все остальное.
Некоторым людям требуется месяц, чтобы пройти текущее обучение, другим - 3 месяца. Мы совсем не против. Судя по опыту, люди с приличной подготовкой будут создавать полезный код намного быстрее, чем без него. Время на обучение в конечном итоге окупится. Плюс то, что людям действительно нравится учиться и они знают, что кто-то уделяет пристальное внимание их кривой обучения. Уже одно это, вероятно, заставляет нас удерживать разработчиков дольше.
Хорошо, я действительно хотел бы знать, как вы обучаете людей там, где вы работаете? На что бы вы хотели походить, но не на что? Не стесняйтесь поделиться своими впечатлениями ниже или поговорите со мной об этом в твиттере. Я уверен, что мы все можем многому научиться друг у друга.
