Основы программной инженерии и разработка сложных систем

Введение в программную инженерию: методологии и модели жизненного цикла (SDLC)

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

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

Программная инженерия vs Программирование

Многие студенты ошибочно полагают, что их работа после вуза будет заключаться исключительно в написании кода. Однако код — это лишь строительный материал. Программная инженерия (Software Engineering) — это применение систематического, дисциплинированного и измеримого подхода к разработке, эксплуатации и сопровождению программного обеспечения.

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

Для иллюстрации проблемы коммуникации в команде часто используют формулу количества каналов связи:

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

Если в команде 5 человек, каналов связи всего 10. Если же команда вырастает до 20 человек, количество связей возрастает до 190. Без четких процессов и методологий такая команда утонет в согласованиях, не написав ни строчки полезного кода.

Жизненный цикл разработки ПО (SDLC)

Чтобы управлять сложностью, инженеры придумали концепцию SDLC (Software Development Life Cycle) — жизненный цикл разработки ПО. Это фреймворк, описывающий этапы, через которые проходит продукт.

!Основные этапы жизненного цикла разработки ПО (SDLC)

Классический SDLC включает следующие фазы:

Анализ требований: Понимание того, что мы строим. Общение с заказчиком, фиксация функциональных и нефункциональных требований.

Проектирование (Design): Определение того, как мы будем это строить. Выбор архитектуры, стека технологий, проектирование баз данных и интерфейсов.

Разработка (Implementation): Непосредственное написание кода согласно спецификациям.

Тестирование (Testing): Проверка соответствия продукта требованиям и поиск дефектов.

Развертывание (Deployment): Доставка продукта конечному пользователю (выкладка на серверы, публикация в сторы).

Поддержка (Maintenance): Исправление багов, найденных пользователями, и добавление новых функций.

Модели жизненного цикла

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

Каскадная модель (Waterfall)

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

> Впервые формализованная Уинстоном Ройсом в 1970 году, эта модель пришла из строительной индустрии, где нельзя возвести крышу, не залив фундамент.

Плюсы: * Четкость и определенность сроков и бюджета (при условии неизменных требований). * Простота управления и отчетности.

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

V-Model (V-образная модель)

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

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

Итеративная и инкрементальная модели

Здесь проект разбивается на части. Вместо того чтобы делать «все и сразу», мы создаем продукт по кусочкам.

* Инкрементальный подход: Мы строим систему по модулям. Например, сначала делаем модуль регистрации, выпускаем его, затем модуль корзины и так далее. * Итеративный подход: Мы создаем всю систему сразу, но в черновом варианте, а затем улучшаем ее от версии к версии.

Гибкие методологии (Agile)

В 2001 году группа экспертов собралась на горнолыжном курорте в штате Юта и сформулировала Agile Manifesto. Это не конкретный алгоритм, а философия, которая изменила индустрию.

Основные ценности Agile: * Люди и взаимодействие важнее процессов и инструментов. * Работающий продукт важнее исчерпывающей документации. * Сотрудничество с заказчиком важнее согласования условий контракта. * Готовность к изменениям важнее следования первоначальному плану.

Agile реализуется через конкретные фреймворки, самые популярные из которых — Scrum и Kanban.

Scrum

Scrum делит процесс разработки на короткие отрезки времени — спринты (обычно 1-4 недели). В конце каждого спринта команда должна показать готовый к использованию инкремент продукта.

Ключевые роли в Scrum: Product Owner (Владелец продукта): Отвечает за то, что* делать (приоритеты бизнеса). Scrum Master: Отвечает за то, как* идет процесс (устраняет препятствия, следит за соблюдением правил). * Команда разработки: Кросс-функциональная группа специалистов, создающая продукт.

!Визуализация рабочего процесса во фреймворке Scrum

Kanban

Kanban пришел из производственной системы Toyota. Его суть — в визуализации потока задач и ограничении количества незавершенной работы (WIP — Work In Progress).

В отличие от Scrum, в Kanban нет жестких спринтов. Задачи движутся по доске слева направо (например: «Нужно сделать» -> «В работе» -> «Тестирование» -> «Готово»). Главная цель — максимально быстро провести задачу от начала до конца, избегая «пробок» на этапах.

Как выбрать методологию?

Выбор модели зависит от контекста проекта. Не существует «серебряной пули».

| Характеристика проекта | Рекомендуемая модель | | :--- | :--- | | Требования четкие и не будут меняться (госзаказ, типовой проект) | Waterfall | | Высокая цена ошибки, критические системы (авионика, медицина) | V-Model | | Требования неясны, рынок быстро меняется (стартап, новый продукт) | Agile (Scrum) | | Проект в стадии поддержки, поток мелких задач | Kanban |

Заключение

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

Инженерия требований: методы сбора, анализа и документирования функциональных спецификаций

В предыдущей лекции мы рассмотрели жизненный цикл разработки ПО (SDLC) и выяснили, что любой осознанный процесс начинается с этапа анализа. Сегодня мы погрузимся в этот этап максимально глубоко. Мы поговорим об инженерии требований (Requirements Engineering) — дисциплине, которая отвечает на главный вопрос любого проекта: «Что именно мы должны создать?».

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

Что такое требование?

Требование — это условие или возможность, которой должна обладать система, чтобы удовлетворить соглашение, стандарт, спецификацию или другие официально установленные документы. Это мост между нечеткими желаниями заказчика («хочу, чтобы было удобно») и точными инструкциями для разработчика.

Все требования глобально делятся на две большие категории:

Функциональные требования (Functional Requirements): Описывают поведение системы. Они отвечают на вопрос «Что система должна делать?».

* Пример: «Система должна отправлять пользователю email с подтверждением после регистрации». * Пример: «При нажатии кнопки 'Рассчитать' калькулятор должен выводить сумму введенных чисел».

Нефункциональные требования (Non-functional Requirements): Описывают атрибуты качества системы. Они отвечают на вопрос «Как система должна работать?».

* Пример: «Время загрузки главной страницы не должно превышать 2 секунд при нагрузке 1000 пользователей». * Пример: «Пароли пользователей должны храниться в базе данных в зашифрованном виде».

Часто нефункциональные требования называют «-ости»: надежность, масштабируемость, безопасность, доступность.

Процесс работы с требованиями

Инженерия требований — это не разовое действие, а итеративный процесс. Он состоит из четырех основных этапов:

!Циклический процесс работы с требованиями

1. Выявление требований (Elicitation)

Это этап «археологии». Ваша задача — извлечь информацию из голов стейкхолдеров (заинтересованных лиц). Заказчик редко знает, чего он хочет на самом деле. Он знает свои проблемы, а ваша задача — перевести их на язык решений.

Основные методы сбора:

* Интервью: Самый распространенный метод. Может быть структурированным (по заранее подготовленным вопросам) или неструктурированным (свободная беседа). * Анкетирование: Полезно, когда стейкхолдеров очень много и они географически распределены. * Наблюдение (Job Shadowing): Инженер садится рядом с будущим пользователем и смотрит, как тот работает сейчас. Это позволяет выявить привычки и проблемы, о которых пользователь может даже не упомянуть в интервью, так как считает их само собой разумеющимися. * Анализ документов: Изучение регламентов, законов и существующей документации, которые регулируют предметную область.

2. Анализ и приоритизация (Analysis)

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

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

* M — Must have: Критически важные функции. Без них продукт не имеет смысла (например, двигатель для машины). * S — Should have: Важные функции, но не критичные. Если их не будет, продукт будет работать, но с ограничениями (например, кондиционер в машине). * C — Could have: Желательные функции. «Вишенка на торте» (например, подогрев руля). * W — Won't have: То, что мы точно не будем делать в этом релизе.

3. Документирование (Specification)

Результаты анализа должны быть зафиксированы. В зависимости от методологии (Waterfall или Agile), формат документов будет отличаться.

#### Software Requirements Specification (SRS)

В классических подходах создается большой документ — SRS (Спецификация требований к ПО). Это «библия» проекта. Она содержит полное описание функционала, интерфейсов, поведения системы в нештатных ситуациях.

#### User Stories (Пользовательские истории)

В гибких методологиях (Agile) вместо огромных томов пишут короткие истории по шаблону:

> Как <роль пользователя>, я хочу <действие>, чтобы <ценность/цель>.

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

Такой формат фокусирует команду не на функциях системы, а на потребностях живых людей.

#### Use Cases (Варианты использования)

Это описание сценариев взаимодействия пользователя с системой. Use Case обычно включает: * Актера: Кто выполняет действие. * Предусловие: Что должно случиться до начала сценария. * Основной поток: Пошаговое описание успешного сценария. * Альтернативные потоки: Что происходит при ошибках или нестандартном выборе.

!Пример диаграммы вариантов использования для системы банкомата

4. Валидация (Validation)

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

Основные техники: * Ревизия (Review): Команда и заказчик читают спецификацию и ищут логические дыры. * Прототипирование: Создание черновых макетов интерфейса. Показать заказчику картинку всегда эффективнее, чем дать прочитать 50 страниц текста.

Математика стоимости ошибки

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

Эту зависимость можно аппроксимировать показательной функцией:

где: * — стоимость исправления ошибки на этапе . * — базовая стоимость исправления ошибки на этапе требований (условно 1 час работы аналитика). * — коэффициент роста сложности (эмпирически часто принимается около 10 для перехода между крупными фазами). * — индекс этапа (0 — требования, 1 — проектирование, 2 — кодирование, 3 — тестирование, 4 — эксплуатация).

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

Заключение

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

Качественно собранные требования — это фундамент, на котором в следующей статье мы будем строить архитектуру нашей системы.

Архитектура программного обеспечения: принципы проектирования, UML и паттерны разработки

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

Если требования — это список пожеланий заказчика («хочу дом с тремя спальнями и бассейном»), то архитектура — это чертежи инженера, где указаны несущие стены, разводка коммуникаций и материалы фундамента. Ошибка здесь стоит еще дороже, чем в требованиях, потому что перестраивать фундамент, когда дом уже возведен, практически невозможно.

Что такое архитектура ПО?

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

Мартин Фаулер, один из авторов манифеста Agile, дает более прагматичное определение: «Архитектура — это то, что трудно изменить позже».

Архитектура определяет:

Декомпозицию: Как разбить огромную систему на управляемые модули.

Взаимодействие: Как эти модули общаются (API, события, прямые вызовы).

Технологии: Языки, базы данных, фреймворки.

Архитектура vs Дизайн

Часто студенты путают эти понятия. Граница размыта, но она есть: * Архитектура — это стратегический уровень (высокоуровневая структура, выбор микросервисов или монолита). * Дизайн (проектирование) — это тактический уровень (как реализовать конкретный класс, какой паттерн применить внутри модуля).

Фундаментальные метрики: Coupling и Cohesion

Прежде чем говорить о паттернах, нужно понять, что делает архитектуру «хорошей» или «плохой». В основе всего лежат две метрики: Связность (Cohesion) и Связанность (Coupling).

Связанность (Coupling)

Это мера того, насколько сильно один модуль зависит от другого. Ваша цель — Low Coupling (слабая связанность).

Если изменение в модуле «Корзина» заставляет вас переписывать код в модуле «Доставка» и «Склад», значит, у вас высокая связанность (High Coupling). Это плохо, так как система становится хрупкой.

Для оценки стабильности архитектуры часто используют метрику нестабильности Роберта Мартина:

где: * — нестабильность модуля (от 0 до 1). * (Efferent Coupling) — исходящая связанность: количество классов внутри модуля, которые зависят от внешних классов. * (Afferent Coupling) — входящая связанность: количество внешних классов, которые зависят от классов внутри модуля.

Если , модуль максимально стабилен (ни от кого не зависит). Если , модуль максимально нестабилен (зависит от всех, но никому не нужен).

Связность (Cohesion)

Это мера того, насколько элементы внутри одного модуля сфокусированы на решении одной задачи. Ваша цель — High Cohesion (высокая связность).

Хороший модуль делает одну вещь и делает её хорошо. Если класс называется UserManager, но он также отправляет email-рассылки и считает налоги, у него низкая связность (Low Cohesion).

!Визуализация принципов Coupling и Cohesion: слева идеальная архитектура, справа — «спагетти-код»

Принципы SOLID

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

S — Single Responsibility Principle (Принцип единственной ответственности): У класса должна быть только одна причина для изменения.

O — Open/Closed Principle (Принцип открытости/закрытости): Программные сущности должны быть открыты для расширения, но закрыты для модификации. Вы должны иметь возможность добавить новую функцию, не переписывая старый код.

L — Liskov Substitution Principle (Принцип подстановки Барбары Лисков): Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.

I — Interface Segregation Principle (Принцип разделения интерфейса): Много специализированных интерфейсов лучше, чем один универсальный.

D — Dependency Inversion Principle (Принцип инверсии зависимостей): Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба должны зависеть от абстракций.

Язык моделирования UML

Архитектору нужен язык, чтобы объяснить свои идеи команде, не написав ни строчки кода. Таким языком стал UML (Unified Modeling Language).

UML — это стандарт ISO, включающий набор графических диаграмм. Мы рассмотрим самые популярные.

Диаграмма классов (Class Diagram)

Показывает статическую структуру системы: классы, их атрибуты, методы и связи между ними. Это «скелет» приложения.

Основные типы связей: Наследование (Inheritance): «Является» (Собака является* Животным). Композиция (Composition): «Состоит из» (Дом состоит из* Комнат). Если уничтожить Дом, Комнаты исчезнут. Жесткая связь. Агрегация (Aggregation): «Включает в себя» (Группа включает* Студентов). Если расформировать Группу, Студенты останутся. Мягкая связь.

!Пример UML диаграммы классов для системы заказов

Диаграмма последовательности (Sequence Diagram)

Показывает динамику: как объекты взаимодействуют во времени. Это «сценарий» работы функции.

Пример: Пользователь -> (вводит данные) -> Интерфейс -> (отправляет запрос) -> Сервер -> (проверяет БД) -> База Данных.

Паттерны проектирования

Паттерны (шаблоны) — это типовые решения часто встречающихся проблем проектирования. Это не готовый код, который можно скопировать, а концепция. Классическая книга «банды четырех» (Gang of Four, GoF) описывает 23 паттерна.

Они делятся на три группы:

1. Порождающие (Creational)

Отвечают за создание объектов, скрывая логику создания.

* Singleton (Одиночка): Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа. (Пример: подключение к базе данных). * Factory Method (Фабричный метод): Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать.

2. Структурные (Structural)

Отвечают за компоновку классов и объектов в более крупные структуры.

* Adapter (Адаптер): Позволяет объектам с несовместимыми интерфейсами работать вместе. (Пример: переходник с USB-C на HDMI). * Facade (Фасад): Предоставляет простой интерфейс к сложной системе классов. (Пример: кнопка «Запустить» на стиральной машине скрывает сложную логику управления двигателем и клапанами).

3. Поведенческие (Behavioral)

Отвечают за взаимодействие между объектами и распределение обязанностей.

* Observer (Наблюдатель): Создает механизм подписки, позволяющий одним объектам следить за событиями в других. (Пример: вы подписались на рассылку, и когда выходит новая статья, вам приходит уведомление).

Архитектурные паттерны

Если GoF-паттерны решают локальные задачи, то архитектурные паттерны определяют структуру всего приложения.

Монолитная архитектура

Все компоненты системы (интерфейс, бизнес-логика, работа с БД) находятся в единой кодовой базе и разворачиваются как единый файл.

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

Микросервисная архитектура

Приложение разбивается на набор небольших, независимых сервисов, которые общаются через сеть (обычно HTTP/REST).

* Плюсы: Гибкость (каждый сервис можно писать на своем языке), надежность (падение сервиса комментариев не сломает сервис видео). * Минусы: Огромная сложность инфраструктуры, проблемы распределенных транзакций.

> «Не начинайте с микросервисов. Начинайте с монолита, но держите его модульным». — Мартин Фаулер

Заключение

Архитектура — это искусство компромиссов. Нет «правильной» архитектуры, есть архитектура, подходящая под конкретные требования и ограничения. Использование паттернов и UML помогает структурировать хаос и говорить на одном языке с коллегами.

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

Обеспечение качества: стратегии тестирования, верификация и валидация кода

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

Сегодня мы поговорим об обеспечении качества (Quality Assurance). Мы разберем, почему тестирование — это не просто поиск багов, чем верификация отличается от валидации и как математически измерить сложность кода, чтобы предсказать вероятность ошибок.

QA, QC и Тестирование: разбираемся в терминах

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

QA (Quality Assurance — Обеспечение качества): Это набор активностей, направленных на выстраивание процессов, которые гарантируют качество. QA-инженер думает о том, как предотвратить появление дефектов еще до написания кода. Это превентивный подход.

QC (Quality Control — Контроль качества): Это процесс проверки готового продукта на соответствие требованиям. Это поиск дефектов в уже созданном артефакте.

Testing (Тестирование): Это непосредственное исполнение системы с целью нахождения ошибок. Это инструмент, который использует QC.

> «Тестирование может доказать наличие дефектов, но никогда не может доказать их отсутствие». — Эдсгер Дейкстра

Верификация и Валидация (V&V)

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

Верификация (Verification)

Вопрос: «Строим ли мы продукт правильно?»

Верификация проверяет, соответствует ли система спецификациям и требованиям, зафиксированным в документации. Если в ТЗ написано «кнопка должна быть красной», а она синяя — это ошибка верификации. Верификация — это объективный процесс сравнения факта с планом.

Валидация (Validation)

Вопрос: «Строим ли мы правильный продукт?»

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

!Диаграмма взаимосвязи процессов верификации и валидации в V-модели

Пирамида тестирования

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

!Пирамида тестирования Майка Кона

1. Модульные тесты (Unit Tests)

Фундамент пирамиды. Они проверяют самые маленькие изолированные части кода (функции, методы, классы) в отрыве от остальной системы.

* Скорость: Очень быстрая (миллисекунды). * Стоимость: Дешево писать и поддерживать. * Количество: Их должно быть больше всего (тысячи).

Пример: Проверка того, что функция sum(a, b) при вводе 2 и 2 возвращает 4.

2. Интеграционные тесты (Integration Tests)

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

* Цель: Найти ошибки в интерфейсах и контрактах данных. * Сложность: Требуют поднятия окружения (тестовая БД, моки внешних API).

3. Сквозные тесты (E2E — End-to-End)

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

* Инструменты: Selenium, Cypress, Playwright. * Минусы: Медленные, хрупкие (любое изменение верстки может сломать тест), дорогие в поддержке. * Количество: Их должно быть мало, только для критических бизнес-сценариев.

Стратегии тестирования: «Ящики»

В зависимости от того, имеет ли тестировщик доступ к исходному коду, выделяют три стратегии:

Black Box (Черный ящик): Мы не знаем, как устроена система внутри. Мы подаем данные на вход и проверяем выход. Это симуляция действий пользователя.

White Box (Белый ящик): Тестировщик видит код и пишет тесты, зная внутреннюю логику (ветвления, циклы). Unit-тесты — это почти всегда белый ящик.

Grey Box (Серый ящик): Комбинация подходов. Мы знаем архитектуру и структуру БД, но тестируем через внешние интерфейсы.

Метрики качества кода

Как понять, что код «хороший» или «протестированный»? Для этого существуют метрики. Самая популярная — Code Coverage (покрытие кода), показывающая процент строк кода, выполненных во время тестов.

Однако более глубокой метрикой является Цикломатическая сложность (Cyclomatic complexity), разработанная Томасом Маккейбом. Она позволяет оценить сложность программы через количество линейно независимых маршрутов через программный код.

Формула вычисления цикломатической сложности:

где: * — цикломатическая сложность. * — количество рёбер (переходов) в графе потока управления программы. * — количество узлов (блоков кода) в графе потока управления. * — количество компонентов связности (обычно 1 для одной функции или программы).

Простыми словами: каждый if, for, while, case увеличивает сложность.

Зачем это нужно? Существует эмпирическое правило: если , функция считается слишком сложной, трудной для тестирования и подверженной ошибкам. Такую функцию нужно рефакторить (разбивать на части).

Также цикломатическая сложность определяет минимальное количество тестов, необходимых для полного покрытия всех веток кода (Branch Coverage).

Статический анализ кода

Помимо динамического тестирования (запуска кода), существует статический анализ. Это автоматическая проверка исходного кода без его выполнения.

Инструменты (линтеры, анализаторы типа SonarQube) ищут: * Потенциальные баги (NullPointerException, утечки ресурсов). * Нарушения стандартов оформления (Code Style). * Дублирование кода. * Уязвимости безопасности.

Статический анализ — это самый дешевый способ найти ошибку, так как он происходит еще до компиляции.

TDD: Разработка через тестирование

Test-Driven Development (TDD) — это техника разработки, которая переворачивает процесс с ног на голову. Вместо «Написать код -> Написать тесты», мы действуем по циклу Red-Green-Refactor:

Red: Пишем тест для новой функциональности, которой еще нет. Запускаем его — он падает (красный).

Green: Пишем минимально необходимый код, чтобы тест прошел (зеленый). Качество кода на этом этапе не важно, главное — работоспособность.

Refactor: Улучшаем код, убираем дублирование, приводим в порядок архитектуру, при этом тесты гарантируют, что мы ничего не сломали.

Заключение

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

В следующей статье мы рассмотрим, как автоматизировать доставку нашего проверенного кода пользователям: нас ждет тема CI/CD и DevOps.

Управление конфигурацией, CI/CD процессы и сопровождение программных систем

В предыдущих лекциях мы прошли долгий путь: от сбора требований и проектирования архитектуры до написания кода и его тестирования. Казалось бы, если все тесты «зеленые», работу можно считать выполненной. Но в реальности промышленной разработки написание кода — это лишь начало пути.

Код, который работает на ноутбуке разработчика, не приносит ценности бизнесу. Ценность появляется только тогда, когда программа запущена в продуктивной среде (Production) и доступна пользователям. Сегодня мы поговорим о том, как организовать этот процесс, сделать его предсказуемым и как жить с системой после релиза.

Мы разберем управление конфигурацией, философию DevOps, конвейеры CI/CD и самый длительный этап жизненного цикла — сопровождение.

Управление конфигурацией (SCM)

Software Configuration Management (SCM) — это дисциплина управления изменениями в проекте. Она отвечает не только за версии кода, но и за состояние всей системы в любой момент времени.

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

Системы контроля версий и стратегии ветвления

Вы уже знакомы с Git. Но в команде из 20 человек хаотичные коммиты в main приведут к катастрофе. Для упорядочивания работы используются стратегии ветвления (Branching Strategies).

Gitflow: Классическая модель. Есть две вечные ветки: main (стабильный релиз) и develop (разработка). Фичи делаются в feature-branches, релизы готовятся в release-branches. Подходит для продуктов с редкими релизами.

Trunk-Based Development: Современный подход. Все разработчики коммитят в одну главную ветку (trunk или main) минимум раз в день. Ветки живут недолго. Это требует высокого покрытия автотестами, но позволяет релизиться несколько раз в день.

!Визуализация потоков кода в стратегии Gitflow

Версионирование артефактов

Собранный код превращается в артефакт (jar-файл, docker-образ, exe-файл). Артефакты должны иметь уникальные версии. Стандартом индустрии является Semantic Versioning (SemVer).

Формат версии: MAJOR.MINOR.PATCH (например, 2.14.5).

* MAJOR: Сделаны несовместимые изменения API (ломающие изменения). * MINOR: Добавлен новый функционал без нарушения обратной совместимости. * PATCH: Исправлены баги без изменения API.

CI/CD: Конвейер поставки

Чтобы код попадал к пользователю быстро и надежно, процессы сборки и доставки автоматизируют. Этот процесс называется Pipeline (конвейер).

Аббревиатура CI/CD расшифровывается как:

CI (Continuous Integration) — Непрерывная интеграция.

CD (Continuous Delivery / Deployment) — Непрерывная доставка / развертывание.

Continuous Integration (CI)

Суть CI проста: изменения от всех разработчиков должны сливаться в основную ветку как можно чаще, и каждое слияние должно проверяться автоматически.

Типичный CI-процесс:

Разработчик отправляет код в репозиторий (Push).

CI-сервер (Jenkins, GitLab CI, GitHub Actions) видит изменения.

Запускается сборка (Build) — компиляция кода.

Запускаются юнит-тесты и статический анализ (Linter).

Если все успешно — создается артефакт.

Если на любом этапе происходит ошибка, сборка считается «сломанной», и команда должна немедленно это исправить.

Continuous Delivery vs Continuous Deployment

Эти термины часто путают, но разница в последнем шаге.

* Continuous Delivery (Непрерывная доставка): Весь процесс автоматизирован до этапа, когда готовый релиз загружен в репозиторий артефактов и готов к выкладке. Но саму кнопку «Развернуть на прод» нажимает человек (инженер или менеджер). * Continuous Deployment (Непрерывное развертывание): Полная автоматизация. Если тесты прошли, код автоматически попадает к пользователям без участия человека.

!Этапы автоматизированного конвейера CI/CD

DevOps и Infrastructure as Code

Раньше разработчики (Dev) писали код и «перебрасывали его через стену» администраторам (Ops), которые пытались его запустить. Это порождало конфликты: «У меня работает, это ваши серверы кривые».

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

Ключевой практикой DevOps является Infrastructure as Code (IaC) — Инфраструктура как код. Серверы, сети и базы данных описываются не вручную через консоль, а в виде конфигурационных файлов (Terraform, Ansible, Kubernetes Manifests).

> «В прошлом мы относились к серверам как к домашним питомцам: давали им имена, лечили, когда они болели. В облачную эру мы относимся к ним как к скоту: если сервер заболел, мы его пристреливаем и берем новый». — Рэнди Биас

Сопровождение программного обеспечения

После того как ПО передано заказчику, начинается фаза сопровождения (Maintenance). Согласно исследованиям, на эту фазу приходится от 60% до 80% полной стоимости владения системой (TCO).

Стандарт ISO/IEC 14764 выделяет четыре типа сопровождения:

Корректирующее (Corrective): «Пожаротушение». Исправление багов, найденных пользователями.

Адаптивное (Adaptive): Изменение системы для работы в новой среде. Например, вышла новая версия iOS, обновился закон о налогах или нужно переехать с Oracle на PostgreSQL.

Совершенствующее (Perfective): Улучшение производительности или удобства использования по просьбе пользователей. Это добавление новых фич, которые не были в исходных требованиях.

Профилактическое (Preventive): Рефакторинг, обновление библиотек, оптимизация кода для предотвращения будущих проблем.

Метрики надежности и доступности

Главная задача сопровождения — обеспечить доступность системы. Для этого инженеры используют математические модели надежности.

Ключевая метрика — Коэффициент готовности (Availability). Он рассчитывается на основе времени между сбоями и времени восстановления.

Формула коэффициента готовности:

где: * — коэффициент готовности (вероятность того, что система работает в произвольный момент времени). * (Mean Time Between Failures) — среднее время наработки на отказ (сколько времени система работает нормально между сбоями). * (Mean Time To Recovery) — среднее время восстановления (сколько времени уходит на починку после сбоя).

Пример: Если ваш сервер падает раз в 100 часов (), а чините вы его за 1 час (), то доступность:

Это 99% доступности. В индустрии стремятся к «пяти девяткам» (99.999%), что допускает всего 5 минут простоя в год. Чтобы повысить , нужно либо увеличивать надежность кода (растить ), либо ускорять процессы восстановления и CI/CD (уменьшать ).

Заключение курса

Мы завершаем наш курс «Основы программной инженерии». Мы прошли путь от абстрактной идеи до поддерживаемой системы.

Программная инженерия — это не знание синтаксиса языка программирования. Это умение:

Понимать проблему (Требования).

Строить структуру решения (Архитектура).

Гарантировать качество (QA).

Доставлять и поддерживать решение (CI/CD и Сопровождение).

Технологии будут меняться каждые 5 лет, но эти фундаментальные принципы останутся с вами навсегда. Удачи в создании сложных и надежных систем!