Софт: из чего состоит программа_

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

three partsТри составляющих любой программы

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

Данные редко хранятся «просто в файле» — для этого используют базы данных, и здесь есть два основных подхода. SQL (реляционные базы данных, например MySQL, PostgreSQL) хранят информацию в виде таблиц со строго заданной структурой: заранее известно, какие столбцы есть в таблице и какого типа в них данные, а связи между таблицами чётко прописаны. NoSQL (например MongoDB, Redis) — это более гибкий подход: данные хранятся не только в таблицах, но и в виде документов, пар «ключ-значение» или графов, без жёсткой заранее заданной структуры, что удобно для быстро растущих проектов с разнородными данными.

Работа через API обычно состоит из трёх шагов: приложение отправляет запрос (например, «покажи данные о заказе номер 5»), сервер этот запрос обрабатывает, а затем присылает в ответ структурированные данные (обычно в формате JSON). Основные операции, которые выполняет API, описываются аббревиатурой CRUD:

# 1. приложение отправляет запрос
GET /api/orders/5 HTTP/1.1
Host: shop.example

# 2. сервер обрабатывает и присылает структурированные данные
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 5,
  "status": "paid",
  "total": 12500,
  "items": ["клавиатура", "мышь"]
}

UX (User Experience — пользовательский опыт) и UI (User Interface — пользовательский интерфейс) — два разных, но связанных направления в дизайне цифровых продуктов.

Работа над UX/UI обычно идёт по циклу:

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

layersТрёхслойная структура — самый распространённый вариант

• Слой представления (Presentation Layer) — верхний слой, с которым напрямую взаимодействует пользователь: показывает данные и собирает его действия, без какой-либо бизнес-логики внутри.
• Слой бизнес-логики (Business Layer) — «сердце» системы: получает запрос от слоя представления, обрабатывает его по установленным правилам и решает, что делать дальше.
• Слой доступа к данным (Data Access Layer) — нижний, самый устойчивый слой, где хранятся все записи и таблицы.

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

pros & consПлюсы и ограничения

После разработки продукт нужно куда-то «поселить», чтобы он был доступен пользователям — этот процесс называется развёртыванием (deployment), а место, где физически работает продукт — хостингом. Есть два основных варианта:

gitВерсионирование кода: зачем нужен Git

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

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

# сохранить изменения с описанием
$ git add .
$ git commit -m "добавлен модуль оплаты"

# параллельная работа над фичей — не мешает основному коду
$ git branch feature/notifications
$ git checkout feature/notifications

# аккуратно объединить, когда готово
$ git merge feature/notifications  # → основная ветка цела

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

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

Программный продукт — это не «просто код», а система слоёв и процессов. Интерфейс показывает и собирает действия, логика принимает решения по правилам, данные живут в базе; фронтенд выполняется у пользователя, бэкенд — на сервере, а связывает их API. Архитектура (монолит, слои, микросервисы) определяет, насколько легко продукт менять и масштабировать; хостинг и Git — где он живёт и как не потерять наработки; методологии и этапы — как команда доходит от идеи до работающего решения и сопровождает его дальше.