Этапы разработки ПО. Как их видит разработчик и заказчик
Есть много статей повествующих о каскадной, итеративной и других всеми любимых моделях разработки. Каждая из этих статей рассказывает о преимуществах и недостатках и предлагает читателю самому сделать правильный выбор в зависимости от проекта. Смешно то, что человеку, который будет принимать решение о модели и этапах разработки, скорее всего не нужно читать об этом статьи. Он и так все знает. С другой стороны “целевая аудитория” таких материалов сможет применить эти знания только через время (и то если сильно повезет). Поэтому предлагаю читателю прочитать не теорию из учебников, а послушать про реализацию на практике. Мы разберем про различия в подходах аутсорсинговых и продуктовых компаний. И чем различается взгляд на модель разработки с точки зрения заказчиков(работодателей) и разработчиков(сотрудников).
Джун на аутсорсе
Начнем наше повествования от лица начинающего разработчика, которому удалось пройти свое первое интервью и устроиться в аутсорсинговую компанию. Почему именно джун и именно аутсорс ? Потому что, с одной стороны, 90% всех компаний – это аутсорс, а с другой модель разработки обычно изучают в универе, либо на “ранних этапах становления” и автор статьи очень надеется охватить большинство.
Итак, вы устроились в компанию и после небольшого инструктажа и знакомства с командой, получаете свою первую задачу. Какая у вас первая мысль ? Верно ! Написать свою функцию сортировки, кое-как на коленке выполнить задачу, чтобы она у вас работала и с чувством гордости смержить ваш код в мастер ветку, дабы показать что вы не просто так получаете зарплату. Назовем это этапом Разработки.
И если компания, в которой вы работаете очень маленькая, то возможно вам даже удастся такое провернуть. Просто потому что у некоторых начинающим ООО или ИП просто нет возможности нанять команду сеньеров и они считают, раз закончил институт, значит программист, а если программист, то иди и программируй мне. И чтобы все работало. Таким образом в вашей команде разработки совсем не обязательно будут опытные коллеги, которые смогут поправить вас. К тому же ревью кода отнимает время как минимум 2-x разработчиков и работодателям не всегда понятно зачем менять уже работающий код, а значит даже в опытной команде совсем не обязательно что вам будут указывать на ваши ошибки.
Но этап Ревью нужен. Представим, что вам все таки попалась жизнеспособная компания, которая понимает важность соблюдения определенных правил разработки, поэтому после того как вы закончили свою задачу, создается merge request и ваш наставник начинает разбираться в том что вы натворили.
Скорее всего ваше первое ревью будет долгим, т.к вам потребуется не только исправить не только архитектурные и логические ошибки в вашем коде, но также и соблюсти code style (свод правил написания кода, специфичный для конкретной компании). Здесь самое главное чтобы ваш ревьювер не сильно увлёкся. У ревью можно выделить 2 главных назначения:
Первое. Убедиться, что ты написал код, который будет работать всегда. Здесь мы предполагаем, что разработчик уже убедился в работоспособности кода (иначе какой смысл отдавать не работающий код на ревью). При этом можно упустить частные случаи, о которых начинающий девелопер может просто не знать.
Второе. Привести ваш код к некоторому стандартному виду. Чтобы в нем соблюдались правила и структура существующего приложения. Грубо говоря, нужно сделать ваш код внешне похожим, на уже присутствующий в проекте.
При этом очень важно сильно НЕ ударяться в перфекционизм. НЕ нужно по несколько дней вылизывать ваш код. Здесь нужно помнить о правиле “Лучшее враг хорошего”.
После того как вы закончили с ревью и ваш код оказался в общем репозитории наступает следующий этап – Тестирование.
Как правило аутсорсинговые компании имеют отдельных тестировщиков. Это люди, которые не занимаются разработкой, а пытаются сломать вашу новую фичу, после чего приходят и говорят “чини”. И это хорошо, что есть такие люди. Т.к даже будучи разработчиком сложно найти уязвимости в своем коде. Отчасти потому что ты из всех сил пытаешься их не искать и не ломать код. Но даже если честно взглянуть на свой код, то очень сложно учесть все варианты взаимодействия пользователя (а их очень много).
Тем не менее отдельные люди, занимающиеся тестированием – это совсем не обязательное условие. Особенно в небольших стартапах, у которых просто нет на это бюджета. И поэтому в таких командах тестированием кода занимаются сами разработчики. При этом бывает тестирование 1-й конкретной фичи, которую ты только что добавил, а бывает тестирование новой версии вашего приложения. И во втором случае могут быть задействованы ни один, а целая команда разработчиков.
Про автоматические тесты
Я не стал включать в главу про тестирование написание автоматических unit и интеграционных тестов. Поскольку считаю, что тесты - это не механизм проверки работоспособности вашего кода. Да конечно, есть TDD – но опять же, в этом случае вы с помощью тестов просто запускаете ваш код. Поэтому написание тестов нужно относить к этапу разработки.
Автоматические тесты – это в первую очередь защита от регрессии (поло