✏️ Принципы разработки
KISS, Бритва Оккама, SSOT, DRY, YAGNI, SOLID
Зачем нужны
Инженерные принципы это не строгие правила, а ориентир
Помогают:
🔸 уменьшать стоимость изменений
🔸 снижать количество ошибок
🔸 упрощать сопровождение
🔸 делать требования понятнее
🔸 избегать избыточных решений
💡 Для системного аналитика принципы служат фильтром при сборе требований, позволяют снизить затраты ещё до написания кода
KISS (Keep It Simple, Stupid)
Решение должно быть максимально простым
Чем сложнее система, тем дороже изменения, тестирование и поддержка
KISS не означает примитивные решения
✅ А отказ от ненужного усложнения
Как применять СА
🔵не добавлять лишние сущности и процессы
🔵избегать универсальных решений без необходимости
🔵описывать требования максимально понятно
🔵сокращать количество исключений и специальных сценариев
Пример
❌ Спроектировать универсальный механизм уведомлений с 15 каналами доставки, шаблонизацией и правилами маршрутизации
✔️ Сначала реализовать email и push-уведомления, если нужны бизнесу
❌ Описывать 15 вариантов исключений для одного процесса
✔️ Описать общее правило обработки ошибок (fallback), покрывающее 95 % случае
Признаки нарушения KISS
▪️слишком много сущностей
▪️чрезмерная параметризация
▪️большое количество условий и исключений
▪️ сложность объяснения решения
Бритва Оккама
Не надо умножать сущности без необходимости
Если два решения равнозначно покрывают требования, выбирается то, у которого меньше сущностей и допущений
Отличие от KISS
🔸KISS говорит «делай просто»
🔸Бритва Оккама — «выбирай простое среди равных»
Примеры для СА
🟠Есть проблема производительности.
Необязательно сразу проектировать новый сервис или менять архитектуру. Возможно, достаточно оптимизировать запрос или
индекс
🟠При выборе интеграции: если данные можно получить через REST-агрегацию, не стоит предлагать внедрение ESB или CDC только из соображений «это современно».
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 возможных статусов процесса «на будущее» лучше реализовать только реально используемые статусы.
🔵на этапе уточнения задавать вопрос: «Если не сделать это сейчас, сможет ли бизнес работать?» Если да — требование переносится в бэклог.
❌ Типичная ошибка: путать гибкость системы и проектирование гипотетических сценариев
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 помогает управлять сложностью, но избыточное применение может привести к переусложнению
📎 Материалы
1. Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама
2. Принципы разработки в системном анализе
3. 5 принципов читаемого кода: KISS, YAGNI, DRY, BDUF и Бритва Оккама
4. SOLID, DRY, KISS, YAGNI и др. принципы разработки, пугающие новичка в IT
#проектирование
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Больше полезного в базе знаний по системному анализу
KISS, Бритва Оккама, SSOT, DRY, YAGNI, SOLID
Зачем нужны
Инженерные принципы это не строгие правила, а ориентир
Помогают:
🔸 уменьшать стоимость изменений
🔸 снижать количество ошибок
🔸 упрощать сопровождение
🔸 делать требования понятнее
🔸 избегать избыточных решений
💡 Для системного аналитика принципы служат фильтром при сборе требований, позволяют снизить затраты ещё до написания кода
KISS (Keep It Simple, Stupid)
Решение должно быть максимально простым
Чем сложнее система, тем дороже изменения, тестирование и поддержка
KISS не означает примитивные решения
✅ А отказ от ненужного усложнения
Как применять СА
🔵не добавлять лишние сущности и процессы
🔵избегать универсальных решений без необходимости
🔵описывать требования максимально понятно
🔵сокращать количество исключений и специальных сценариев
Пример
❌ Спроектировать универсальный механизм уведомлений с 15 каналами доставки, шаблонизацией и правилами маршрутизации
✔️ Сначала реализовать email и push-уведомления, если нужны бизнесу
❌ Описывать 15 вариантов исключений для одного процесса
✔️ Описать общее правило обработки ошибок (fallback), покрывающее 95 % случае
Признаки нарушения KISS
▪️слишком много сущностей
▪️чрезмерная параметризация
▪️большое количество условий и исключений
▪️ сложность объяснения решения
Бритва Оккама
Не надо умножать сущности без необходимости
Если два решения равнозначно покрывают требования, выбирается то, у которого меньше сущностей и допущений
Отличие от KISS
🔸KISS говорит «делай просто»
🔸Бритва Оккама — «выбирай простое среди равных»
Примеры для СА
🟠Есть проблема производительности.
Необязательно сразу проектировать новый сервис или менять архитектуру. Возможно, достаточно оптимизировать запрос или
индекс
🟠При выборе интеграции: если данные можно получить через REST-агрегацию, не стоит предлагать внедрение ESB или CDC только из соображений «это современно».
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 возможных статусов процесса «на будущее» лучше реализовать только реально используемые статусы.
🔵на этапе уточнения задавать вопрос: «Если не сделать это сейчас, сможет ли бизнес работать?» Если да — требование переносится в бэклог.
❌ Типичная ошибка: путать гибкость системы и проектирование гипотетических сценариев
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 помогает управлять сложностью, но избыточное применение может привести к переусложнению
📎 Материалы
1. Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама
2. Принципы разработки в системном анализе
3. 5 принципов читаемого кода: KISS, YAGNI, DRY, BDUF и Бритва Оккама
4. SOLID, DRY, KISS, YAGNI и др. принципы разработки, пугающие новичка в IT
#проектирование
➿➿➿➿➿➿➿➿➿➿
🧑🎓 Больше полезного в базе знаний по системному анализу