Вы получили новый билет в спринте. Или вы получили требования от клиента.

Что вы делаете в первую очередь?

Очень ценно иметь сборник игр. Процедура, которой вы следуете каждый раз, когда начинаете исследовать новое изменение в коде.

Это делает вашу работу более предсказуемой, полной и правильной. Вы станете лучшим разработчиком

Что должно произойти

Возьмем в качестве примера билет в спринте. Это проще всего.

Что должно произойти?

  • Напишите код, реализующий функцию
  • Напишите тесты для этого ^ кода
  • Убедитесь, что все тесты пройдены
  • Откройте запрос на вытягивание
  • (Обычно) пройти код-ревью
  • Пройти тесты пользовательского интерфейса и контроль качества
  • Успешное развертывание во всех средах

Это много! Это больше шагов, чем просто «написание кода.»

Ваш модуль Runbook

Каждый человек будет иметь немного разные предпочтения в том, как он структурирует свою книгу игр. Но важно, чтобы он у вас был.

Все эти шаги не просто предсказуемо встают на свои места! Для их выполнения требуется планирование и привычка.

Вот что я делаю, чтобы начать новую задачу. Может быть, это поможет вам.

  1. Я начинаю новую ветку git. Обычно это мой первый шаг.
  2. Я нахожу части кода, которые нужно будет изменить, но пока не вношу изменений. Это может занять некоторое время, потому что код, скорее всего, состоит из нескольких слоев, и мне может потребоваться внести изменения в нескольких местах.
  3. Я ищу любые существующие тесты для функциональности, которую я собираюсь изменить. Если повезет, уже есть хорошие тесты! Если нет, я напишу тесты, которые помогут мне быть уверенным, что я ничего не сломал. Я также лучше понимаю код, тестируя его ПЕРВЫМ.
  4. Теперь я готов сделать минимально возможное изменение. Не позволяйте пулл-реквесту увеличиваться в объеме. Сосредоточьтесь на своей задаче и на том, что должно произойти.
  5. Конечно, я пишу тесты и для своего нового кода. Иногда я практикую TDD. В других случаях я более свободен в выборе того, когда и какие тесты я пишу.
  6. Я часто запускаю модульные тесты во время разработки. Это мой инструмент номер один, чтобы рассказать, как у меня дела. Хорошее кодирование — это вопрос обратной связи. Модульные тесты дают одну из самых тесных петель обратной связи.
  7. Я отправляю свои изменения на GitHub после прохождения модульных тестов. Я открываю черновик пулл-реквеста, чтобы другие пользователи еще не получили автоматическую проверку. Я позволил нашей автоматизации GitHub позаботиться о выполнении полного набора тестов.
  8. Пока работает полный набор, я делаю обзор кода. Удивительно, сколько мелких ошибок или возможностей для оптимизации я вижу, когда просматриваю свой собственный код в качестве diff на GitHub. Я хочу, чтобы мой код был как можно меньше и чище, прежде чем я запрошу проверку.
  9. Если все тесты пройдены, я запрашиваю проверку, чтобы получить обратную связь от моей команды.
  10. Когда я готов к развертыванию, я позволяю нашему конвейеру CI/CD позаботиться о деталях. Но я сразу же проверяю изменения вживую, когда они проходят через окружение.

Здравый смысл

Этот модуль Runbook может показаться здравым смыслом.

Конечно, вам нужно протестировать свой код! Конечно, изменения в коде должны быть чистыми и небольшими!

К сожалению, здравый смысл не так распространен. Создавая явный модуль Runbook для себя, я не оставляю здравый смысл на волю случая.

Я просто выполняю одни и те же шаги каждый раз, когда вношу изменения.

Ежедневный список

Каждое утро я пишу что-то новое для разработчиков программного обеспечения. Присоединяйтесь к ежедневному списку, чтобы получать обновления!

—

Присоединяйтесь к Medium за 5 долларов — получите доступ ко всему Medium + поддержите меня и других!