28 января 2009 г.

Идея: как обучать студентов хорошим технологиям разработки

Один наш коллега и по совместительству известный, но очень скромный преподаватель ИжГТУ, задался вопросом: "Как обучать студентов хорошим технологиям разработки?" Дискуссия по поднятой теме внутри НПО "Компьютер" длилась не один день. Сегодня мы хотим предложить этот вопрос нашим читателям.

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

Наверное, многие из тех, кому приходилось заниматься подготовкой вновь приходивших сотрудников сразу из студенческой среды, согласятся, что студенты, не имевшие во время учебы приличной практики в како-нибудь софтверной компании, долгое время пишут программы как лабораторные работы: без тестов, без комментариев, не используя контроль версий (или долго к нему привыкая), с некоторым трудом привыкая к тому, что необходимо учитывать, что над проектом работаешь не один. Т.е. студенты выходят из стен ВУЗа не имея представления и навыков так называемой prodaction разработки.

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

И первая и вторая задача, по большому счету, решается просто набором опыта, “набиванием рук”, однако на это, конечно же, нужно время, причем, чем больше, тем лучше. Кроме того, мне кажется, что для данных областей в принципе бессмысленно преподавать отдельные курсы (например, что-то вроде курса “Технологии разработки”, который читается на специальности 22.04, сейчас это 22.03.05) - нужно элементы организации процессов разработки включать в большинство курсов по разработке, причем в таком виде, когда работа уже организована, и студенты просто подключаются к какому-то большому проекту, а в качестве лабораторной работы делают некоторую небольшую часть, причем в отдельном branch, где ничего сломать не смогут.

Собственно идея.

Думаю, основная идея как решить приведенные мною проблемы уже ясна, но для полноты я все-таки ее еще раз сформулирую.

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

Для работы разворачивается сервер хранения версий, который позволяет делать отдельные независимые ветви всего проекта или отдельных его частей. Для каждого студента (группы студентов) создается отдельный branch (на основную ветку, еонечно же, у них нет прав), который они и могут дорабатывать. Далее эту ветку они могут копировать локально к себе или работать непосредственно с центральным репозиторием - это уже детали.

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


  • собираемость общего проекта (т.е. то, что с внесенными изменениями не ломается основная ветка);
  • наличие модульных или функциональных тестов (типы тестов, степень покрытия и другие параметры могут меняться в разных проектах - это оговаривается отдельно);
  • выдерживаение используемого в общем проекте стиля программирования (оговаривается заранее);
  • наличие хороших комментариев, а если используется автодокументирование, то и возможность собрать справку;
  • что-то еще … Ну например, доработка документации или фиксация изменений в их релизе в некотором инструменте для документирования. В общем, сейчас с ходу не придумаю, но думаю, найдется еще не мало…

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

    Для преподавателей здесь полезным может быть, например:
  • Возможность оперативно и удаленно контролировать текущую работу. В том смысле, что студентам не надо таскаться с ноутами или еще хуже - распечатками на лекции, чтобы показать что они сделали, а можео и вовсе разбивать работу на этапы и на базе простого трекера отслеживать что кем делано (особенно это полезно для преподавателей ведущих курсовые - работы на курсовых обычно не маленькие, а студенты, обычно, все курсовые отодвигают на конец сессии…).
  • Возможность организовать “передачу опыта”, закрепив за каждой небольшой группой студентов, “шефа” со старшего курса или из аспирантов. В задачи “шефа” как раз входило бы отслеживание сроков работ, ревью кодов, какие-то небольшие консультации (т.е. нечто сродни работы тим-лида, но не в полной мере). Думаю, что для “шефов” это более чем полезный опыт. За преподавателем остался бы конечный прием, консультирование по вопросам реализации и т.д.
  • Возможность привлекать студентов к научной/практической работе, которую ведет сам преподаватель. Как показывает практика на лабах/курсовых далеко не уедешь, а тут у студентов, поработавших с проектом, будет возможность в дальнейшем вести какие-то его части в качестве полноценных тим-лидов или “постоянных шефов”.

    Конечно же, у такого подхода есть много “но”. Вот самые очевидные:
  • Далеко не все курсы могут быть сориентированы на использование в учебном процессе большого проекта - слишком много всплывет ненужных нюансов, а курс нужен только для того, чтобы дать основы. Например, большинство академических курсов по ИИ - это солянка из кучи разных направлений и чтобы студенты смогли себя везде попробовать, нужны маленькие разнообразные лабораторные. Однако, правда, никто при этом не запрещает использовать всю перечисленную инфраструктуру - просто проекты будут разные.
  • Как минимум на первое время (пока не устаканится) это будет очень сильно нагружать преподавателя. Да и вообще, смена всего подхода к работе с лабораторными это мучительно и затратно по времени и силам.
  • Далеко не все проекты могут служить образцами для подражания, с которыми бы имело смысл работать студентам. Да и вообще не все проекты подходят для подобной работы (какие проекты, по моему мнению, подходят чуть ниже).
  • Такой подход тебует, чтобы со всеми подходами и инструментами, хотябы поверхносттно, студенты должны знакомиться до начала работы, а это значит, что нужно либо серьезно переделывать программы (сейчас во всех программах, что я видел, курсы связанные с технологией программирования идут ближе к концу учебы, на 4-5 курсе, а кому оно там уже нужно?), либо это ляжет дополнительной нагрузкой на преподавателей, которые будут вести первые курсы по подобной методике.

    Увы, любая ломка устоев требует больших усилий, и, если говорить, например, про кафедру ПО в ИжГТУ, то, я боюсь, на подобные изменения согласятся, дай бог, 2-3 преподавателя. Остальных и текущий вариант вполне устраивает.
    наверняка еще что-то, чего с ходу не видно ….

    В общем, основные вопросы в каких курсах и какие проекты можно было бы использовать. Начнем с проектов:
  • В идеале, это должен быть проект, который на постоянной основе поддерживается кем-то из сотрудников кафедры. Внешний или внутренний, это уже не столь важно, хотя внешний, конечно же - на много интереснее, т.к. дает дополнительные стимулы к развитию и поддержке (особенно, если он будет постоянно использоваться и развиваться).
  • Как минимум для начала, пока еще нет навыков групповой работы, лучше всего, если это будет проект состаящий из множества слабо связанных частей, т.е. очень модульный. В первую очередь это всевозможные системные библиотеки: мат. вычислений, структур данных и пр.
  • Желательно, чтобы проект был хорошо документирован, и выдержан в едином стиле. Например, boost, хоть и может быть использован где угодно (т.к. представляет собой “библиотеку для всего”), но представляет, по сути, плохо документированную солянку из разных проектов, абсолютно не связанных между собой. В результате даже функциональность там местами повторяется…

    Теперь, для каких курсов можно попробовать подобный подход. Если двигаться по определению типа проекта, то, например:
  • Курс по струтурам данных и классическим алгоритмам (проект - доработка библиотеки структур данных и классических алгоритмов).
  • Курс численных методов (проект - доработка библиотеки численных методов).
  • Курс ОС (проект - доработка отдельных узлов небольшой открытой ОС).

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

    Собственно, вопросы, коллеги.

    Ну, во-первых, как вы считаете, существуют ли вообще описанные мною проблемы или это мне только кажется?

    Как вам предложенный метод в целом? Будет ли он полезен (даже если проблемы нет), стоит ли вообще заморачиваться на этот счет?

    Какие еще вы видите варианты развития этой идеи, ее плюсы и минусы?

    На каких курсах можно было бы практиковать подобный подход (если Вы заканчивали 22.04, то назовите просто курс, а если нет, то в паре слов о чем он), и в каком виде (какие проекты, задания, как организовать процесс)?

    В общем, буду рад любым разумным дополнениям/критике.

    Дополнение: Хочу обратить внимание, что под “проектами” подразумеваются некоммерческие программные разработки с открытыми исходными кодами. А вот должны ли это быть внешние (по отношение к университету) или внутренние проекты как раз вопрос на проработку.
  • 26 января 2009 г.

    Главное, чтобы человек был хороший

    Как мы и обещали — публикуем некоторые истории наших сотрудников о том, как они устраивались на работу в НПО, как проходили собеседования и с какими подводными камнями сталкивались. Подкин Андрей, ведущий специалист по технологиям программирования, рушит шаблоны, рассказывая о действительно важных качествах любого специалиста.
    Npo.Comp

    В мою бытность сотрудником одного из отделов разработки НПО «Компьютер» я участвовал в собеседованиях с кандидатами на работу. Именно тогда мне удалось, что называется, на своей шкуре оценить правильность позиции Джоэля Спольски («Главное, чтобы человек был толковый и умел доводить дело до конца»).

    К примеру, когда я оценивал уровень знаний кандидатов в Delphi, то почти у всех он был такой, что требовалось проводить дополнительное обучение (даже, если кандидат априори оценивал себя по высшему уровню, что, вообще говоря, наблюдалось нередко). Так, один кандидат рассказывал, что в знании Delphi он достиг заоблачных высот, устал от программирования, а потому ушел в руководители. Теперь же он желал вернуться в программирование. Но слушать его рассуждения о предлагаемых примерах кода — поверьте моему 11-летнему опыту программирования — без слез было решительно невозможно.

    Мораль истории такова: мне ни разу не удалось увидеть готового специалиста. А если всех надо учить, то ситуация получается довольно интересная: мне как наставнику больше нравится учить людей, которые обладают, может, и не такими большими знаниями сейчас, но могут и хотят учиться. Если человек прекрасно разбирается в ООП (понимает что-такое полиморфизм, умеет применять design patterns и когда слышит слово «рефакторинг» не прячется, а начинает обсуждать конкретные приемы), то пусть он не знает Delphi или .NET — обучить его конкретным платформам разработки не так уж и сложно. И вложив сравнительно немного, через несколько месяцев можно получить как раз того самого готового специалиста высочайшего уровня.И, к слову, вспомнилась еще одна история — про «гендерную» дискриминацию.

    Мало кто считает, что девушка как программист может составить конкуренцию молодому человеку. А если и может — это будет единичный случай. Вот, что я по этому поводу вспомнил. Однажды было то ли 6, то ли 7 кандидатов (3 девушки и 3 или 4 молодых человека), из которых предполагалось взять на работу всех, но в разные отделы, и мне (вместе с моим непосредственным начальником — руководителем отдела) предложили провести серию собеседований. Мы честно подготовились и провели их по всем правилам, пытаясь по ходу собеседований держаться максимально беспристрастно. По итогам нас ожидал легкий шок: девушки по толковости обогнали молодых людей если не на порядок, то все же очень значительно. Ситуация для кандидатов в программисты, мягко говоря, необычная.

    Одним словом, ни образование, ни пол на шансы устроиться работать в НПО «Компьютер» не оказываются принципиального влияния. Главное, чтобы человек был хорошим.

    22 января 2009 г.

    Новое начало

    Всем привет.

    Мы решили начать Новый год нашего блога в этот чудесный день - 22.01, - когда "все настоящие ИТшники, мастера (и сочувствующие) PDP-11, ассемблеров и проектирования печатных плат отмечают свой специальный праздник", по справедливому комментарию одного выпускника специальности 2201 ИжГТУ. Кроме того, в этот день родились Сергей Эйзенштейн и Лев Ландау; Барак Обама сутки как президент США; а европейские страны вовсю согреваются российским газом.

    Закончились новогодние и рождественские каникулы, заканчивается уже вторая рабочая неделя, неумолимо движется к своему логическому завершению месяц январь. Но время и место для радости есть всегда: давайте на минутку закроем глаза и вспомним, как здорово мы провели эти январские дни. А теперь откроем и посмотрим, как дружно нас - НПО "Компьютер" - поздравляли наши клиенты и партнеры.

    Собственно, то, что вы сейчас видите, это лишь малая часть присланных нам открыток, а именно - открытки бумажные. Электронные же разлетелись меж сотрудников со скоростью почты - собрать их вместе и представить на ваш суд почти невозможно. )
    Зато мы по-прежнему можем и будем публиковать здесь все самое интересное из нашей неофициальной кухни, устраивать конкурсы и потехи, и, конечно, обсуждать всю эту феерию в самой демократичной форме.

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

    Следите за обновлениями и до встречи!