Общие правила разработки¶
Даже если Вы — начинающий разработчик, Вы несёте коллективную ответственность за весь код проекта вместе с другими разработчиками. Поэтому если Вы видите проблемы в проекте (проваливающиеся сборки на сервере непрерывной интеграции, проваливающиеся тесты, ошибки статического анализа, неработоспособность приложения или отдельных его компонентов и т. п.), необходимо сообщить о них в конференции!
Порядок разработки¶
В самом начале работы над проектом необходимо однократно выполните клонирование репозитория проекта. Приведённые ниже шаги представляют собой описание одной итерации разработки и выполняются в цикле.
- Обновите свою локальную копию репозитория, загрузив изменения с центрального сервера с помощью команды
hg pull -u
. - Выберите задачу из числа поставленных Вам руководителем проекта или имеющихся в трекере в соответствии с их приоритетами. Если Вы испытываете затруднение в приоритизации задач, обратитесь к руководителю проекта.
- Решите задачу, руководствуясь инструкциями из следующего раздела. Внесите требуемые изменения в кодовую базу и выполните соответствующие коммиты в локальный репозиторий. Подробнее смотрите «Выполнение коммитов в репозиторий» ниже.
- Загрузите изменения кодовой базы, которые были внесены другими разработчиками в то время, пока Вы работали над задачей, с помощью команды
hg pull --rebase
. При необходимости устраните конфликты. - Отправьте свои изменения в центральный репозиторий командой
hg push
. - Оповестите руководителя проекта и/или других разработчиков о внесённых изменениях и решённых задачах, если необходимо.
Работа над задачами¶
- Задача, которую Вы решаете, обязательно должна быть в трекере до начала её решения. Запрещается решать задачи, которых нет в трекере! При необходимости Вы всегда можете создать задачу сами.
- Перед началом решения задачи убедитесь, что Вы чётко понимаете, что нужно сделать. Если есть непонимание каких-то деталей, необходимо уточнить эти детали у коллег.
- При решении задачи чётко осознавайте, какие побочные эффекты может иметь Ваше решение задачи и как оно может повлиять на другую функциональность приложения. Если эти эффекты представляются существенными (или если Вы не можете сами оценить, насколько они существенны), обсудите с коллегами.
- Отдельные законченные подзадачи необходимо оформлять отдельными коммитами. Не реже раза в сутки необходимо выгружать эти коммиты в центральный репозиторий. Желательно выгружать в центральный репозиторий каждый коммит сразу же после его фиксации.
- Если Вы не можете сделать коммит в течение длительного времени (более 2-3 часов), это обычно означает, что Вы решаете задачу бессистемно и/или неправильно разбили её на подзадачи. Остановитесь и выполните декомпозицию задачи на подзадачи так, чтобы по окончании решения подзадачи получался какой-то законченный результат, который можно было бы зафиксировать.
- По окончании работы над каждой задачей, а также в конце рабочего дня необходимо записать отработанное время в трекер (log time). Запрещается вносить время работы над задачей не в тот день, в который это время было потрачено! Отработанное время, внесённое задним числом, с большой долей вероятности не будет впоследствии оплачено!
Выполнение коммитов в репозиторий¶
- Коммит выполняется по окончании решения какой-либо задачи или её относительно самостоятельной части.
- Старайтесь выполнять коммиты, содержащие небольшое количество изменений.
- Если в процессе разработки добавлялись, удалялись, перемещались или переименовывались файлы, необходимо явно сообщить системе контроля версий об этих изменениях. Для этого используются команды
hg add имя_файла(ов)
,hg remove имя_файла(ов)
,hg mv имя_файла(ов)
. - Перед осуществлением коммита:
- проверьте, что модульные тесты выполняются успешно;
- проверьте, что написаны документационные комментарии;
- выполните команду
hg status
и убедитесь в отсутствии изменений файлов, которые не должны были изменяться, неотслеживаемых файлов (обозначены знаком вопроса) или потерянных файлов (обозначены восклицательным знаком); - выполните команду
hg diff
и убедитесь в отсутствии изменений в файлах, которые не относятся к решаемой задаче (в т. ч. появление лишних пустых строк/пробелов, отладочный вывод и т. п.);
- При написании сообщения коммита используется неопределённая форма глагола, например:
Add something useful (refs #23)
- Старайтесь, чтобы текст коммита был максимально коротким и понятным. Обязательно оцените, насколько легко будет понять, что было сделано, человеку, который последние два часа не занимался решением вашей задачи и не видел вашего кода.
- Текст сообщения завершается ссылкой на номер выполняемой (выполненной) задачи в трекере в скобках, предваряемой словом refs для незавершённых задач (промежуточные коммиты), fixes для исправленных багов, closes для прочих завершённых задач, resolves для задач, которые необходимо проверить.
TODO¶
- Уточнить про атомарность.
- Добавить процедуру оценки времени на задачу и указать максимальное ограничение этого времени.
- Добавить указание не копить локальные изменения даже в том случае, когда задача не решена до конца.
- Добавить указание про разработку через rebase, неплохая статья https://habr.com/ru/post/161009/