Принцип атомарности

Данный раздел находится в работе и пока здесь хозяйствует Муза.

В своей профессиональной области я постоянно сталкивался с принципами, которые прямо или косвенно, так или иначе, призывали разделять и властвовать. Рубить, пока можно, до состояния атома, который в греческом языке звучит буквально как "не могу разрезать". Имя этим принципам было легион - SRP, ISP, KISS, YAGNI, микро-сервисы, микро-фронтенды и другие, но искусство разработки учит нас искать общие абстракции и в этом случае её было невозможно не заметить.

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

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

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

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

Но что ещё важнее, я также наблюдал и те области, где этот принцип мог бы принести пользу, будучи применён. Как знать, может государства также бояться работать с каждым отдельным гражданином, его проблемами, чаяниями и мечтами или школа с каждым учеником, учитывая его возможности и интересы, как я боялся работать с тысячами функциональных элементов. А что если эти опасения напрасны? [Egopolis]

Атомарность в ИТ

Принцип единственной ответственности

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

Принцип разделения интерфейса

(Interface Segregation Principle (ISP). Клиенты не должны быть вынуждены зависеть от интерфейсов, которые они не используют. Это означает, что интерфейсы должны быть узкоспециализированными и предоставлять только те методы, которые действительно необходимы конкретному клиенту.

Микро-сервисы

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

Микро-фронтенды

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

Закон Деметры

Закон Деметры (Law of Demeter, LoD) — это принцип проектирования программного обеспечения, который рекомендует минимизировать зависимость одного объекта от внутренней структуры других объектов. Его также называют принципом "не говори с незнакомцами".

KISS

Keep It Simple, Stupid (KISS) — это принцип проектирования, который подчеркивает важность простоты. Его основная идея состоит в том, что системы работают лучше, а их разработка, использование и поддержка проще, если они не излишне усложнены. "Сделай так просто, как только возможно, но не проще."

DRY

Don't Repeat Yourself (DRY). Избегайте дублирования кода и знаний в системе. Каждый фрагмент информации должен существовать в одном месте.

YAGNI

You Aren't Gonna Need It (YAGNI). Реализуйте только тот функционал, который нужен сейчас, а не в будущем.

Эгономика

Атомные привычки

Бестселлер Джеймса Клира Атомные привычки.

"Разрежьте слона на бифштексы"

Менеджмент

Кайдзен

Кайдзен (Kaizen) — это методология управления и постоянного улучшения процессов, основанная на идее малых, последовательных изменений. Термин происходит из японского языка и состоит из двух частей: "кай" (изменение) и "дзен" (лучшее), что можно перевести как "улучшение ради лучшего".

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

Государство

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

Атомарность в философии

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

Бритва Оккама (Occam’s Razor) — это философский принцип, который утверждает, что среди множества объяснений явления следует выбирать самое простое, то есть то, которое вводит меньше всего новых предположений. Принцип часто формулируют как: "Не следует умножать сущности без необходимости."

Муза

Отдельно на стыке Software Engineering и Project Management можно выделить Agile. Многие его составляющие критикуются, но за кулисами активно работают принципы атомарности в виде коротки спринтов, MVP, user stories. И небольшие команды также практически стали атрибутом Agile.
Разумеется говоря об атомарности невозможно обойти стороной химию. Её внезапный прогресс в середине прошлого столетие был во многом связан с развитием базовых элементов. Тоже самое можно сказать и о физике.
Экстраполируя этот принцип на разные области, например AI, можно сделать предположение, что множество миниатюрных нейросетей могут быть более эффективны, чем одна гигантская.
Дифференцирование и интегрирование.
Можем ли мы сказать о существовании принципы атомарности? Какая дисциплина должна за него отвечать? Если выяснится, что принцип хорош, не стоит ли экстраполировать и тестировать его в других направления. В образовании (+interleaving), в предпринимательстве.
Можно углубить философскую составляющую, исследуя исторические корни атомистического мышления от Демокрита до современности.