Процесс разработки программного обеспечения

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

Маршрут по разделу 4.14

После этой главы — Типовые задачи разработчика — справочник-шпаргалка, Отладка, DevTools в браузере, Пет-проекты, План развития, Структура кодовой базы, README.

Git в процессе — Как работать с Git, лабораторные сценарии.

Карта раздела — о разделе.

---

Процесс разработки программного обеспечения

В компании под "разработкой ПО" часто понимают весь жизненный цикл — от идеи и аналитики до эксплуатации. В этой статье фокус на том, что делает разработчик в своей зоне ответственности — понять задачу, спланировать реализацию, написать и проверить код, сдать результат команде. Аналитика, тестирование на стенде, релизы и мониторинг существуют рядом; без них продукт не доедет до пользователя, но и без качественного кода они не спасут пустой репозиторий.

Термин в разговоре	Обычно включает	В фокусе этой статьи
Разработка (широко)	Требования, дизайн, код, тесты, деплой	Частично (схемы ниже)
Кодирование	Редактор, язык, отладка, коммиты	Да
Инженерная культура	SOLID, ревью, CI, безопасность	Да (принципы и этапы)

Обычно в разработку включают много всего - от анализа требований и проектирования до тестирования, развёртывания. Но по факту под разработкой понимать лучше именно само кодирование - написание программного кода на выбранных языках программирования и интеграция различных компонентов.

Сейчас порог довольно высокий, и разрабатывать довольно сложно. Усложняет всё необходимость знания практик, методологий, подходов, принципов и прочих ньюансов. Именно в этом сложность.

---

Принципы разработки

Есть принципы проектирования, паттерны проектирования, архитектурные паттерны, методологии, подходы проектирования, и всё это - разные вещи. А каких же принципов придерживаться разработчику?

Play ITЗагрузка интерактивного демо…

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

Можно собирать миллионы всяких условий и правил, но в общем, как-то так. Ниже каждый пункт сохранён; после него — зачем он нужен на практике, а не только "что делать".

---

ИИ, секреты и дисциплина проверки

• Если используете нейросеть, то проверяйте и переписывайте код. Сама по себе идея "подсказки" от ИИ-агентов хороша, но на практике всегда всё криво. Команды в терминале от агента — по стоп-листу; подробнее — AI-ассистенты;

  Модель не знает ваш репозиторий целиком и может "додумать" несуществующие API. Прогоните сценарий руками, прочитайте diff и убедитесь, что зависимости и версии совпадают с проектом.

• Если публикуете код, отправляете куда-то, скриншотите или шлёте нейросети, обязательно убирайте всё конфиденциальное - API-ключи, пути, идентификаторы, персональные и коммерческие данные;

  Утечка в gist, чат или скриншот PR — та же утечка, что и в проде. Заменяйте реальные значения на *** или фиктивные из .env.example.

• Не полагайтесь на автоматику, всегда перепроверяйте;

  Автоформатирование, линтер и CI ловят часть ошибок, но не понимают бизнес-смысл. Финальная ответственность за поведение программы — на разработчике.

---

Перед тем как писать код

• Сначала проектируйте решение, затем приступайте;

  Хотя бы набросок — какие сущности, какой endpoint, где хранятся данные. Пятнадцать минут схемы экономят часы переделки.

• Не ленитесь поискать решение прежде, чем делать самим;

  Официальная документация, issue на GitHub, внутренняя wiki — часто уже есть готовый паттерн. Изобретать велосипед имеет смысл, когда вы понимаете, почему готовое не подходит.

---

Читаемость и соглашения команды

• Наименования сущностей, классов, переменных и прочих элементов кода должны передавать свою суть наиболее доходчиво, чтобы любой другой разработчик мог сразу понять смысл;

totalPrice понятнее, чем x или data2. Имя — первая документация; комментарий не должен исправлять плохое имя.

• Следуйте принятым в проекте соглашениям по форматированию;

  Один стиль отступов, порядок using, именование веток — меньше шума в diff и на code review. Если регламента нет, согласуйте с командой, а не "как привык".

• Повторяющийся код выносите в отдельные методы или классы - это DRY (Don't Repeat Yourself);

  Копипаста из трёх мест при правке бага даёт три места для ошибки. Общую логику выносите, когда повтор осознанный, а не случайный.

• Перепроверьте свой код ещё раз (работает всегда!);

  Свежий взгляд после паузы или прогон по чек-листу ловит опечатки, которые глаз замылил.

• Внимательно сверить реализацию с задачей - проверить каждое слово, пункт, поле, формулировки, числа, и прочее;

  В тикете "не больше 100" — это включительно или строго меньше? "Пользователь" — только активные? Такие детали часто дороже, чем час кодирования.

• Проверяйте, не затираются ли чужие доработки;

  Перед merge смотрите diff целиком: не исчезли ли чужие строки при разрешении конфликта. git blame и история файла помогают, если сомневаетесь.

• По возможности, максимально декомпозируйте методы, чтобы было проще отлаживать;

  Метод на 200 строк сложно покрыть тестом и поставить breakpoint. Разбейте на шаги с говорящими именами — отладчик покажет, на каком шаге сломалось.

• Проверяйте на наличие орфографических ошибок;

  Опечатки в сообщениях пользователю, логах и именах веток выглядят непрофессионально; в ключах конфигурации могут сломать поиск.

• Добавляйте комментарии (и XML-документацию), описания и атрибуты к каждому классу, методу, свойству и полю, чтобы другим было понятно;

  Комментируйте почему сделано неочевидно, а не что делает i++. Публичный API в библиотеках — документируйте обязательно.

• Отделяйте элементы друг от друга пустыми строками - условные конструкции (if, else, for, while), методы, атрибуты, поля, свойства и прочее.

• Правильно:

элемент1

элемент2

элемент3

• Неправильно:

элемент1
элемент2
элемент3

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

---

Константы, структура файла, YAGNI

• Старайтесь избегать литералов и не оставлять фиксированных значений в коде;

  Магическое 86400 в коде хуже, чем const secondsPerDay = 86400 или настройка в конфиге. Так проще менять правила и искать вхождения.

• Сортируйте код в логические блоки:

здесь объявляем переменные

здесь объявляем функции

здесь вызываем функции и работаем

• Убирайте потенциальные полезные вещи, которые сейчас не нужны. Никаких "на будущее" (это YAGNI);

  Абстракция "на вырост" усложняет чтение и тесты. Добавляйте слой, когда появился второй реальный случай использования, а не гипотеза.

• Добавляйте валидацию для всех значений, которые поступают извне (интеграционное получение данных, ввод пользователя);

  Сеть и пользователь — недоверенные источники. Проверяйте тип, диапазон и формат на границе системы, до бизнес-логики.

---

SOLID — пять опор ООП-дизайна

• SOLID. Принцип единственной ответственности (SRP): класс делает только одну задачу;

  Если класс и считает скидку, и шлёт email, и пишет в БД — при изменении почты придётся трогать "скидочный" модуль. Разделяйте причины изменения.

• SOLID. Принцип открытости/закрытости (OCP): классы открыты для расширения, закрыты для изменения;

  Новый тип оплаты — новый класс/стратегия, а не очередной if в гигантском switch. Старое поведение не ломаем при добавлении нового.

• SOLID. Принцип подстановки Барбары Лисков (LSP): объекты могут быть заменены их подтипами без нарушения программы;

  Если функция принимает Bird, подтип Penguin не должен ломать ожидание "умеет летать". Контракт подтипа не уже и не шире базового без необходимости.

• SOLID. Принцип разделения интерфейса (ISP): клиенты не зависят от методов, которые они не используют;

  "Толстый" интерфейс из 20 методов заставляет реализаторов писать пустые заглушки. Дробите интерфейсы по ролям клиента.

• SOLID. Принцип инверсии зависимостей (DIP): зависит от абстракций, а не от конкретных реализаций;

  Use-case знает IOrderRepository, а не SqlOrderRepository. Подмена БД или мок в тесте — без переписывания сценария. См. Организация кодовой базы.

---

Простота, производительность, отладка

• KISS. Нет избыточного ООП и излишней логики, если можно сделать проще;

  Паттерн ради паттерна усложняет онбординг. Три класса с ясной логикой лучше фабрики абстрактных строителей для одной кнопки.

• Избегать частых аллокаций в критических участках (например, создание объектов в цикле);

  В горячих циклах (обработка потока, игровой кадр) лишние new дают нагрузку на GC. Сначала измерьте профилировщиком, потом оптимизируйте.

• На этапе написания кода - используйте отладочные сообщения, трассировки, комментарии и инструменты для дебага . Но перед отправкой коммита - уберите их.

console.log в цикле на 10 000 итераций засорит лог и тормозит. В коммит уходит чистый код; отладку ведите локально или через условный флаг — см. Отладка.

• Код не должен содержать закомментированного мусора - ненужные методы, блоки кода, всё это нужно убирать;

  Закомментированный код не компилируется в голове читателя: жив он или мёртв? Удаляйте — история в Git вернёт при необходимости.

• Функции и методы называть лучше глаголом, обозначающим основной смысл функции, к примеру GetData для получения данных;

GetUserById, SendInvoice, ValidateEmail — сразу видно действие. Существительное уместно у сущностей и DTO.

• Проверяйте, чтобы среди английских символов (латиницы) не спрятались кириллические символы (к примеру, "с", "K", "Н", "Т", "М" и так далее);

  Визуально userСount (кириллическая "с") и userCount совпадают; компилятор видит разные идентификаторы. Такие баги ловят ревью и поиск по Unicode.

• Когда формируете SQL-запросы, используйте только те данные, которые нужны в работе - не запрашивайте все таблицы целиком;

SELECT * тянет лишние колонки и ломает индексы. Явный список полей — меньше трафика и понятнее контракт.

• Предпочитайте декларативный стиль императивному, где это упрощает понимание;

items.Where(x => x.Active).Select(...) короче цепочки for с флагами, если команде знаком LINQ/map/filter. Главное — ясность, а не мода.

---

Контракты методов, тесты и безопасность

• Все публичные методы должны выполнять проверку входных параметров (в том числе null, диапазоны, форматы);

  Публичный API — граница: вы не контролируете вызывающего. ArgumentNullException / IllegalArgumentException лучше, чем падение глубже по стеку.

• Для внутренних (private/internal) методов проверки допустимо опускать, если гарантируется корректность вызова из контекста;

  Внутри модуля договорённость "вызываем только после Validate" снижает шум. Если контекст размыт — лучше проверить снова.

• Не подавляйте исключения без явной необходимости: catch {} без логгирования или восстановления состояния;

Пустой catch делает сбой невидимым: пользователь видит "ничего не произошло", в логах пусто. Ловите конкретный тип, логируйте, пробрасывайте или восстанавливайте осмысленно.

• Критически важные компоненты должны быть покрыты модульными и интеграционными тестами (TDD/BDD по уместности);

  Платёж, авторизация, расчёт цены — зона, где регресс дорог. Тест не обязан быть "на 100 % покрытия", но должен фиксировать ключевые сценарии и границы.

• Уязвимости ввода (например, SQL-injection, XSS, SSRF) должны устраняться на уровне архитектуры — параметризованные запросы, экранирование, валидация, allowlist-подход;

  Одна "санитизация в контроллере" не спасёт, если второй endpoint забыли. Параметризованные запросы ORM/SQL, CSP, запрет произвольных URL — системные меры. Подробнее — основы ИБ.

---

Исключения и видимость

• Исключения — для исключительных ситуаций, а не для управления потоком выполнения (т.е. не использовать try-catch вместо if). Не стоит оборачивать каждый блок кода в try-catch: это снижает читаемость, скрывает реальные проблемы и усложняет отладку;

  Ожидаемый случай "файл не найден" часто лучше вернуть Optional / Result, чем бросать на каждый запрос. Глобальный обработчик — для необработанных сбоев на границе API.

• Избегайте исключений, которые можно предотвратить проверкой (например, NullReferenceException, IndexOutOfRangeException);

if (list == null || index < 0 || index >= list.Count) в горячем пути дешевле, чем stack trace в проде. Nullable-типы и границы индекса — профилактика.

• В распределённых системах исключения должны корректно сериализоваться и содержать контекст (trace ID, operation ID), но не конфиденциальные данные;

  По traceId в логах связаны сервисы; пароль и токен в тексте ошибки — утечка. Пользователю — безопасное сообщение, в лог — детали.

• По умолчанию используйте наиболее строгий уровень доступа, private для полей и вспомогательных методов, internal для компонентов, используемых только внутри сборки, protected — только если явно требуется расширение в подклассах;

  Публичное поле — контракт навсегда. Сужать доступ позже больно; расширять — просто.

• Не расширяйте доступность ради "удобства тестирования" — вместо этого применяйте инверсию зависимостей и DI-контейнеры;

public только чтобы тест вызвал метод — признак плохой связности. Тестируйте через интерфейс и внедрение зависимостей.

• Объявляйте локальные переменные ближе к месту первого использования и в наименьшей возможной области видимости;

  Переменная в начале метода на 80 строк путает: живёт ли она весь метод? Узкая область — меньше случайных перезаписей.

• Предпочитайте неизменяемые типы.

readonly, record, final — меньше состояний, которые нужно держать в голове при многопоточности и рефакторинге.

Куда углубляться по принципам

SOLID и паттерны в проектировании — раздел 7.06.

Структура папок под чистую архитектуру — Организация кодовой базы.

Безопасность ввода и секреты — 8.03 "Забота о коде", стоп-лист команд.

AI в IDE — AI-ассистенты.

Список выше — ориентиры, которые со временем становятся привычкой. На code review вас чаще поймают на нарушении двух-трёх пунктов, чем на отсутствии идеального DRY во всём файле.

---

Процесс разработки

Процесс разработки начинается с получения задания. Но в каждой компании могут быть свои особенности и правила, а также проекты могут быть как простыми, так и сложными, поэтому схем можно выделить четыре:

Общий процесс

Первая схема представляет общий процесс разработки, начиная с подготовки проекта и заканчивая завершением. Он логичен, хотя новичку юнит-тесту могут быть не знакомы.

Акцент на тестирование

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

Использование Git

Третья схема показывает процесс разработки с учётом использования системы контроля версий (Git), это стандартная практика в современной разработке. Важный момент здесь - коммиты, использование локального и удалённого репозитория и конечно код-ревью.

Использование CI/CD

Четвёртая схема учитывает современные практики CI/CD (непрерывная интеграция и доставка). Здесь тестирование и развёртывание автоматизированы. Это более сложная тема, особенности которой будем изучать позже.

---

Что такое разработка?

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

Давайте рассмотрим основные этапы разработки.

---

Получение задания

Любая разработка начинается с задачи. Это может быть запрос от заказчика, идея собственного проекта или поручение внутри команды. Первый и один из самых важных шагов — правильно понять, что именно требуется сделать:

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

  "Быстро" — это 200 мс или "до конца недели"? "Все пользователи" — только активные или включая заблокированных? Запишите ответы в комментарий к тикету.

• Определите цели — чего хочет заказчик, какова основная функция.

  Одна фраза "зачем это бизнесу" помогает отсечь лишнюю работу: если цель — отчёт для бухгалтерии, анимация UI не в приоритете.

• Соберите контекст — узнайте, какие ограничения существуют (сроки, стек, совместимость, регуляторика).

  Старый API без HTTPS, запрет на новые NuGet, GDPR для персональных данных — такие ограничения дешевле узнать до кодирования.

Формулировки в тикете (Jira, YouTrack, Azure DevOps) — часть спецификации. Перескажите задачу своими словами в комментарии или в личке аналитику: "правильно ли я понял, что…". Это дешевле, чем шесть часов кода в неверном направлении.

Не стесняйтесь спрашивать у коллег (особенно аналитиков этой задачи), ведь иногда задание может быть расплывчатым или даже противоречивым. В таких случаях необходимо провести предварительный анализ и согласование условий до начала проектирования и реализации. И если аналитик уже анализировал, это не значит, что разработчику не нужен анализ!

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

А если бы вы даже и не заметили ошибку, просто сделали бы как указано в документации, задача пошла в тестирование, и только на этом этапе обнаружили проблему - и вас будут дёргать на исправление "бага", и вы в процессе правки заметите, что задача изначально была некорректно поставлена.

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

---

Стратегия разработки и оценка затрат на разработку

После того как задача понята, наступает время стратегического планирования. Этот этап определяет дальнейший ход действий и помогает ответить на три ключевых вопроса:

• Сколько времени потребуется на реализацию?

  Декомпозиция на подзадачи по 2–8 часов и сумма с запасом 20–30 % надёжнее, чем "неделя на всё".

• Какие ресурсы (люди, инструменты, технологии) будут задействованы?

  Нужен ли DBA, доступ к staging, лицензия на библиотеку — без этого оценка срока бессмысленна.

• Какой бюджет необходим?

  Для разработчика редко в зоне ответственности; если слышите цифру от менеджмента — уточните, входит ли в неё тестирование и деплой.

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

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

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

Второй вариант более строгий, когда вам просто дают задачу, и время на неё уже определено. К примеру, техлид определил самостоятельно, получив ответы на все вопросы, проанализировал и назначил уже готовую задачу. Здесь будет документация, чёткая задача и выделенное время, поэтому важно не спешить бежать её исполнять, всё также нужно проанализировать, но в чуть более ускоренном темпе. В идеале, созвониться с постановщиком задачи и попросить объяснить задачу, если есть такая возможность.

Для ответа на вопросы обычно используют методы оценки трудозатрат (к примеру, деление задач на подзадачи и оценка каждой части), анализ рисков (выявление потенциальных проблем и их влияния на сроки и бюджет), и учитывается выбранная модель жизненного цикла разработки (водопад, Agile).

Здесь главное — точная оценка на ранних этапах позволяет избежать недоразумений и перерасхода ресурсов позже.

---

Предварительное планирование

Организация процесса — залог успешной реализации любого проекта, как в циклах задач, так и в конкретных задачах. Даже самые талантливые и опытные разработчики могут потерпеть неудачу, если работа плохо спланирована или не контролируется. Конечно, здесь важно, чтобы роли и обязанности в команде были распределены, постановка задач выполнялась с помощью систем управления проектами, планирование этапов было корректным, проводились регулярные встречи для контроля процесса. И конечно гибкость, ведь план должен учитывать возможные изменения и адаптацию под новые условия.

Но не всё зависит от самого разработчика, ведь он лишь часть команды, а не управляющий, поэтому сначала нужно адаптироваться, изучить все регламенты и потом только приступать. Обычно к проектам допускают только после прохождения какого-то базового обучения и череды знакомств. Разработчику потребуются разве что хард-скиллы, технические навыки со знанием алгоритмов, структур данных, опыта работы, понимания протоколов, API, паттернов. Начинающему же будут давать более простые задачи, так что сложность задачи лежит на лидах.

После получения задачи, определения затрат, начинается "горячая фаза" разработки. Если перед разработкой вы проанализировали и записали себе свой план разработки, то работа пойдёт чуть быстрее. А если не записали - пора записать (кроме случаев, когда у вас уже есть идеальная документация, но это нереально). Аналитики и лиды не углубляются в тонкости реализации - какие функции вызывать, как называть переменные, как выполнять запросы в базу и тому подобное. Поэтому тут бремя лежит на разработчике.

Даже небольшое проектирование перед началом кодирования помогает избежать хаоса, повысить читаемость кода и облегчить дальнейшее сопровождение. Нужно определить данные, логику, интерфейс, способы обмена данными, поток движения информации внутри системы.

Сначала напишите себе крупные этапы работы - допустим "Создать класс слушатель", "Создать класс для логики". Потом разбейте эти этапы на задачи, декомпозировав их - алгоритмическим языком распишите, что должны иметь классы, какие свойства/поля, методы, переменные. В таком "мини-проекте" определите им имена. Можете всё расписывать в обычном текстовом редакторе и создавать отдельные файлы для каждой задачи, которую вам поручают. В некоторых компаниях можно встретить даже требования для подготовки специальных документов с планом разработки (это полезно, когда сотрудник уволился или в отпуске, и при разборе проблем нужно понять, чем он руководствовался, что он делал и как планировал). Кто-то предпочитает так не расписывать и сразу приступить, мыслить творчески в самом процессе, но я бы рекомендовал придерживаться чёткости и порядка хотя бы на первых порах. В дальнейшем мышление структурируется и только тогда будете готовы рваться сразу в бой. А документация поможет не забыть о том, что изменено (хотя Git и так сообщит изменения), какие были названия у сущностей и элементов, и позволит избежать проблем.

---

Процесс написания кода

Это центральный этап разработки. Тут всё просто — сделайте код:

• Читаемым — чтобы другие разработчики могли понять вашу логику.

  Через полгода "другой разработчик" — это вы сами; имена и короткие методы экономят время при багфиксе.

• Поддерживаемым — чтобы добавление новых функций не превращалось в лотерею.

  Изменение в одном месте не должно ломать пять экранов; для этого границы модулей и тесты на критичные пути.

• Тестируемым — код разбит на модули, которые можно проверить отдельно (юнит-тесты, ручной сценарий, контракт API).

  Если функцию нельзя вызвать без поднятия всей БД и почты — её сложно проверить до merge.

Инструменты: IDE (Visual Studio, VS Code), отладчик — Отладка. Версии — Git. Для учебной практики вне работы — Пет-проекты и План развития.

Соблюдение стандартов кодирования, написание комментариев и документирование функций значительно облегчает жизнь всем участникам проекта. В рамках принятых регламентов, конечно.

Собственно, прежде чем приступить к написанию кода, нужно проверять, готовы ли нужные инструменты и окружение - IDE, текстовый редактор, системы сборки и зависимости, доступ к серверам, базам данных, внешним API. Правильно настроенная рабочая среда экономит время и снижает количество "не работает у меня" ситуаций.

Важно понимать, что разработчик пишет код быстро, а большую часть времени выясняет, почему оно не работает, или правит ошибки. Ошибка — неизбежная часть разработки. Особенно часто они возникают на ранних этапах, поэтому бояться их не нужно, воспринимать как возможность научиться их исправлению.

Читайте сообщения об ошибках, пользуйтесь отладкой и логированием для поиска проблем. Главное — сохранять терпение и систематически подходить к исправлению ошибок. Вы можете завершить работу, сдать её, но вам прилетит ошибка от тестировщиков и придётся вернуться к этому шагу, чтобы поправить баги.

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

---

Сдача разработки

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

Перепроверили? Перепроверьте ещё раз. Семь раз отмерь, один раз отрежь. Не торопясь, сначала прочитайте свой код, и убедитесь в его корректности, аккуратности и соответствии регламентам. Потом попробуйте проверить, работает ли он (ведь кому нужен нерабочий код?), протестируйте, а если у вас есть возможность работать со своей локальной копией репозитория, то это как раз возможность для теста.

И только когда вы убедились, что всё работает как надо, а также чисто и (по вашему мнению) готово, то заливайте изменения на сервер, делайте пулл-реквесты, словом, сдавайте задачу. Здесь можно столкнуться ещё с одной задачей - подготовкой документации, к примеру, описание разработчика или отчёт. Если вы документировали на этапе планирования, то отчеты пишутся легко, так как всё было по плану.

---

Чек-лист перед сдачей задачи

Проверка	Зачем
Код соответствует формулировке тикета (каждый пункт)	Чтобы не вернули "не то сделали"
Локально воспроизведён happy path и пара граничных случаев	Меньше циклов с QA
Нет отладочного мусора (console.log, закомментированных блоков)	Чистота репозитория
Секреты и пути к локальным машинам не в diff	Безопасность
Коммиты осмысленные, ветка запушена	Ревью и CI
README / описание PR, если менялся запуск или конфиг	README — руководство

---

Как четыре схемы процесса соотносятся с реальностью

Четыре диаграммы выше — акценты на одном пути:

1. Общий процесс — сквозной путь от задачи до закрытия, включая самопроверку.
2. Акцент на тестирование — напоминание, что баги возвращают на этап кода; тестировщик — следующий фильтр качества.
3. Git — ветка, коммиты, PR; без VCS в команде вы теряете параллельную работу и историю решений.
4. CI/CD — автоматическая сборка и выкладка; на старте карьеры достаточно понимать, что pipeline запускается после merge, подробности — в DevOps и CI/CD и кейсе GitHub Pages.

На стажировке вас чаще посадят на вариант 1 + 3; в зрелых командах к этому добавляют 2 и 4.

---

Практика вне работы

Если коммерческого опыта мало, закрывайте пробелы пет-проектами с полным циклом — репозиторий, README, несколько коммитов, по возможности деплой — Пет-проекты, идеи по уровню сложности — План развития, выкладка — кейс GitHub Pages.

---