Один наш коллега и по совместительству известный, но очень скромный преподаватель ИжГТУ, задался вопросом: "Как обучать студентов хорошим технологиям разработки?" Дискуссия по поднятой теме внутри НПО "Компьютер" длилась не один день. Сегодня мы хотим предложить этот вопрос нашим читателям.
Небольшая преамбула: собственно, с чего вдруг возник такой вопрос.
Наверное, многие из тех, кому приходилось заниматься подготовкой вновь приходивших сотрудников сразу из студенческой среды, согласятся, что студенты, не имевшие во время учебы приличной практики в како-нибудь софтверной компании, долгое время пишут программы как лабораторные работы: без тестов, без комментариев, не используя контроль версий (или долго к нему привыкая), с некоторым трудом привыкая к тому, что необходимо учитывать, что над проектом работаешь не один. Т.е. студенты выходят из стен ВУЗа не имея представления и навыков так называемой prodaction разработки.
Другая большая проблема - отсутсвие навыков работы с чужим кодом. Сюда я отношу и умение быстро разбираться с чужим кодом, искать в нем ошибки, перенимать предложенный стиль, разбираться в алгоритме и нюансах поведения и т.д.
И первая и вторая задача, по большому счету, решается просто набором опыта, “набиванием рук”, однако на это, конечно же, нужно время, причем, чем больше, тем лучше. Кроме того, мне кажется, что для данных областей в принципе бессмысленно преподавать отдельные курсы (например, что-то вроде курса “Технологии разработки”, который читается на специальности 22.04, сейчас это 22.03.05) - нужно элементы организации процессов разработки включать в большинство курсов по разработке, причем в таком виде, когда работа уже организована, и студенты просто подключаются к какому-то большому проекту, а в качестве лабораторной работы делают некоторую небольшую часть, причем в отдельном branch, где ничего сломать не смогут.
Собственно идея.
Думаю, основная идея как решить приведенные мною проблемы уже ясна, но для полноты я все-таки ее еще раз сформулирую.
Итак, за основу для выполнения лабораторных и практических работ берутся не отдельные независимые задачи, а задачи по доработке (очень ограниченной, конечно же, т.е. объем работ практически не меняется по сравнению с лабораторными!) или модификации частей какаого-то большого общего проекта.
Для работы разворачивается сервер хранения версий, который позволяет делать отдельные независимые ветви всего проекта или отдельных его частей. Для каждого студента (группы студентов) создается отдельный branch (на основную ветку, еонечно же, у них нет прав), который они и могут дорабатывать. Далее эту ветку они могут копировать локально к себе или работать непосредственно с центральным репозиторием - это уже детали.
Перед защитой своей работы все изменения должны быть внесены в их ветку проекта. Обязательными условиями, для выполнения работ являются:
собираемость общего проекта (т.е. то, что с внесенными изменениями не ломается основная ветка);
наличие модульных или функциональных тестов (типы тестов, степень покрытия и другие параметры могут меняться в разных проектах - это оговаривается отдельно);
выдерживаение используемого в общем проекте стиля программирования (оговаривается заранее);
наличие хороших комментариев, а если используется автодокументирование, то и возможность собрать справку;
что-то еще … Ну например, доработка документации или фиксация изменений в их релизе в некотором инструменте для документирования. В общем, сейчас с ходу не придумаю, но думаю, найдется еще не мало…
Думаю, понятно, что от такого подхода могут выиграть студенты, это я уже писал.
Для преподавателей здесь полезным может быть, например:
Возможность оперативно и удаленно контролировать текущую работу. В том смысле, что студентам не надо таскаться с ноутами или еще хуже - распечатками на лекции, чтобы показать что они сделали, а можео и вовсе разбивать работу на этапы и на базе простого трекера отслеживать что кем делано (особенно это полезно для преподавателей ведущих курсовые - работы на курсовых обычно не маленькие, а студенты, обычно, все курсовые отодвигают на конец сессии…).
Возможность организовать “передачу опыта”, закрепив за каждой небольшой группой студентов, “шефа” со старшего курса или из аспирантов. В задачи “шефа” как раз входило бы отслеживание сроков работ, ревью кодов, какие-то небольшие консультации (т.е. нечто сродни работы тим-лида, но не в полной мере). Думаю, что для “шефов” это более чем полезный опыт. За преподавателем остался бы конечный прием, консультирование по вопросам реализации и т.д.
Возможность привлекать студентов к научной/практической работе, которую ведет сам преподаватель. Как показывает практика на лабах/курсовых далеко не уедешь, а тут у студентов, поработавших с проектом, будет возможность в дальнейшем вести какие-то его части в качестве полноценных тим-лидов или “постоянных шефов”.
Конечно же, у такого подхода есть много “но”. Вот самые очевидные:
Далеко не все курсы могут быть сориентированы на использование в учебном процессе большого проекта - слишком много всплывет ненужных нюансов, а курс нужен только для того, чтобы дать основы. Например, большинство академических курсов по ИИ - это солянка из кучи разных направлений и чтобы студенты смогли себя везде попробовать, нужны маленькие разнообразные лабораторные. Однако, правда, никто при этом не запрещает использовать всю перечисленную инфраструктуру - просто проекты будут разные.
Как минимум на первое время (пока не устаканится) это будет очень сильно нагружать преподавателя. Да и вообще, смена всего подхода к работе с лабораторными это мучительно и затратно по времени и силам.
Далеко не все проекты могут служить образцами для подражания, с которыми бы имело смысл работать студентам. Да и вообще не все проекты подходят для подобной работы (какие проекты, по моему мнению, подходят чуть ниже).
Такой подход тебует, чтобы со всеми подходами и инструментами, хотябы поверхносттно, студенты должны знакомиться до начала работы, а это значит, что нужно либо серьезно переделывать программы (сейчас во всех программах, что я видел, курсы связанные с технологией программирования идут ближе к концу учебы, на 4-5 курсе, а кому оно там уже нужно?), либо это ляжет дополнительной нагрузкой на преподавателей, которые будут вести первые курсы по подобной методике.
Увы, любая ломка устоев требует больших усилий, и, если говорить, например, про кафедру ПО в ИжГТУ, то, я боюсь, на подобные изменения согласятся, дай бог, 2-3 преподавателя. Остальных и текущий вариант вполне устраивает.
наверняка еще что-то, чего с ходу не видно ….
В общем, основные вопросы в каких курсах и какие проекты можно было бы использовать. Начнем с проектов:
В идеале, это должен быть проект, который на постоянной основе поддерживается кем-то из сотрудников кафедры. Внешний или внутренний, это уже не столь важно, хотя внешний, конечно же - на много интереснее, т.к. дает дополнительные стимулы к развитию и поддержке (особенно, если он будет постоянно использоваться и развиваться).
Как минимум для начала, пока еще нет навыков групповой работы, лучше всего, если это будет проект состаящий из множества слабо связанных частей, т.е. очень модульный. В первую очередь это всевозможные системные библиотеки: мат. вычислений, структур данных и пр.
Желательно, чтобы проект был хорошо документирован, и выдержан в едином стиле. Например, boost, хоть и может быть использован где угодно (т.к. представляет собой “библиотеку для всего”), но представляет, по сути, плохо документированную солянку из разных проектов, абсолютно не связанных между собой. В результате даже функциональность там местами повторяется…
Теперь, для каких курсов можно попробовать подобный подход. Если двигаться по определению типа проекта, то, например:
Курс по струтурам данных и классическим алгоритмам (проект - доработка библиотеки структур данных и классических алгоритмов).
Курс численных методов (проект - доработка библиотеки численных методов).
Курс ОС (проект - доработка отдельных узлов небольшой открытой ОС).
Первые два вообще можно считать идельными: их и достаточно просто разделить на отдельные задания и модульные тесты для них писать очень просто. С последним сложнее, но тоже можно выкрутиться.
Собственно, вопросы, коллеги.
Ну, во-первых, как вы считаете, существуют ли вообще описанные мною проблемы или это мне только кажется?
Как вам предложенный метод в целом? Будет ли он полезен (даже если проблемы нет), стоит ли вообще заморачиваться на этот счет?
Какие еще вы видите варианты развития этой идеи, ее плюсы и минусы?
На каких курсах можно было бы практиковать подобный подход (если Вы заканчивали 22.04, то назовите просто курс, а если нет, то в паре слов о чем он), и в каком виде (какие проекты, задания, как организовать процесс)?
В общем, буду рад любым разумным дополнениям/критике.
Дополнение: Хочу обратить внимание, что под “проектами” подразумеваются некоммерческие программные разработки с открытыми исходными кодами. А вот должны ли это быть внешние (по отношение к университету) или внутренние проекты как раз вопрос на проработку.
