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

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

Начнём с простого класса:

public class Report
{
    public void Generate()
    {
        Console.WriteLine("Отчёт создан");
    }

    public void PrintReport()
    {
        Console.WriteLine("Отчёт напечатан");
    }

    public void SaveToPdf()
    {
        Console.WriteLine("Отчёт сохранён в PDF");
    }

    public void SendByEmail()
    {
        Console.WriteLine("Отчёт отправлен по электронной почте");
    }
}

Выглядит нормально. Четыре метода, понятная логика. Но проходит неделя, и заказчик говорит:

«Теперь нужно сохранять отчёт не только в PDF, но и в Excel».

Окей, добавляем метод SaveToExcel(). Ещё через неделю:

«А можно ещё в Word?»

Добавляем. Потом — «отправлять в Telegram». Потом — «выгружать в Google Drive». Потом — «в облако». Потом — «распечатать автоматически после генерации»...

Что происходит с нашим классом Report? Он начинал с четырёх методов — а теперь в нём двадцать. Генерация, сохранение в пять форматов, отправка в три канала, печать, архивирование, конвертация. Универсальный комбайн, который делает всё подряд.

И самое страшное — если вы попробуете что-то в нём поменять, неизвестно, что именно сломается.

Вы можете возразить: «я аккуратный, я не сломаю». Возможно. Но в реальных проектах над кодом работает не один человек — иногда десятки. И если каждый «аккуратно добавляет по чуть-чуть», через полгода класс превращается в тысячу строк, половину из которых никто не помнит, зачем написал. Наш пример был максимально упрощённым — методы просто выводят текст в консоль. А теперь представьте, что вместо Console.WriteLine() там реальная работа: файловая система, база данных, сетевые запросы, API, шифрование. Маленькое изменение в одном месте запускает цепную реакцию по всему проекту.

Вот конкретно, на что влияет архитектура:

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

Надёжность. Когда код спроектирован правильно, можно добавить модуль, изменить логику или переписать часть системы — остальное продолжает работать. Без архитектуры — любое изменение как домино: тронул одну костяшку — упали все.

Тестирование. Маленькие, изолированные классы легко тестировать по отдельности. Класс-комбайн на тысячу строк — тестировать можно только целиком, запуская всю систему. Время на тесты растёт, уверенность в коде — падает. Нам повезло — программирование развивается десятки лет, и разработчики успели набить шишек за нас. Из этого опыта выросли принципы, которые помогают проектировать код правильно с самого начала.

Роберт Мартин (он же «Дядя Боб») в начале 2000-х собрал лучшие практики проектирования и сформировал набор из пяти принципов — SOLID:

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

Не пытайтесь запомнить все пять прямо сейчас. Каждому принципу посвящён отдельный урок с примерами, кодом и практикой. Сейчас важно понять главное: SOLID — это не академическая теория. Это инструмент, который решает реальные проблемы реального кода.

Примеры в этом курсе — на C#, но принципы SOLID не привязаны к языку. Они работают в Java, Python, TypeScript, Go — везде, где есть объекты, классы и интерфейсы. Освоив их здесь, вы сможете применять в любом проекте, на любом языке.

Ну что ж — вперёд, к первому принципу. S — Single Responsibility.