Жизненный цикл программного обеспечения

Технический фундамент SDLC

Жизненный цикл — это управляемый поток инженерных артефактов:

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

Такой подход превращает разработку из "написал код" в повторяемый процесс качества.

Почему нужно видеть задачу шире, чем «написал код»

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

Когда ты думаешь циклами, код становится частью продуктового процесса, а не изолированным артефактом.

Ключевой момент: "готово" — это не состояние ветки в git, а предсказуемый результат в проде и сигнал качества после релиза.

Проверь себя: какой этап SDLC чаще всего пропускают новичок и почему это потом "стреляет"?

Базовая модель SDLC в практичном виде

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

const hasTests = true;
const hasReview = true;
const hasMonitoring = false;

const releaseReady = hasTests && hasReview && hasMonitoring;
console.log(releaseReady);

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

Как принимать решение перед выкатом

Перед релизом полезно проверять не «в среднем все хорошо», а конкретные критичные условия.

function releaseAction(failedChecks, criticalPathCovered) {
  if (failedChecks > 0) return 'fix-before-release';
  return criticalPathCovered ? 'deploy' : 'hold';
}

console.log(releaseAction(1, true));
console.log(releaseAction(0, true));

Какие артефакты должны появляться на этапах цикла

Чтобы SDLC не был абстракцией, полезно фиксировать результат каждого шага:

планирование: список требований и критерии готовности
реализация: код и понятные комментарии к нетривиальным местам
проверка: тест-кейсы и результаты проверок
релиз: запись о версии и changelog
пост-релиз: метрики, логи, список улучшений

const releaseChecklist = {
  requirements: true,
  tests: true,
  changelog: true,
  monitoring: true,
};

const ready = Object.values(releaseChecklist).every(Boolean);
console.log(ready ? 'release-ready' : 'missing-artifacts');

Это делает процесс прозрачным и для разработчика, и для команды.

Такой подход снижает шанс инцидента после выката.

Частые ошибки новичков

Merge — это важный этап, но не конец цикла. Без наблюдаемости команда не понимает, помогла ли фича пользователю.

const hasMerge = true;
const hasPostReleaseMetrics = false;

const done = hasMerge && hasPostReleaseMetrics;
console.log(done ? 'task-complete' : 'needs-follow-up');

Другие частые ошибки:

Считать чеклист формальностью и выпускать без критичных проверок.
Не фиксировать критерии успеха до начала работы (потом нечем измерять результат).
Игнорировать пост-релизные сигналы, пока не случится инцидент.

Что будет, если изменить входные данные

Edge case — когда фича уже в проде, а команда не видит метрики, логи и ошибки пользователей. Формально релиз «состоялся», фактически — риск высокий.

function lifecycleState(hasRelease, hasMetrics) {
  if (!hasRelease) return 'build-in-progress';
  return hasMetrics ? 'iterating' : 'released-without-feedback-loop';
}

console.log(lifecycleState(true, false));

Проверь себя: что вернет функция для lifecycleState(true, true) и почему это состояние лучше для команды?

Что делать после релиза

После выката цикл продолжается:

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

Анти-провал: считать релиз финальной точкой и не возвращаться к реальным данным пользователей.

Краткий итог

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