УДК 377:004
Аннотация. Статья посвящена целенаправленному формированию навыков технической коммуникации у студентов колледжей, осваивающих программирование. Традиционная организация лабораторных работ не обеспечивает достаточной речевой практики в профессиональном контексте. В качестве методического решения предлагается поэтапное внедрение практики взаимного код-ревью, адаптированной к условиям среднего профессионального образования. Подробно описывается технология, включающая обучение конструктивной критике, использование уровне-ориентированных шаблонов рецензирования и организацию парной и групповой работы. Приводятся полные описания шаблонов для младших и старших курсов, а также критерии оценки самого процесса рецензирования. Обосновано влияние систематической практики аргументированной обратной связи на качество итоговых проектов и развитие коммуникативной компетентности.
Ключевые слова: техническая коммуникация, код-ревью, обучение программированию, среднее профессиональное образование, методика преподавания, шаблоны рецензирования, конструктивная критика.
Введение
Современные профессиональные стандарты и запросы работодателей к выпускникам ИТ-специальностей всё чаще включают в число обязательных образовательных результатов не только владение языками программирования, но и способность к эффективному профессиональному общению. Техник-программист должен уметь аргументированно объяснить принятое решение, дать коллеге развёрнутую и конструктивную обратную связь на его программный продукт, участвовать в обсуждении дефектов и предлагать обоснованные улучшения. Эта сторона профессии, которую принято относить к так называемым мягким навыкам, в реальной рабочей среде реализуется преимущественно в письменной форме и на русском или английском языке с широким использованием специальной лексики. В системе среднего профессионального образования развитию технической коммуникации, и в частности умению формулировать аргументированную обратную связь, до сих пор не уделяется систематического внимания. При изучении программирования студенты чаще всего работают индивидуально, а их речевая активность сводится к коротким вопросам преподавателю.
Одним из наиболее органичных способов формирования коммуникативных навыков в контексте разработки программного обеспечения является код-ревью, которая представляет собой практику критического анализа исходного кода коллегой или напарником. В индустрии этот процесс давно стал стандартом качества [1; 2], но в учебном процессе колледжа он используется редко и эпизодически. Вместе с тем методически грамотно выстроенное взаимное рецензирование кода способно одновременно решать несколько задач, а именно повышать качество программных продуктов, углублять понимание материала у проверяющего и формировать умение давать и принимать аргументированную обратную связь. Цель данной статьи - представить развёрнутую методику организации взаимной практики аргументированной обратной связи в формате код-ревью при изучении программирования в учреждениях СПО, включая описание подготовительного этапа, структуры шаблонов для разных курсов и критериев оценивания.
Методика включает четыре последовательные фазы, а именно подготовительную, ознакомительную, практическую и аналитическую.
На этапе подготовительной работы преподаватель решает две основные задачи. Он готовит дидактические материалы и определяет календарный план интеграции код-ревью в рабочую программу дисциплины. К дидактическим материалам относятся подборка проблемного кода с типичными ошибками для учебных разборов, комплект шаблонов код-ревью для разных уровней обучения и памятка по конструктивной обратной связи. План интеграции предполагает выделение под рецензирование десяти–пятнадцати минут в начале или в конце каждого лабораторного занятия, а также проведение двух-трёх полноценных занятий-практикумов в семестр, на которых код-ревью становится основным видом деятельности. Преподаватель также продумывает систему оценивания, включая журнал рецензий и критерии.
Этап обучения конструктивной критике начинается с того, что студенты, не имеющие опыта рецензирования, часто ограничиваются формальными одобрениями либо, напротив, переходят на личность автора. Поэтому первые два-три занятия, предваряющие введение полноценного код-ревью, отводятся под короткие тренинги. Преподаватель выводит на экран небольшой фрагмент кода с несколькими недостатками разного типа, такими как синтаксическая ошибка, неудачное имя переменной, отсутствие комментария, избыточная вложенность условий. Затем студентас предлагается выполнить задание, где необходимо сформулировать письменный комментарий к этому коду так, как будто он адресован коллеге. После выполнения задания несколько вариантов зачитываются вслух и сравниваются по критериям конкретности, безличности и наличия предложения по улучшению. Группа совместно выбирает лучший комментарий и фиксирует простые правила, которые затем оформляются в виде памятки. Памятка предписывает говорить только о коде, а не о человеке, указывать конкретное место и причину замечания, предлагать исправление или альтернативный вариант и обязательно отмечать удачные решения. Эта памятка в распечатанном или цифровом виде остаётся у студентов на всём протяжении обучения и используется при каждом ревью.
Когда базовые правила усвоены, начинается практическая фаза с поэтапным введением шаблонов и парной работы. На первом занятии преподаватель раздаёт шаблон для младших курсов и объясняет каждый пункт на примере готового решения. Затем студенты получают индивидуальное задание, пишут небольшой фрагмент кода (например, функцию или класс) и обмениваются тетрадями либо файлами с соседом по парте. Каждый проверяет работу напарника строго по шаблону, заполняя его письменно в течение семи–десяти минут. После этого пары обсуждают результаты лично, стараясь соблюдать правила памятки. Преподаватель наблюдает, при необходимости корректирует диалоги, а в конце занятия собирает заполненные шаблоны для анализа.
Через несколько занятий, когда парное рецензирование становится привычным, вводится групповой формат. Группа из трёх-четырёх человек получает решение одного из студентов (анонимно либо с согласия автора) и готовит коллективный отзыв. Распределяются роли, например один студент отвечает за проверку логики алгоритма, второй - за читаемость и оформление, третий - за обработку ошибок. Результатом становится общий документ с комментариями, который затем передаётся автору. Обсуждение в группе позволяет студентам услышать аргументацию друг друга и учиться согласовывать разные точки зрения.
Завершает цикл аналитическая работа и рефлексия. Периодически, примерно раз в месяц или после крупной контрольной точки, преподаватель проводит общее обсуждение качества рецензий. На экран выводятся обезличенные примеры удачных и неудачных отзывов, группа анализирует, какие формулировки были наиболее полезны автору кода. Также вводится обязательная практика ответа автора: после получения рецензии студент должен в кратком абзаце описать, какие замечания он принял и что исправил, а с какими не согласен и почему. Такой двусторонний процесс окончательно превращает код-ревью в осмысленную коммуникативную ситуацию. На старших курсах эта же общая последовательность сохраняется, но шаблон усложняется, а в качестве рецензируемого материала всё чаще используются фрагменты курсовых проектов или код, подготовленный в рамках учебной практики.
Шаблон для первого-второго курсов (базовый уровень) включает восемь позиций.
Первая позиция - соответствие условию задачи. Проверяющий выясняет, все ли пункты задания выполнены и не упущены ли особые случаи.
Вторая позиция - возможность запуска кода. Необходимо убедиться, что отсутствуют синтаксические ошибки, опечатки и пропущенные скобки.
Третья позиция - корректность результата на тестовых данных. Код проверяется на двух-трёх простых примерах, включая граничные значения (ноль, пустая строка, максимальное число).
Четвёртая позиция - понятность имён. Оценивается, легко ли по названиям переменных и функций догадаться об их назначении.
Пятая позиция - наличие и качество комментариев. Проверяющий смотрит, есть ли пояснения в сложных или неочевидных местах и не дублируют ли комментарии то, что и так очевидно из кода.
Шестая позиция - структурирование кода. Здесь обращается внимание на соблюдение отступов и логическое разделение на блоки пустыми строками.
Седьмая позиция - сильные стороны решения. Проверяющий отмечает, что в коде выполнено хорошо, понятно или оригинально.
Восьмая позиция - итоговая оценка и рекомендации. Формулируется общий вывод, а именно готов ли код к сдаче, требует ли он небольших доработок или нуждается в серьёзной переработке.
Шаблон для третьего-четвёртого курсов (продвинутый уровень) содержит десять позиций.
Первая позиция - соответствие требованиям. Оценивается полнота реализации технического задания или пользовательской истории, а также обработка всех крайних случаев.
Вторая позиция - архитектура и декомпозиция. Проверяющий анализирует, насколько обоснованно разбиение на классы, модули и функции, и нет ли слишком крупных блоков (более тридцати-сорока строк без логического завершения).
Третья позиция - читаемость и стиль кодирования. Контролируется соблюдение принятого в проекте или оговорённого в задании стиля, а также отсутствие проблем с форматированием.
Четвёртая позиция - применение принципов объектно-ориентированного программирования. Если проект подразумевает ООП, проверяются корректность инкапсуляции, наследования, полиморфизма и соблюдение принципа единственной ответственности.
Пятая позиция - обработка ошибок и исключений. Выясняется, предусмотрена ли реакция на некорректные входные данные, отсутствие файлов и сетевые сбои.
Шестая позиция - эффективность и оптимальность. Проверяющий ищет лишние вычисления и вложенные циклы, которые можно заменить, а также оценивает возможность ускорить узкие места.
Седьмая позиция - безопасность. Код проверяется на наличие уязвимостей ввода, SQL-инъекций (при работе с базами данных) и на хранение паролей в открытом виде.
Восьмая позиция - документирование. Оценивается полнота описания публичных методов и интерфейсов и то, сможет ли новый член команды понять назначение модуля без дополнительных вопросов.
Девятая позиция - положительные стороны решения. Фиксируются архитектурные решения или приёмы, которые можно отметить как особенно удачные.
Десятая позиция - итоговый вердикт и рекомендации. Определяется, следует ли принять код, отправить на доработку с обязательными замечаниями или отклонить.
Шаблоны не являются жёсткой инструкцией, преподаватель может убирать или добавлять пункты в зависимости от темы занятия. Важно, чтобы каждый пункт был сформулирован как вопрос, побуждающий к развёрнутому ответу, а не к односложному согласию или отрицанию.
Система оценивания код-ревью должна быть встроена в учебный процесс, чтобы процедура рецензирования воспринималась студентами не как формальность, а как значимая учебная активность.
Предлагается использовать простую трёхкомпонентную шкалу, каждый компонент которой может приносить до одного балла за одно ревью.
Первый компонент - полнота и точность. Проверяющий должен корректно обнаружить большую часть реальных ошибок и не указать ложных замечаний.
Второй компонент - конструктивность. Комментарии формулируются в соответствии с памяткой, содержат объяснение и, где уместно, конкретное предложение по исправлению.
Третий компонент - уважительность тона. Отзыв выдерживается в доброжелательном профессиональном стиле, без переходов на личности и обесценивающих формулировок.
Баллы суммируются в течение семестра и учитываются как дополнительная составляющая общей оценки по дисциплине (например, с весом от десяти до пятнадцати процентов).
Такая система стимулирует студентов относиться к рецензированию ответственно и одновременно даёт преподавателю материал для анализа развития коммуникативных навыков группы.
Как показывает обобщение педагогической практики, систематическое взаимное код-ревью приводит к заметному росту качества итоговых проектов. Студенты начинают писать более понятный и структурированный код уже на этапе черновика, зная, что он будет прочитан одногруппниками. Многократное повторение цикла «написал - получил отзыв - исправил» формирует привычку к самопроверке, а знакомство с типичными ошибками других расширяет кругозор. Однако главное в том, что будущие техники-программисты приобретают дефицитную способность к профессиональной коммуникации, которую невозможно развить, работая исключительно индивидуально.
Для успешного применения методики требуется минимальное материально-техническое обеспечение, так как достаточно доступа к редактору кода и возможности обмена файлами или ссылками. Ключевым фактором остаётся готовность преподавателя регулярно организовывать рецензирование и последовательно формировать культуру конструктивной обратной связи.
Дальнейшие перспективы исследования связаны с разработкой цифрового инструмента, частично автоматизирующего сбор и анализ студенческих рецензий, а также с изучением корреляции между активностью в код-ревью и результатами демонстрационного экзамена по компетенциям разработки программного обеспечения.
Список литературы
1. Бухарова Г.Д., Стариков В.В. Код-ревью как метод обучения программированию в высшей школе // Информатика и образование. 2023. Т. 38. № 5. С. 34–43.
2. Семенов А.Л. Коммуникативная компетентность как компонент профессиональной подготовки ИТ-специалистов среднего звена // Среднее профессиональное образование. 2023. № 8. С. 22–28.
3. Григорьев С.Г., Гриншкун В.В. Развитие коммуникативных навыков у студентов IT-специальностей в условиях цифровой трансформации образования // Вестник РУДН. Серия: Информатизация образования. 2023. Т. 20. № 2. С. 142–153.
4. Лебедева Т.Н., Шефер О.Р. Организация проектной деятельности обучающихся СПО с использованием элементов взаимного оценивания // Профессиональное образование и рынок труда. 2024. № 1. С. 71–80.
