Як ми використовували Git, CI і code review в навчальному процесі

В Академічному університеті постійно впроваджуються нові підходи до навчання. Програми, завдання і сам процес змінюються таким чином, щоб надати студентові найбільш повні та актуальні знання, а вчитель – можливість спробувати більш ефективні методи. Так і в минулому семестрі замість того, щоб приймати ДЗ по Java "на А4 і за Гостом", ми з bintree вирішили зробити все "як у великих дядьків": використовувати Git, CI і code review. У цій замітці я поділюся з вами виниклими проблемами, їх рішеннями, плюсами-мінусами такого підходу, а також деякими міркуваннями на майбутнє.

Проблеми стандартних підходів
Питання підготовки і перевірки домашніх і контрольних завдань постало перед нами відразу як тільки ми дізналися, що будемо вести Java. До того моменту ми встигли побувати в якості студентів у різних університетах і спробувати на собі безліч підходів до перевірки ДЗ, наприклад, "принеси на флешці" або "роздрукуй на листочку" (навіть не буду мучитися перерахуванням мінусів цих двох). Найбільш зручним до того часу для нас здавався підхід, який практикувався в АУ: студент надсилає рішення за електропошта і вступає з викладачем листування. Однак і в цьому підході нам не все подобалося:

  1. Багато рутини для викладача: рішення треба перенести до себе на комп'ютер, запустити його, протестувати, отревьюить і написати зауваження в листі.

  2. Додаткове очікування для студента і навантаження для викладача, оскільки повністю переконатися в коректності свого рішення студент може лише пославши його вчитель і дочекавшись від нього відповіді.
Ще одним способом здавання домашніх робіт в АУ було використання спільного сховища; в ньому для кожного студента створювалася окрема директорія, де він виконував домашні роботи. Такий підхід частково позбавляє від рутини, але оскільки викладач все одно перевіряє рішення вручну і пише зауваження поштою, то студенту так само доводиться чекати відповіді, щоб зрозуміти, що в рішенні щось не так.

Трохи подумавши, ми вирішили, що зв'язка "СКВ + загальнодоступний CI-сервер + інструмент для рев'ю коду" позбавить нас від усіх наступних проблем, а використання сторонніх сервісів позбавить ще й від необхідності все це налаштувати.

Організація роботи
Репозиторій було вирішено організувати наступним чином: для кожного завдання завести окрему гілку, яка містить ДОКУМЕНТАЦІЮ з описом того, що треба зробити, а також проект Maven з кістяком рішення і тестами до нього. Студент на початку семестру робить форк репозиторію і надалі просто переключається на потрібну гілку, вносить зміни, коммитит і відправляє pull request. PR автоматично збирається і тестується; якщо тести не проходять, то студенту потрібно доробити роботу; якщо ж все добре, то викладач перевіряє код і залишає зауваження або закриває PR і ставить оцінку.

На відміну від підходу з одним репозиторієм і за директорії на кожного студента, така організація позбавляє від можливих проблем при злитті змін, дозволяє тримати репозиторій в чистоті, а також захищає від вандалізму, хоча, на щастя, з цим прецедентів в АУ поки не було.

Підбір сервісів
З VCS-сервісом все було просто і зрозуміло: Github. Історично так склалося, що і у нас, і у більшості студентів були акаунти саме там; це стало ключовим аргументом "за". Крім того, там же було вирішено робити рев'ю коду і залишати зауваження.

З сервісом CI все було трохи складніше. Спочатку ми вирішили використовувати Travis CI і до деяких пір він нас всіх влаштовував. Проте з часом наші вимоги змінилися: крім відкритих тестів, доступних прямо з репозиторію з завданням, нам захотілося зробити ще й кілька закритих — для того, щоб студенти самостійно подумали над різними тонкощами і граничними випадками. Ми створили закритий репозиторій, змінили білд так, щоб цей репозиторій додавався як submodule в основній, і додали зашифрованих змінних з ім'ям користувача і паролем, щоб Travis міг скопіювати закритий репозиторій. Все було добре рівно до того моменту, поки один з студентів не спробував зробити pull request. Виявилося, що зашифровані змінні недоступні білдів для PR і ми це перевірили. Побіжний пошук за рештою CI-сервісів вивів нас на Semaphore CI. На відміну від Travis, він підтримує завантаження секретних ключів SSH, які можна використовувати в билде для доступу до закритих репозиториям, а це саме те, що нам було потрібно.

Підводні камені і мінуси
Першою проблемою, з якою ми зіткнулися, виявився, як не дивно, сам Git. У хлопців не завжди виходило відправити свої рішення на Github. Причина цього була в тому, що після оновлення свого форк і переходу на нову гілку в якості remote у ній був виставлений основний репозиторій, а не форк. Про тонкощі цієї варто згадати окремо.

Другою проблемою стала відсутність правил іменування комітів і PR. У результаті вже після першої домашки ми отримали купу PR з назвами виду "fix", "1st hw", "моя домашка" і т. п. Все це додатково ускладнювалося тим, що визначити студента по імені користувача було майже неможливо, тому що профіль був заповнений далеко не у всіх. Для наступних завдань ми, звичайно, ввели суворі правила, але в перший раз довелося попотіти.

Основним недоліком даного підходу є те, що не на всі завдання можна написати осмислені тести. Наприклад, одне із завдань на дженерики передбачало написання своєї functional java. Кількість коду в цьому завданні було мінімально, а основна його краса полягала в тому, щоб придумати правильні сигнатури для функцій. Для того щоб його якісно протестувати, довелося б вигадувати складні ієрархії і перевіряти різні хитрі випадки; на це пішло більше часу, ніж на перевірку робіт вручну. Також до завдань, на які писати тести складно і затратно, можна віднести завдання на багатопоточність.

Досить багато людей також зараховують до мінусів доступність чужих рішень – хто захоче писати ДЗ сам, якщо у сусіда вже все готово і навіть здано. Особисто я не вважаю це мінусом, тому що той, хто хоче списати, все одно знайде спосіб це зробити.

Висновки і плани на майбутнє
Досвід застосування такого підходу можна вважати позитивним. Незважаючи на деякі проблеми і нерівності на початку, до середини-кінця семестру все владналося і запрацювало як треба. Нам було зручно перевіряти рішення, і сподіваюся, що хлопцям було зручно їх здавати. У всякому разі, за результатами семестру, невдоволення таким способом здавання ДЗ в моїй групі з десяти чоловік висловив лише один.

Логічним розвитком даного підходу стане додавання інших корисних сервісів, наприклад, автоматичної перевірки стилю або статичного аналізу коду. Також було б дуже зручно навчити Github автоматично призначати ревьюера для PR. І взагалі, немає межі досконалості.

Джерело: Хабрахабр
  • avatar
  • 0

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.