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

И если HLD, о которым мы уже говорили, – это, как раз, рабочий концепт, то LLD отвечает за те самые полочки, по которым нужно все раскладывать. Как это выглядит на деле? Сейчас расскажем.

РАЗБИРАЕМСЯ С ТЕРМИНОМ

LLD называют еще низкоуровневым дизайном (от английского “low-level design”). Но почему он низкий и при чем здесь дизайн? Низкий он только по сравнению с так называемым высоким дизайном (HLD) и только в том смысле, что описывает отдельные структурные единицы системы, а не саму систему в целом.

Проще говоря, высокоуровневый дизайн отвечает за общий план системы, низкоуровневый – за его отдельные компоненты.

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

Так даже понятнее: LLD – это детальное описание всех компонентов, конфигураций и процессов IT-инфраструктуры, утвержденных ранее в HLD. Если еще проще, LLD – это практическая детализация HLD.

LLD: КОГДА, КАК И ЗАЧЕМ?

Когда же нужно такое детальное описание конфигурации и всех механизмов будущей системы? Как правило, создание LLD становится завершающим этапом проектных работ – дальше идет уже внедрение и тестирование.

Грамотно прописанный LLD заметно ускоряет и упрощает процесс запуска любой IT-системы. Имея детализированное описание, специалисты четко видят требования по проекту и понимают, что именно и в какой последовательности им нужно делать. Часто, если такого описания нет, запуск и работа инфраструктуры осложняются разнообразными непредвиденными (недопроектированными) инцидентами.

Как и в случае с HLD, четкого свода правил, касающихся структуры документа, нет – она прописывается под конкретный проект. Но есть примерный алгоритм составления LLD, который использует большинство разработчиков:

• описание схем размещения и подключения оборудования;
• описание схем установки программных модулей;
• детализация рабочих режимов отдельных компонентов системы.

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

ДЛЯ ЧЕГО ЭТО НУЖНО?

Специалисты до сих пор спорят, а так ли нужен LLD и обязательно ли добавлять это описание в проектную документацию. Одни разработчики всегда включают в пакет документов этот раздел, другие – только в отдельных случаях, третьи вообще ничего не слышали о странной аббревиатуре. Но есть как минимум 3 причины, почему прописывать LLD выгодно и заказчику, и исполнителю:

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

Еще один важный момент. Даже если вы заказали разработку IT-системы стороннему исполнителю, используя LLD, в дальнейшем вы спокойно сможете поручить часть работ (или даже все работы) штатным специалистам. Ведь в описании собрана вся важная информация обо всех компонентах и особенностях конфигурации системы.