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

SSOT, KISS, Бритва Оккама, DRY, YAGNI, BDUF, SOLID, APO, и Separation of Concerns

Зачем нужны

Инженерные принципы это не строгие правила, а ориентир. Помогают:

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

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

Принципы уменьшения сложности

KISS (Keep It Simple, Stupid)

Решение должно быть максимально простым. Чем сложнее система, тем дороже изменения, тестирование и поддержка.

KISS не означает примитивные решения.А отказ от ненужного усложнения.

Как применять аналитику

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

Пример:

Нарушение KISS	Соблюдение KISS
Спроектировать универсальный механизм уведомлений с 15 каналами доставки, шаблонизацией и правилами маршрутизации.	Сначала реализовать email и push-уведомления, если нужны бизнесу.
Описывать 15 вариантов исключений для одного процесса.	Описать общее правило обработки ошибок (fallback), покрывающее 95 % случаев.

.

Признаки нарушения KISS

• слишком много сущностей;
• чрезмерная параметризация;
• большое количество условий и исключений;
• сложность объяснения решения.

Бритва Оккама

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

Отличие от KISS: KISS говорит «делай просто», Бритва Оккама — «выбирай простое среди равных».

Примеры для СА

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

• При выборе интеграции: если данные можно получить через REST-агрегацию, не стоит предлагать внедрение ESB или CDC только из соображений «это современно».
• В моделировании данных: если атрибут вычисляется (например, возраст по дате рождения), его не следует хранить.

Separation of Concerns (SoC)

Разделять систему на независимые зоны ответственности.

Каждая часть системы должна отвечать за ограниченный набор задач. Это:

• упрощает изменения;
• снижает связанность;
• облегчает сопровождение;
• уменьшает влияние изменений.

Примеры применения

В архитектуре:

• UI отдельно;
• бизнес-логика отдельно;
• интеграции отдельно;
• хранение данных отдельно.

В аналитике:

• бизнес-требования отдельно от технических ограничений;
• интеграционные требования отдельно от UI;
• правила обработки отдельно от сценариев.

Признаки нарушения

• изменение одной функции ломает несколько областей; например, изменение логики расчёта скидки заставляет переписывать раздел «Вход в систему».

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

Принципы борьбы с избыточностью

SSOT (Single Source of Truth)

Для каждой информации должен существовать один источник истины.

Если одинаковые данные существуют в нескольких местах, со временем они начинают расходиться.

Где применяется

• требования;
• схемы данных;
• справочники;
• бизнес-правила;
• интеграционные контракты.

Примеры в СА

• Создавать единый глоссарий; в тексте требований использовать ссылки на термины, а не их определения.
• Справочные данные (списки валют, стран) выносить в общий раздел и ссылаться на него.
• Маппинг полей между системами хранить в едином файле (Swagger/OpenAPI или отдельной таблице), а не дублировать в сценариях.

Пример нарушения: правило «комиссия для клиентов из ЕС = 20 %» прописано в ТЗ, в UI-макете, в описании интеграции и в тест-кейсах. При изменении ставки до 22 % три источника не обновляются → баг на релизе.

DRY (Don’t Repeat Yourself)

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

Дублирование приводит к изменениям во многих местах одновременно (одинаковые бизнес-правила; повторяющиеся требования; копирование схем данных; одинаковая логика в нескольких процессах.)

Пример

• Одинаковые структуры API вручную описываются в нескольких документах. Лучше использовать единое описание и переиспользовать его.

• В Use Cases применять include-сценарии для повторяющихся процедур (например, аутентификация описывается один раз).

Когда дублирование допустимо: ради производительности (денормализация БД) или изоляции микросервисов (копирование DTO), но такое решение должно быть явно зафиксировано как исключение.

DRY не должен создавать избыточную сложность.

Отличие DRY от SSOT

SSOT — про данные: одна сущность (справочник, атрибут, значение) хранится в одном месте. «где лежит истина?» (хранение).

DRY — про логику: один алгоритм, правило или описание процесса не повторяется в разных местах. «где выполняется действие?» (поведение).

Принципы ограничения лишней разработки

YAGNI (You Aren’t Gonna Need It)

Не создавайте функциональность заранее.

Если функция не нужна сейчас — вероятно, её не нужно делать сейчас.

Примеры в СА

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

Типичная ошибка: путать гибкость системы и проектирование гипотетических сценариев.

BDUF (Big Design Up Front)

Подход предполагает детальное проектирование системы заранее.

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

Когда полезен

• высокая стоимость ошибок;
• стабильные требования;
• сложные интеграции;
• регулируемые отрасли.

Когда создаёт проблемы

• требования часто меняются;
• сроки ограничены;
• проект развивается итерационно.

Примеры в СА:

• BDUF оправдан для ядра системы (фундаментальные сущности: Клиент, Договор, Платеж), где ошибка проектирования критична, а также в регулируемых отраслях (финансы, медицина).

Риск чрезмерного BDUF

Система начинает проектироваться под предположения вместо реальных потребностей.

APO (Avoid Premature Optimization)

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

Оптимизация — это компромисс. Почти всегда усложняет решение.

Что делать вместо

• измерять;
• собирать метрики;
• искать узкие места;
• оптимизировать только проблемные области.

Пример в СА

• Требования к нагрузке (например, 1000 RPS) должны опираться на реальные бизнес-показатели (средний пиковый трафик прошлых периодов + разумный запас).
• Для справочника из 50 записей, меняющегося раз в месяц, не требуется сложное кэширование (Redis) — достаточно in-memory кэша или его отсутствия.

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

SOLID

SOLID — набор принципов проектирования, направленных на создание изменяемых и поддерживаемых решений.

Принцип	Интерпретация для аналитика
SRP (Single Responsibility)	Требование должно иметь одну причину для изменения. Не следует смешивать в одном разделе расчёт зарплаты и отправку уведомлений — их нужно разделять.
OCP (Open/Closed)	В требованиях новый сценарий должен дополнять, а не переписывать старый. Вместо «если тип A, то скидка 10 %» лучше описать механизм правил, где для типа A задаётся правило, а для типа B можно добавить новое правило.
LSP (Liskov Substitution)	Если в требованиях есть родительская роль («Клиент»), то её подтип («VIP-клиент») не должен нарушать предусловия системы (например, не требовать обязательный номер телефона, если у VIP его нет).
ISP (Interface Segregation)	Лучше иметь несколько специализированных эндпоинтов, чем один универсальный с множеством обязательных полей.
DIP (Dependency Inversion)	Требования к модулям верхнего уровня не должны зависеть от деталей нижнего уровня. Вместо «сохранять в таблицу Oracle INSERT'ом» следует писать «система сохраняет данные» — абстрагироваться от реализации.

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

Как принципы работают вместе

Некоторые принципы усиливают друг друга.

Комбинация принципов	Как взаимодействуют	Практический эффект
KISS + YAGNI	Помогают не создавать лишние функции и сложность заранее	Быстрее разработка, проще сопровождение
SSOT + DRY	Уменьшают дублирование данных, логики и требований	Меньше рассинхронизации и ошибок
SoC + SOLID	Помогают разделять ответственность и снижать связанность	Проще изменять и расширять систему
APO + KISS	Сдерживают преждевременные усложнения и оптимизации	Более понятные и дешёвые решения
YAGNI + APO	Не позволяют реализовывать или оптимизировать гипотетические сценарии	Снижение объёма ненужной работы
BDUF + YAGNI	Требуют баланса между проектированием и скоростью изменений	Снижается риск как недопроектирования, так и переусложнения

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

Принципы могут конфликтовать.Например:

• слишком агрессивный DRY иногда ухудшает читаемость;
• чрезмерный SoC может привести к избыточной декомпозиции;
• чрезмерное следование YAGNI иногда мешает расширяемости.

Типичные ошибки

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

Распространенные ошибки:

• применение принципов как строгих правил;
• чрезмерная декомпозиция;
• проектирование «на всякий случай»;
• попытка сделать универсальное решение сразу;
• оптимизация неподтвержденных проблем;
• создание сложных абстракций ради красоты архитектуры.

Материалы

1. Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама
2. Принципы разработки в системном анализе
3. 5 принципов читаемого кода: KISS, YAGNI, DRY, BDUF и Бритва Оккама
4. SOLID, DRY, KISS, YAGNI и др. принципы разработки, пугающие новичка в IT
5. KISS, YAGNI, DRY и другие: 5 принципов, которые должен знать каждый разработчик
6. Принципы проектирования
7. Это классика, это знать надо: DRY, KISS, SOLID, YAGNI и другие полезные сокращения
8. Технологии программирования 2. Основные принципы: SOLID, YAGNI, KISS, DRY. Паттерны программирования
9. Что имеют в виду программисты, когда говорят про DRY, SOLID и YAGNI
10. Основные принципы разработки (SOLID, KISS и т. д.)
11. Пишем код, который живёт долго: SOLID, DRY, KISS, YAGNI

Видео

1. KISS, DRY, GRASP и другие принципы разработки
2. Принципы разработки программного обеспечения
3. Лекция 3 в НГУ: SOLID, KISS, DRY и другие странные слова
4. Простыми словами про принцип KISS, DRY, YAGNI
5. Бритва Оккама, KISS, YAGNI, BDUF. | Курс «Паттерны и практики написания кода»
6. KISS DRY YAGNI ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ | SWIFT
7. Как писать чистый код программисту новичку: KISS, YAGNI, DRY, Закон Деметры