Установка, обновление и удаление программ

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Всем

---

Скачали установщик, нажали "Далее", появился ярлык — за этим знакомым сценарием стоят копирование файлов, запись в реестр или каталоги /etc, регистрация служб и нумерация версий. Та же программа через месяц может получить патч безопасности или крупное обновление с новым интерфейсом. Здесь — как изменения классифицируют, как их доставляют пользователю и чем установка отличается от простого копирования папки.

Связанные темы

Исполняемые файлы и форматы установщиков — Исполняемые файлы и архивы.

История изменений в команде — системы контроля версий (Git) в томе Код и разработка.

Поведение после смены настроек без переустановки — Поведение программ.

---

Установка, изменение и обновление

Изменение и модификация

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

Программа + изменение = Изменённая программа.

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

★ Модификация – изменение программы, для добавления новых функций или исправления ошибок. Она может быть как силами разработчика, так и силами сторонних лиц. Модификация может быть путём ручного редактирования кода, либо путём подготовки программы, которая автоматически внесёт изменения в код – патч.

Изменение может быть нескольких видов:

• функциональное — добавили кнопку "скачать";
• исправление ошибки (багфиксы);
• оптимизация — ускорили загрузку;
• рефакторинг — переписали код для лучшей читаемости;
• косметическое — изменение внешнего интерфейса;
• удаление функций.

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

---

1. Функциональное изменение

Добавление новой возможности, расширяющей поведение программы.

Примеры:

• Добавлена кнопка "Скачать как PDF" в интерфейсе отчётов,
• Реализована поддержка двухфакторной аутентификации через TOTP,
• Добавлен экспорт данных в формате CSV.

Особенности:

• Требует проектирования, тестирования, документирования,
• Может влиять на интерфейс API или пользовательский интерфейс,
• Часто сопровождается новыми зависимостями (библиотеками),
• Фиксируется как MINOR-версия в SemVer (например, 1.2.0 → 1.3.0).

---

2. Исправление ошибки (багфикс)

Устранение некорректного поведения при сохранении внешнего контракта.

Примеры:

• Исправлена ошибка округления при расчёте итоговой суммы заказа,
• Устранено падение приложения при вводе кириллицы в поле "Логин",
• Починена утечка памяти в цикле обработки входящих сообщений.

Особенности:

• Не добавляет новые функции, не удаляет старые,
• Цель — восстановить заявленное поведение,
• Часто сопровождается добавлением тестов, чтобы ошибка не вернулась,
• Фиксируется как PATCH-версия (например, 2.1.3 → 2.1.4).

---

3. Оптимизация

Улучшение производительности, потребления ресурсов или масштабируемости без изменения функциональности.

Примеры:

• Ускорена загрузка главной страницы с 3.2 с до 0.8 с за счёт кэширования данных,
• Снижено потребление памяти на 40% при обработке больших файлов,
• Увеличена пропускная способность API с 500 до 3000 запросов/сек.

Особенности:

• Внешнее поведение не меняется — те же входы → те же выходы,
• Может потребовать изменения архитектуры (переход на асинхронность, пул соединений),
• Требует замеров до/после (бенчмаркинг),
• Может быть PATCH или MINOR — в зависимости от глубины изменений.

---

4. Рефакторинг

Перестройка внутренней структуры кода для улучшения читаемости, поддерживаемости и расширяемости.

Примеры:

• Замена 200-строчного метода processOrder() на 5 маленьких функций с говорящими именами,
• Выделение работы с базой данных в отдельный класс UserRepository,
• Внедрение зависимостей вместо прямого создания объектов (new Database() → inject(db)).

Особенности:

• Поведение программы не должно измениться — все тесты проходят как раньше,
• Цель — уменьшить технический долг,
• Часто предшествует крупным изменениям ("расчистка места"),
• Обычно не влияет на номер версии (фиксируется в changelog как "internal").

---

5. Косметическое изменение

Модификация внешнего вида без влияния на логику.

Примеры:

• Изменение цветовой схемы с синей на тёмно-серую,
• Замена иконки "Корзина" на более современную,
• Выравнивание полей формы по сетке.

Особенности:

• Может требовать согласования с дизайнерами и юзер-тестов,
• Нередко сопровождается изменением CSS, SVG, шрифтов,
• Редко влияет на функциональные тесты, но требует визуального контроля (visual regression testing),
• Обычно не ведёт к повышению версии, но может быть частью MINOR-релиза.

---

6. Удаление функций

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

Примеры:

• Удалён устаревший API-метод /v1/old-login, оставлен только /v2/auth,
• Убрана поддержка Internet Explorer 11,
• Отключена экспериментальная функция "Авто-перевод", не набравшая популярности.

Особенности:

• Требует предупреждения пользователей (deprecation notice),
• Часто сопровождается миграционными скриптами или адаптерами,
• Является ломающим изменением — фиксируется как MAJOR-версия (например, 3.9.2 → 4.0.0),
• Документируется в changelog с указанием альтернатив.

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

---

Версионность

Play ITЗагрузка интерактивного демо…

Каждое такое изменение порождает новую версию программы, даже если оно кажется мелким.

Версия — это уникальный идентификатор состояния программы на определённый момент времени. Пример - v1.0.0.

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

Самый распространённый стандарт — семантическое версионирование (SemVer, Semantic Versioning).

Формат:

MAJOR.MINOR.PATCH

• MAJOR (мажор) — основная версия при несовместимых изменениях (ломающие обновления);
• MINOR (минор) — дополнительная функциональность при обратно совместимых улучшениях;
• PATCH — поправки при исправлениях ошибок, без новых фич.

Подробнее о стандарте — в глоссарии: Semantic Versioning.

Полный номер версии

Базовая тройка MAJOR.MINOR.PATCH — обязательная часть. К ней по правилам SemVer можно добавить два опциональных суффикса:

MAJOR.MINOR.PATCH[-пре-релиз][+сборка]

Пример: 1.2.3-alpha.1b+123.ab.

• Пре-релиз (после дефиса -) — сборка ещё не считается стабильным релизом — ранняя альфа, бета, кандидат в релиз (-alpha.1, -beta.2, -rc.1). Такие версии ниже той же тройки без суффикса: 1.2.3-alpha предшествует 1.2.3 при сравнении. Пакетные менеджеры и CI часто не подставляют пре-релиз автоматически, пока вы явно не разрешите "нестабильные" версии.
• Метаданные сборки (после плюса +) — служебная метка — номер сборки в CI, хеш коммита, дата. На порядок версий при сравнении не влияет: 1.2.3+build.1 и 1.2.3+build.99 считаются одной и той же версией 1.2.3 с точки зрения совместимости; различаются только подпись артефакта.

Пользователь в магазине приложений или в "О программе" чаще видит либо короткий номер 1.2.3, либо маркетинговую подпись ("Beta 5"); полная строка с + обычно нужна разработчикам и службам обновления.

Стадии до стабильного релиза

Пока продукт не готов к массовой поставке, его прогоняют через цепочку стадий — каждая получает свой номер или пре-релизный суффикс:

1. Alpha (альфа) — ранняя внутренняя сборка — функции могут быть сырыми, интерфейс меняется, критичные сценарии ещё не закрыты.
2. Beta (бета) — более зрелая версия для ограниченной аудитории (тестировщики, early access): основной функционал на месте, ищут регрессии и краевые случаи.
3. RC (Release Candidate) — кандидат в релиз: команда считает, что при отсутствии серьёзных багов эту сборку можно выпустить как стабильную. Бывает несколько кандидатов подряд (RC1, RC2) — исправили найденное на RC1, собрали RC2.
4. Release (релиз) — стабильная версия для всех: в SemVer это обычно MAJOR.MINOR.PATCH без пре-релизного суффикса (например, 2.1.0).

Суффиксы в номере и названия стадий часто совпадают: 2.0.0-beta.3, 2.0.0-rc.1, затем 2.0.0. Переход с бета на релиз — смена статуса качества: меняется политика обновлений, поддержки и ожиданий пользователей.

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

Чтобы управлять изменениями, используются системы контроля версий — например, Git. Такая система хранит историю кода, позволяет сравнивать правки, работать нескольким разработчикам параллельно и откатиться к любому коммиту. Вход в тему — Терминал (многие команды Git вводятся из командной строки) и раздел Код и разработка.

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

• Добавление - что-то новое;
• Изменение - модификация существующего;
• Удаление - убираем существующее;
• Переименование или рефакторинг - изменение структуры;
• Исправление - устранение ошибок.

Каждое из этих действий фиксируется как коммит в системе контроля версий и вносит вклад в следующую версию.

---

Патч и обновление

★ Патч – маленькое обновление, которое может относиться как к модификации, так и к обновлению.

★ Обновление – термин близкий к модификации, но отличается, в основном, масштабом и самим процессом. К примеру, процесс обновления ПО может включать в себя изменение существующей версии ПО путем установки поверх неё модифицированной версии. Пример – обновление Windows, Chrome – когда разработчики подготовили изменения, выгрузили в виде пакета (патча), а мы загружаем и устанавливаем новую версию программы поверх предыдущей.

Особенности патча:

• Малый объём: может содержать изменения всего в нескольких строках кода или конфигурации,
• Высокая специфичность — исправляет одну уязвимость, один баг или одну неточность,
• Срочность выпуска: патчи безопасности (Безопасность patches) часто выпускаются в течение часов после обнаружения угрозы,
• Минимальное тестирование — проверяется только затронутый сценарий, чтобы ускорить доставку,
• Формат доставки:
  — .diff / .patch — текстовый файл с инструкциями diff (+ и -),
  — бинарный дельта-патч — разница между двумя версиями исполняемого файла (экономия трафика),
  — hotfix-сборка — отдельный мини-релиз (например, v2.1.3-hotfix1).

Примеры патчей:

• Уязвимость Log4Shell (CVE-2021-44228): патч отключил интерпретацию JNDI в строках логирования. Обновление log4j-core с 2.14.1 → 2.15.0 состояло из нескольких строк кода, но предотвратило удалённое выполнение кода.
• Исправление времени в Excel 1900 года: патч сохранил ошибку совместимости (1900 високосный), но документировал её — чтобы формулы не ломались.
• Hotfix для игры: патч исправил краш при запуске миссии "Склад-7", не затрагивая остальной баланс.

Патчи часто применяются инкрементально: система обновлений скачивает только дельту, а не весь установочный пакет. Например, Steam использует алгоритм bsdiff для минимизации трафика.

Особенности обновления:

• Сборка из множества изменений — включает багфиксы, оптимизации, новые функции, рефакторинги,
• Планируемый цикл — регулярные релизы — еженедельные (микрообновления), ежеквартальные (minor), ежегодные (major),
• Полный тестовый цикл — регрессионное тестирование, нагрузочные пробы, юзер-тесты,
• Сопровождающая документация:
  — CHANGELOG.md — список изменений,
  — UPGRADE.md — инструкции по миграции,
  — release notes — описание для конечных пользователей.

Виды обновлений:

Тип	Цель	Пример
Инкрементальное	Мелкие улучшения без нарушения совместимости	v1.2.4 → v1.2.5 (только багфиксы)
Фича-обновление	Добавление функций в рамках текущей архитектуры	v2.1.0 → v2.2.0 (добавлен dark mode)
Мажорное обновление	Кардинальные изменения: API, архитектура, форматы	v3.9.2 → v4.0.0 (переход с REST на GraphQL)
Принудительное	Требуется для продолжения работы (часто — безопасность)	Обновление TLS-библиотеки до версии с поддержкой TLS 1.3
Опциональное	Новые возможности, не критичные для базовой работы	Добавление поддержки нового формата файлов

Механизмы доставки обновлений:

• Автоматическое фоновое — браузеры (Chrome), мессенджеры (Telegram), ОС (Windows Update),
• По запросу — пользователь нажимает "Обновить" в интерфейсе,
• Ручное — скачивание установщика с сайта и запуск,
• Корпоративное — развёртывание через групповые политики (GPO), MDM, Ansible.

Особые случаи:

• Роллбэк — откат к предыдущей версии при обнаружении критического бага в новом релизе,
• Канареечное развёртывание — обновление сначала 1% пользователей, затем 5%, затем 100%,
• Feature flags — новые функции уже в коде, но скрыты за флагами; включаются без нового обновления.

---

Установка

Установка программ обычно выглядит так:

Play ITЗагрузка интерактивного демо…

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

Установка преобразует программу из поставляемого артефакта (архив, образ, пакет) в рабочее состояние.

---

Этапы установки

Этап	Действия	Примеры
1. Проверка требований	Анализ ОС, версии, архитектуры, свободного места, зависимостей	Установщик проверяет: Windows 10+, x64, 4 ГБ RAM, .NET Runtime 6.0
2. Распаковка файлов	Копирование исполняемых файлов, библиотек, ресурсов	.exe, .dll, icons/, lang/ru.json → C:\Program Files\App\
3. Настройка окружения	Создание ярлыков, запись в PATH, регистрация типов файлов	Ярлык на рабочем столе; assoc .xyz=MyApp в Windows
4. Работа с реестром / конфигами	Сохранение путей, лицензий, настроек по умолчанию	Ветка HKEY_LOCAL_MACHINE\SOFTWARE\MyApp; файл config.defaults.json
5. Установка зависимостей	Загрузка и развёртывание runtime’ов, библиотек	Установка Visual C++ Redistributable, JRE, .NET Desktop Runtime
6. Регистрация служб	Настройка автозапуска фоновых компонентов	sc create MyAppService binPath=... → служба в services.msc
7. Первичная инициализация	Генерация ключей, создание БД, настройка прав	CREATE DATABASE app_db; mkdir %APPDATA%\MyApp\cache
8. Финальная проверка	Запуск self-test, проверка целостности	Хеш-суммы файлов; app.exe --self-test

---

Типы установщиков

Тип	Описание	Плюсы / Минусы
Инсталляторы "всё в одном" (Inno Setup, NSIS, WiX)	Самораспаковывающийся .exe, содержит все файлы и логику	+ Полный контроль, + Работает без интернета – Большой размер, – Сложность поддержки
Пакетные менеджеры ОС (apt, dnf, winget, choco)	Установка через команду: apt install firefox	+ Зависимости разрешаются автоматически + Обновления централизованы – Требует прав администратора, – Версии могут отставать
Портативные приложения (PortableApps)	Распаковка архива → запуск .exe без установки	+ Нет следов в системе, + Можно носить на флешке – Нет интеграции (ярлыки, ассоциации), – Ручное обновление
Веб-инсталляторы	Маленький загрузчик → скачивает основное тело онлайн	+ Быстрый старт, + Всегда актуальная версия – Требует интернета, – Риск MITM-атак без подписи
Контейнеры (Docker)	docker run -p 8080:80 nginx — мгновенный запуск изолированного образа	+ Полная изоляция, + Идемпотентность – Требует Docker, – Сложнее для новичков

В корпоративной среде часто встречают также:

Режим	Суть
Тихая (silent)	Без окон и вопросов пользователю — для массовой раскатки
Автоматическая (unattended)	Параметры заранее в файле ответов или через GPO/MDM
OEM	ПО предустановлено на устройстве продавцом
Чистая	Установка "с нуля" без остатков старой версии (часто с форматированием раздела)

Инженерный контекст фазы "внедрение" в SDLC — в жизненном цикле ПО.

---

Особенности установки на разных платформах

• Windows:
  — Централизованное хранение в Program Files,
  — Реестр как единое хранилище настроек,
  — UAC — контроль учётных записей для защиты от вредоносных действий,
  — MSI — стандарт корпоративного развёртывания (тихая установка, откат, аудит).

• Linux:
  — Файлы распределяются по ФС — /bin, /lib, /etc, /var/log,
  — Зависимости строго контролируются (dpkg -l, rpm -qa),
  — Flatpak / Snap — sandbox’ы для изоляции приложений от системы,
  — AppImage — portable-аналог для Linux.

• macOS:
  — Приложения — это папки .app, перетаскиваемые в /Applications,
  — Gatekeeper — проверка подписи разработчика,
  — Notarization — дополнительная проверка Apple,
  — Homebrew — популярный менеджер пакетов для разработчиков.

---

Проблемы при установке и их решения

Проблема	Причина	Решение
"Требуется более новая версия Windows"	Проверка манифеста исполняемого файла	Обновление ОС или запуск в режиме совместимости
"Отсутствует VCRUNTIME140.dll"	Не установлен Visual C++ Redistributable	Скачать и установить с сайта Microsoft
"Доступ запрещён"	Антивирус или политикой блокируется запись	Добавить исключение или запустить от имени администратора
"Повреждённый установочный файл"	Обрыв загрузки, битый архив	Проверить хеш (sha256sum), перекачать
"Конфликт с уже установленной версией"	Старые файлы мешают новым	Удалить старую версию через "Программы и компоненты"

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

---

Удаление (деинсталляция)

★ Удаление программы — снятие приложения с компьютера — файлы, ярлыки, записи реестра (Windows), службы, иногда пользовательские данные (с подтверждением).

Платформа	Как удаляют
Windows	"Приложения" / "Программы и компоненты", MSI с /uninstall, winget uninstall
Linux (пакеты)	apt remove, dnf remove
macOS	Перетащить .app в корзину; brew uninstall
Портативные	Удалить папку вручную

---

Журнал изменений

## [2.1.0] - 2026-05-01
### Added
- Экспорт отчётов в PDF
### Fixed
- Округление суммы в корзине

---

Написание кода

Так, программирование — это процесс создания программы, написания кода. Как же пишут код?

Код пишут по определённому порядку. Основные парадигмы:

• Императивная (C, Python) — явная последовательность шагов.
• Функциональная (Haskell, фрагменты в Python/JS) — вычисления через функции без изменения внешнего состояния.
• ООП (Java, C#) — данные и поведение в объектах.

Функциональное программирование – стиль программирования, где программа строится из функций, не изменяющих исходные данные, а возвращающих новые. Представим, что программа – конвейер, где функции – станки, которые берут входные данные (сырье) и выдают результат (продукт), но при этом сырьё не испортится (исходные данные не изменяются, так как работа велась с их копиями). ФП применяется в обработке данных (анализ логов, Big Data), фронтенде (React, Redux), бэкенде (Elixir, Haskell), и в научных вычислениях, математических моделях. В повседневности примеры чистых функций – в Excel, формулы вроде =СУММ(A1:A10) — не меняют исходные ячейки, но дают результат; разбор типовых формул — Excel и Google Sheets — формулы — Lab.

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

Но программирование не всегда связано с компьютером в классическом понимании. Все электронные устройства программируются, в том числе – стиральные машины, микроволновки, роутеры, медицинские приборы. Оно может происходить через встроенное ПО (Firmware), вшитое в устройство, либо через внутрисхемное программирование (ISP), когда программа загружается в микросхему прямо в устройстве через специальные контакты. Для таких процедур используется специальное оборудование – программатор и отладочная плата. Именно так подключают устройство к микроконтроллеру и загружают прошивку через специальное ПО. Но погружаться в это мы не будем, фактически, это уже глубокая техническая инженерия, а не "айти" в том понимании, в котором мы к нему идём.

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

---