В предыдущей части блога я описал ситуацию, недавно накрывшую меня в соло-проектом на питоне. А сейчас я хочу поговорить о том, зачем разработчику нужно тратить время на что-то кроме создания новых фич проекта.
Если вы встречаете непонятные слова типа "фича", "прод" или "мерж", то можете воспользоваться двумя ссылками, которые я нагуглил за пару минут для вас, чтобы вы понимали о чем я говорю, а мне не пришлось пилить еще одну статью со словарем айтишника. Если что-то все-же осталось не понятно - пишите об этом в комментариях. Постараюсь ответить.
https://habr.com/ru/companies/wrike/articles/475558/
https://habr.com/ru/companies/wrike/articles/477936/
В чем соль
Суть ситуации, в которой я недавно очутился в том, что внезапно понадобилось вносить правки в проект, который работает на проде. А проект с точки зрения надежности был на зачаточном уровне развития, т.е. разработка велась там же, где и продовая версия кода, юнит и end-to-end тестов не было, процесса код-ревью и мерж реквестов тоже не было. И все бы ничего, но у меня дня на три сбился режим и отладка кода заняла все мое личное время, а в остальное время я чувствовал над собой постоянное давление совести из-за сломанного проекта. Давайте разберемся с этими моментами и посмотрим, можно ли без всего этого обойтись, если просто писать с первого раза рабочий код.
Дисклеймер
В данной статье я в качестве объекта рассматриваю backend-проект. Кроме того, я рассматриваю проблемы проекта, за который вы несете ответственность как разработчик перед другими людьми. Кроме того, мой материал может быть больше всего полезен джунам-разработчикам, которые только начали работать над большим проектом в команде и хотят понять почему так сложно устроен процесс разработки. Я буду рассматривать вопрос зачем нужен тот или элемент проекта, но не как его технически устроить. Данный список всех заблуждений и этапов разработки далеко не полон.
С орг частью все. Поехали.
Заблуждение номер раз
Все мои правки в проекте всегда взлетают с первого раза, максимум со второго, если я очень спешу.
Поздравляю, вы один гений из 1000. Но с момента, как вы начали обновлять код и до завершения работ проект становится нерабочим частично или полностью. Поэтому нужно иметь как минимум две версии проекта - прод и дев в соответствующих ветках проекта в гитлабе.
Заблуждение номер два
Я создал себе копию проекта и у меня все работает.
Хорошо, что вы хотя бы проверяете наличие ошибок в коде после его обновления. Дело в том, что ваш проект может быть сломан при фактическом отсутствии ошибок в вашем коде. Во-первых, всегда есть варианты входных данных, которые вы не проверили. Во-вторых, скорее всего ваш проект общается тем или иным способом с другими проектами в режиме онлайн по сети, через файлы и т.д. В таком случае вы можете создать код с ошибкой, которая будет проявляться не у вас в коде, а в коде того проекта, который будет получать от вашего проекта данные по сети.
От подобных ситуаций может уберечь написание юнит-тестов, которые, например, контролируют формат выходных данных в вашем проекте.
Допустим, вы настроили прод/дев версии проекта и мало-мальски тестируетесь перед обновлениями.
Заблуждение номер три
Юнит-тесты показали, что все ок. Можно катиться
Вы можете написать более правильную версию функции, которая отрабатывает без ошибок на юнит-тестах, но при запуске на проде может оказаться, что время обработки порции входных данных увеличилось вдвое. От этих проблем может уберечь нагрузочное и end-to-end тестирование.
Заблуждение номер четыре
Все тесты отработали, теперь можно ехать в прод.
В момент стресса и горящих сроков мы можем отвлекаться на эмоции, сильные ожидания результатов и раздражение. От этого концентрация непосредственно на задаче снижается. Тут могут произойти тоже разнообразные ошибки: формально юнит-тесты есть, но вы забыли проверить важный кейс; у вас есть этапы ручного тестирования и вы могли из-за спешки или раздражения что-то упустить; решая один старый баг, вы принесли новый; у ваших правок низкое качество кода, из-за чего уже завтра вы потратите х2 времени на новые задачи. С этими всеми проблемами помогает бороться оформление ваших правок в виде МР и код-ревью. Вам прийдется пройтись мысленно по всем этапам работа и сформулировать их в понятном для ваших коллег виде.
Заблуждение номер пять
МР готов, коллеги посмотрели и одобрили код.
Теперь уже можно обновлять прод вашими правками. Да, стадия работы над задачей уже зрелая, но даже после всех проделанных этапов могут появиться сбои: вы все-таки что-то недосмотрели; в требованиях к задаче были неправильные сведения; в проекте, с которым вы интегрированы, произошли изменения и т.д.. Все это возможно, но главное то, что вы должны быть готовы быстро откатиться к предыдущей стабильной версии проекта. Ее нужно так или иначе сохранять. Это первое. Второе - перечислите в своей голове все этапы проверок, которое вы совершили при работе над задачей. Этим вы сами вернете себе понимание, что вы молодец, что вы уже обезопасили себя от кучи других косяков и что ошибка, скорее всего кроется не в вашей работе, а постановке задачи или в коммуникации заказчиком. Но это уже другая история.
Что с этой информацией делать?
Надежным будет ваш проект только тогда, когда вы будете вкладывать время и силы в его надежность. Этот вывод часто идет вразрез с требованием заказчиков сделать фичу быстро и вообще задачу надо было сделать вчера.
Если вы только начинаете работать над большим проектом, т.е. вы стажер или свежеиспеченный джун, то примите как данность, что у вас в обязанностях будет не только работа над интересной фичей для пользователя, оформление кода, написание юнит-тестов, обсуждение вашего кода с коллегами и доработки. Расскажите в комментариях о вашем первом опыте работы в большом проекте.
А если вы уже имеете некоторый опыт в работе над большим проектом, т.е. вы уже опытный джун или начинающий мидл и у вас есть проблемы с надежностью проекта, то проанализируйте свою работу за последнее время: на сколько вы вкладывали свое время в техдолг и рефакторинг (вы уже должны знать эти термины), на сколько часто в вашем проекте вы сталкивались с проблемами из данной статьи. Будет интересно узнать в комментариях о вашем опыте излечения своих проектов от подобных заблуждений.