Project

General

Profile

Общие правила разработки

Даже если Вы — начинающий разработчик, Вы несёте коллективную ответственность за весь код проекта вместе с другими разработчиками. Поэтому если Вы видите проблемы в проекте (проваливающиеся сборки на сервере непрерывной интеграции, проваливающиеся тесты, ошибки статического анализа, неработоспособность приложения или отдельных его компонентов и т. п.), необходимо сообщить о них в конференции!

Порядок разработки

В самом начале работы над проектом необходимо однократно выполните клонирование репозитория проекта. Приведённые ниже шаги представляют собой описание одной итерации разработки и выполняются в цикле.

  1. Обновите свою локальную копию репозитория, загрузив изменения с центрального сервера с помощью команды hg pull -u.
  2. Выберите задачу из числа поставленных Вам руководителем проекта или имеющихся в трекере в соответствии с их приоритетами. Если Вы испытываете затруднение в приоритизации задач, обратитесь к руководителю проекта.
  3. Решите задачу, руководствуясь инструкциями из следующего раздела. Внесите требуемые изменения в кодовую базу и выполните соответствующие коммиты в локальный репозиторий. Подробнее смотрите «Выполнение коммитов в репозиторий» ниже.
  4. Загрузите изменения кодовой базы, которые были внесены другими разработчиками в то время, пока Вы работали над задачей, с помощью команды hg pull --rebase. При необходимости устраните конфликты.
  5. Отправьте свои изменения в центральный репозиторий командой hg push.
  6. Оповестите руководителя проекта и/или других разработчиков о внесённых изменениях и решённых задачах, если необходимо.

Работа над задачами

  1. Задача, которую Вы решаете, обязательно должна быть в трекере до начала её решения. Запрещается решать задачи, которых нет в трекере! При необходимости Вы всегда можете создать задачу сами.
  2. Перед началом решения задачи убедитесь, что Вы чётко понимаете, что нужно сделать. Если есть непонимание каких-то деталей, необходимо уточнить эти детали у коллег.
  3. При решении задачи чётко осознавайте, какие побочные эффекты может иметь Ваше решение задачи и как оно может повлиять на другую функциональность приложения. Если эти эффекты представляются существенными (или если Вы не можете сами оценить, насколько они существенны), обсудите с коллегами.
  4. Отдельные законченные подзадачи необходимо оформлять отдельными коммитами. Не реже раза в сутки необходимо выгружать эти коммиты в центральный репозиторий. Желательно выгружать в центральный репозиторий каждый коммит сразу же после его фиксации.
  5. Если Вы не можете сделать коммит в течение длительного времени (более 2-3 часов), это обычно означает, что Вы решаете задачу бессистемно и/или неправильно разбили её на подзадачи. Остановитесь и выполните декомпозицию задачи на подзадачи так, чтобы по окончании решения подзадачи получался какой-то законченный результат, который можно было бы зафиксировать.
  6. По окончании работы над каждой задачей, а также в конце рабочего дня необходимо записать отработанное время в трекер (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/