Собственно, продолжаю эксперименты с генератором задач на онтологию Рациональной работы. В моем случае хорошо работает решение задач на работу с концептами. Так они через руки быстрее осознаются и быстрее наступает состояние легкости в работе с концептами.
Возможно, коллегам мой опыт окажется полезным, а возможно, то что я тут описываю уже успело устареть )
тем не менее,
После того как поднастроил общий промт, запросил тренировочную задачу на Метод:
- Тренировочная задача на метод
** Описание предметной области
В компании по разработке программного обеспечения существует метод проведения код-ревью, который включает следующие этапы:
- Подготовка: разработчик отправляет код на проверку.
- Анализ: ревьюер изучает код, проверяет соответствие стандартам и ищет ошибки.
- Обсуждение: разработчик и ревьюер обсуждают найденные замечания.
- Исправление: разработчик вносит изменения.
- Завершение: ревьюер подтверждает исправления и закрывает задачу.
Метод направлен на повышение качества кода и снижение количества ошибок в продукте.
** Задание
Опишите метод проведения код-ревью с использованием ключевых элементов:
- цели метода,
- результаты,
- объекты внимания,
- характеристики объектов,
- состояния объектов и их изменения,
- действия,
- роли участников.
Определите, какие роли участвуют в методе и какие интересы и предпочтения у каждой роли могут быть.
Представьте формализацию метода в виде кортежей, указывая отношения между ролями, действиями и объектами.
Опишите, как данный метод может быть применён в конкретной работе по проверке кода, учитывая исполнителей, сроки и ресурсы.
** Цель задачи
- Закрепить понимание структуры и формализации метода.
- Понять связь между методами и реальными работами.
- Научиться формализовать процессы и роли в виде кортежей.
Далее, после того как я написал свою версию ответа, я сдаю его на проверку с обратной связью:
проверь ответы и дай обратную связь: “”"** ответы
1.
- цели метода:
- перевести код из состояния “код написан” в состояние “код проверен на ошибки и готов к релизу в прод”
- ошибки в коде переведены из состояния “ошибка есть в коде” в состояние “ошибка обнаружена и иправлена”,
- результаты:
- продукт в котором использован код работает стабильно и не содержит ошибок,
- объекты внимания:
- код,
- ошибки,
- замечания,
- изменения,
- исправления,
- задача
- характеристики объектов:
- объем кода - количество строк кода,
- количество ошибок,
- сложность ошибок,
- количество замечаний
- сложность змечаний
- количество именений
- сложность внесения изменений
- состояния объектов и их изменения:
- код не проверен,
- код проверен,
- ошибка не обнаружена
- ошибка обнаружена,
- ошибка исправлена,
- исправление разработано,
- исправление внесено,
- исправление подтверждено
- задача создана,
- задача в работе,
- задача выполнена,
- замечание обнаружено,
- замечание зафиксировано,
- замечание обсуждено
- замечание в работе,
- изменения созданы,
- изменения внесены,
- изменения проверены,
- изменения приняты,
- исрправления протестированы,
- исправления приняты
- действия:
- отправка кода на проверку
- изучение кода
- проверка кода на соответствие стандартам
- поиск ошибок
- обсуждение найденных замечаний
- внесение изменений в код
- подтверждение исправлений
- закрытие задачи,
- роли участников
- ревьюер
- разработчик
- разработчик
- интерес: писать код, предпочтение: быстро
- интерес: закрывать задачи, предпочтение: быстро, без переделок
- ревьюер
- интерес: обнаружить ошибки в коде, предпочтение: как можно больше
- интерес: чтобы код соответствовал стандартам, предпочтение: всем стандартам, максимально
- интерес: чтобы обнаруженные замечания и ошибки были исправлены, предпочтение: быстро и без создания новых ошибок
- <Разработчик::роль, отправляет на проверку::метод, код::индивид>
- <Ревьюер::роль, изучает::метод, код::индивид>
- <Ревьюер::роль, проверят на соответствие стандартам::метод, код::индивид>
- <Ревьюер::роль, ищет ошибки::метод, код::индивид>
- <Ревьюер::роль, обсуждает::метод, замечания::индивид>
- <Разработчик::роль, обсуждает::метод, замечания::индивид>
- <Разработчик::роль, вносит::метод, исправления::индивид>
- <Ревьюер::роль, подтверждает::метод, исправления::индивид>
- <Ревьюер::роль, закрывает::действие, задачу::индивид>
- модуль с кодом который разработал Иван::индивид разработчик::роль был передан на проверку ревюеру::роль Николаю
ревьюер::роль Николай::индивид должен проверить модуль с кодом на соответствие стандартам и наличие ошибок в течение 3-х рабочих дней с момента поступления задачи в работу.
Далее по итогам проверки ревьюер Николай::индивид проводит рабочую встречу на которой идет обсуждение замечаний и формируетс план-график устранения замечаний с учетом меющихся ресурсов и общего срока выпуска версии продукта.
после того как замечания обсуждены и план работ по устранению замечаний составлен, он берется в работу и исполняется разработчиком::роль"“”
И поучаю оценку с разбором:
Вот подробный разбор и обратная связь по вашим ответам на тренировочную задачу по методу код-ревью:
1. Описание метода
Плюсы:
- Чётко выделены цели метода — перевод кода из состояния «написан» в «проверен и готов к релизу», а также исправление ошибок.
- Результаты сформулированы адекватно — стабильная работа продукта без ошибок.
- Объекты внимания охвачены полно: код, ошибки, замечания, изменения, исправления, задача.
- Характеристики объектов детализированы — объём, количество и сложность ошибок и изменений.
- Состояния объектов расписаны подробно, включая этапы проверки, исправления и обсуждения.
- Перечислены все ключевые действия участников.
- Роли участников чётко обозначены — разработчик и ревьюер.
Рекомендации:
- В характеристиках объектов можно добавить качество кода (читаемость, покрытие тестами) как важный параметр.
- В состояниях стоит добавить состояние «задача на ревью» или «ожидание ревью», чтобы отразить промежуточный статус.
- В действиях можно выделить «создание задачи на ревью» как отдельный шаг.
2. Роли, интересы и предпочтения
Плюсы:
- Для каждой роли выделены ключевые интересы и предпочтения.
- Интересы сформулированы логично и соответствуют реальным ожиданиям ролей.
- Предпочтения отражают приоритеты (быстрота, полнота исправлений).
Рекомендации:
- Можно добавить интерес ревьюера в поддержание качества кода в долгосрочной перспективе (например, снижение технического долга).
- Для разработчика можно добавить интерес к обучению и улучшению навыков через ревью.
3. Формализация метода в виде кортежей
Плюсы:
- Использована правильная структура кортежей с указанием ролей, действий (методов) и индивидов.
- Все ключевые взаимодействия отражены: отправка, изучение, проверка, поиск ошибок, обсуждение, внесение исправлений, подтверждение, закрытие задачи.
- Чётко разделены роли и объекты.
Рекомендации:
- В одном кортеже вы используете «действие» (например, закрытие задачи), в остальных — «метод». Для консистентности лучше использовать один термин (например, «метод» или «действие») или пояснить различия.
- Можно добавить кортежи, отражающие изменение состояний объектов (например, ).
- Можно расширить формализацию, добавив временные метки или связи с задачами.
4. Применение метода в конкретной работе
Плюсы:
- Хорошо описан конкретный сценарий с участием реальных исполнителей (Иван и Николай).
- Указаны сроки выполнения (3 рабочих дня).
- Отражена организация рабочего процесса: проверка, встреча, обсуждение, планирование, исполнение.
- Учитываются ресурсы и общий срок выпуска продукта.
Рекомендации:
- Можно более явно выделить роли и индивидов (например, , ).
- Уточнить, как фиксируются результаты проверки и план-график (например, в системе управления задачами).
- Добавить описание возможных итераций (если исправления не приняты с первого раза).
- Можно добавить формализацию в виде кортежей для этого сценария.
Общая оценка
Ваши ответы демонстрируют глубокое понимание структуры и компонентов метода код-ревью, а также умение формализовать процессы и роли. Очень хорошо проработаны детали и логика взаимодействий.
Для дальнейшего развития рекомендую:
- Уделять внимание единообразию терминологии в формализации (метод vs действие).
- Добавлять временные и статусные аспекты в кортежи для более точного описания динамики.
- Расширять описание интересов ролей с учётом долгосрочных целей и обучения.
- Практиковать формализацию конкретных рабочих сценариев с учётом итераций и изменений.
Собственно, на то чтобы подготовить ответ уходит около 40-50 минут. Все это время я думаю про метод, его аспекты и нахожусь в состоянии собранности. Вполне не плохо, кмк.