Практический сборник советов для проектных команд, выросший из опыта программной инженерии.
Проблема, которую все узнают
Откройте папку любого проектного института — и вы увидите знакомую картину: «План_2_эт_финал.pdf», «План_2_эт_финал_2.pdf», «План_2_эт_испр_после_замечаний_ОЛЕГ_НЕ_ТРОГАТЬ.dxf». Каждый файл — маленькая драма: кто автор последней правки, что из этого актуально, можно ли отправлять заказчику. Ответы на эти вопросы добываются не из имён, а из устных договорённостей, которые забываются через неделю.
У программистов эта война проигрывалась и выигрывалась десятилетиями. Команда из пяти человек способна договориться на пальцах; команда из пятидесяти — уже нет. Всё, что там выработано, переносится на проектирование почти дословно, потому что болезнь одна и та же: совместная работа над общими данными без соглашения об именах. Отличие лишь в том, что у проектировщика «код» — это модель, чертежи и свойства объектов, а цена ошибки измеряется не откатом коммита, а переделкой стадии.
Суть всей системы, о которой пойдёт речь, укладывается в одну фразу: имя отвечает на вопрос «что это», код отвечает на вопрос «как это найти», а состояние — версия, статус, автор — вообще не живёт в имени.
Три имени одного документа
Первый принцип, который стоит принять, — у любого документа в проекте не одно имя, а три. И у каждого — своя задача и своя аудитория.
Самая частая ошибка — сваливать эти уровни в одну строку: АР_04_01_план_финал_иванов.rnp. В такой конструкции теряется всё сразу: шифр перестаёт быть стабильным идентификатором, человекочитаемая часть тонет в служебном шуме, а фамилия автора, записанная в имя, устаревает в тот же день, когда человек уходит в отпуск.
Разделение уровней — не бюрократия, а тот же приём, что в программировании называется разделением идентификатора и заголовка: у тикета в трекере есть номер (PROJ-142) и человеческое название («Падает форма заказа при пустой корзине»). Номер никогда не меняется, название — сколько угодно. Оба нужны, но путать их не стоит.
Уровень первый: шифры и обозначения
Здесь ничего не нужно изобретать. Российская система СПДС уже содержит готовую структуру обозначений: базовое обозначение здания плюс марка комплекта плюс порядковый номер — 2345-12-ЭО.1, 2345-12-ЭО.2, 2345-12-ЭО.11. Каждый сегмент несёт свой слой информации: от чего зависит, что это за комплект и какой в нём лист. Ничего лишнего в обозначении нет — и это признак хорошей системы.
Два правила, которые стоит закрепить с самого начала.
Ведущие нули. К однозначным порядковым номерам допускается добавлять ноль слева (АР-04, а не АР-4). Причина проста: при сортировке без нулей лист номер 11 встанет между листами 1 и 2. Список, который неправильно сортируется, — это список, в котором нельзя ничего найти.
Разделение комплекта — не смена марки. Когда архитектурный комплект перестаёт помещаться в один раздел, его делят на АР1 и АР2, а не придумывают новую марку. Структура меняется, а принадлежность к архитектурному разделу — нет.
Если команда работает в междисциплинарной среде и обменивается данными с подрядчиками, стоит поднять планку до международного стандарта ISO 19650. Его схема имени файла — конвейер фиксированных полей:
Например: 0123-ARC-ZZ-01-DR-A-0001-P01.dxf — проект 0123, создатель — организация ARC, все зоны, первый этаж, чертёж, роль — архитектор, лист 0001, первая предварительная ревизия. Требования к написанию скучны, но неслучайны: только латиница, цифры, дефис и подчёркивание, никаких пробелов и спецсимволов. Файл с таким именем пройдёт через любую систему, шлюз, конвертер и почтовый сервер без искажений. Кириллическое «План второго этажа (финал).dxf» — не пройдёт.
Ручное проставление таких имён — главный источник разнобоя, и его тоже можно убрать. В Renga экспорт чертежей в DXF, DWG, PDF и OXPS доступен не только через интерфейс, но и через API: например для DXF метод ExportToDxf() вызывается для каждого листа проекта, а путь и имя итогового файла задаются программно. Это значит, что скрипт может сам собрать имя файла из полей проекта — раздела, номера листа, имени или свойств чертежа — по вашему шаблону и сохранить каждый лист отдельным файлом с гарантированно одинаковым именованием. Пример такого скрипта на Python выложен на GitHub: он экспортирует чертежи по разделам с учётом раздела и номера листа одной командой. Тот же приём лежит в основе готовых подключаемых модулей пакетного экспорта: листы сохраняются в отдельные файлы, а при экспорте по разделам для каждого раздела автоматически создаётся своя папка.
Отсюда практический вывод: именование файлов — это не ежемесячная дисциплина «набрать правильно», а одноразовая настройка шаблона в скрипте. Один раз договорились, как собирается имя из полей листа, — и дальше каждый экспорт воспроизводит договорённость без участия памяти и внимательности человека.
Уровень второй: имена, которые читают люди
А вот это уже творческая задача — и самая недооценённая. Человекочитаемое имя листа видно в обозревателе проекта, в штампе, в переписке и в устной речи на совещании. Плохое имя здесь стоит дороже, чем плохой шифр: шифр хотя бы стабилен.
Основа — шаблон «Серия. Объект. Уточнение»: от общего к частному, как оглавление книги.
Почему именно такой порядок? Потому что человек сканирует список сверху вниз, как читает оглавление. Сначала ему нужно понять, в какой раздел смотреть, и только потом — какой именно лист. Имя «Экспликация помещений на плане 2 этажа» заставляет искать глазами по всей длине строки; имя «Планы этажей. 2-й этаж. Экспликация помещений» позволяет найти нужное за полсекунды.
К этому шаблону хорошо подходят четыре совета.
Один шаблон на серию. Листы одной серии выигрывают, когда отличаются только наполнением слотов, а не структурой. Если в одном листе написано «Фасад в осях А-Д», а в соседнем — «Южный фасад (ось А)», значит, в проекте уже два словаря, и поиск глазами сломан. Появление «свободной формы» в серии — подсказка, что договорённости не работают.
Только содержательные слова. «Финал», «окончательный», «испр», «после замечаний», даты и фамилии — всё это состояние документа, и у состояния есть свои законные места: ревизия в штампе, статусный код в имени файла, история версий в системе документооборота. Слово «финал» в имени — это не информация, а обещание, которое устареет при первой же правке.
Единый словарь внутри серии. «Этаж» или «уровень», «отметка» или «высота» — выберите один термин и запишите его. Между дисциплинами легенды могут и должны различаться: архитектору естественно писать «2-й этаж», а инженеру по вентиляции — «Ур. +3.300». Но внутри одной серии одно понятие должно называться одним словом — иначе каждый поиск превращается в перебор синонимов.
Три–семь слов. Хорошее имя короткое, но не за счёт смысла. «План» — мало: какой план? «План типового 2-го этажа 2-секционного жилого дома с экспликацией и ведомостью отделки» — слишком: половину этих сведений несут штамп и легенда. Всё, что можно вынести из имени в штамп, — выносите.
Наглядно — до и после:
Любопытная деталь: в правой колонке нет ни одного слова, которое пришлось бы выкинуть из левой, — их там просто нет с самого начала. Это признак удачного шаблона: правильная структура не оставляет места для мусора.
Уровень третий: свойства и параметры
С именами свойств ситуация тоньше: их читают чаще, чем имена листов. Каждый раз, когда инженер открывает свойства или строит спецификацию, он смотрит на десятки имён параметров. И если те написаны на языке личных аббревиатур автора, каждая спецификация превращается в расшифровку.
Первый совет — полные слова вместо сокращений. Аббревиатура — это кэш для тех, кто уже в контексте, и мусор для всех остальных. «Огнестойкость» прочитает любой; «Огнстк» — только автор. Сокращение хорошо работает, только если оно общепринято и однозначно — как правило, это означает «закреплено в нормах». Личные сокращения лучше оставить за дверью проекта.
Второй — естественный порядок слов: существительное, потом определения, потом уточнение. Не «Стена толщина наружная», а «Толщина наружной стены». Человек ищет в имени главное слово, а не последнее.
Третий — не дублировать контекст, который и так есть. Параметр «Огнестойкость стены» на объекте-стене избыточен: понятно, что это свойство стены. Достаточно «Огнестойкости». Это тот же приём, что и в коде: дублировать родителя в имени ребёнка — лишняя работа для всех.
Четвёртый — единицы измерения в имени, только если их не видно рядом со значением. Если система показывает «300 мм» — не надо. Если параметр текстовый и люди вписывают туда вперемешку «300», «0,3» и «300 мм» — имя с единицами дисциплинирует: «Толщина, мм».
Пятый — одно понятие — одно имя во всём проекте. Если «Марка» в одном объекте означает прочность бетона, а в другом — обозначение стали, это два разных понятия, и им лучше дать два разных имени: «Класс бетона» и «Обозначение профиля». Совпадение имён при несовпадении смыслов — источник тихих ошибок в спецификациях и фильтрах.
И шестой — имя не заменяет данные. Имя свойства «Дверь_FD30» заставляет всех, кто работает с моделью, тратить время на расшифровку строки. Спокойнее и надёжнее — параметр «Огнестойкость» со значением FD30: по нему строятся спецификации, фильтры и раскраски видов, по имени — нет.
Проверка любого имени занимает десять секунд: произнесите его и значение вслух. «Расчётная нагрузка — четыреста килограммов» звучит как нормальный рабочий диалог. «RL_N_400» — как шифровка, которую кто-то забыл расшифровать.
Как быть с экспертизой
До сих пор речь шла о том, чтобы имена жили в проекте. Но у проекта в России есть ещё один читатель — экспертиза, которая принимает проектную документацию вместе с цифровой информационной моделью в открытом формате IFC. И у этого читателя своё представление о хороших именах: атрибутивный состав элементов задан нормами, например в СП 333.1325800.2020, где для каждой сущности определены таблицы свойств — «Характеристики стен», «Характеристики стальных конструкций» и так далее. Экспертиза ждёт, что свойства будут переданы с конкретными именами, в конкретных наборах и с конкретными типами данных.
Возникает естественный конфликт: по всем советам из предыдущего раздела имя в модели должно быть удобным людям — «Огнестойкость», «Толщина наружной стены», — а экспертизе нужен свой словарь. Хорошая новость: эти два словаря не обязаны совпадать, потому что между ними есть переводчик.
В Renga этот переводчик называется сопоставлением параметров. Все пользовательские свойства, параметры и расчётные характеристики модели при экспорте в IFC4 передаются по правилам, описанным в файле сопоставления: правила хранятся в JSON, а путь к файлу задаётся в настройках программы во вкладке Экспорт. В базовой поставке Renga идёт готовый файл export_attr_qto_pset.json — он подходит для экспорта в соответствии IFC4 Reference View 1.2, а для конкретной экспертизы его заменяют.
Устроен файл просто: правило вида «ключ: значение», где ключ — имя атрибута в IFC, а значение — имя свойства в модели Renga. Для каждого класса объекта есть три группы: attributes (атрибуты IFC), psets (наборы пользовательских свойств) и qsets (наборы расчётных характеристик). Например, в группе атрибутов стены пара Name: Имя означает, что поле «Имя» из Renga попадёт в IFC как Name. А для требований экспертизы в psets заводят отдельный набор — скажем, ExpCheck_Wall — и перечисляют в нём свойства, которых ждёт проверка: наборы с префиксом ExpCheck_ — пользовательские.
Из этого следуют три совета.
Не переименовывайте свойства ради экспертизы. Если требуемое имя появилось в модели (снова «Дверь_FD30» вместо человеческого названия и отдельного свойства), вы платите удобством команды за то, что перевод можно поручить файлу сопоставления. Модель остаётся на языке команды — в IFC она уходит на языке экспертизы.
Следите за типами данных, а не только за именами. Чтобы экспертиза (и любые другие проверки) однозначно читала модель, свойства должны не только называться правильно, но и иметь правильный тип: длина, площадь, объём, целое число, логический, перечисление. Свойство, заполненное текстом «300 мм» там, где положено число с типом «Длина», при экспорте не станет корректным атрибутом — ни одним файлом сопоставления этого не исправить, потому что переводить нечего.
Ведите словарь соответствий и храните файлы сопоставления как проектные документы. Файл сопоставления параметров — это фактически двуязычный словарь между вашим проектом и требованиями конкретной экспертизы, и у разных экспертиз требования различаются. Если команда экспортирует модель и для Мосгосэкспертизы, и для петербургской, для каждой цели держат свой файл со своим понятным именем — и тогда очередная досдача или повторный экспорт не превращаются в восстановление всех наименований с нуля.
Смысл раздела в том, что имена в проекте живут в нескольких системах координат сразу: словарь команды, словарь норматива, словарь смежников. Попытка уравнять их все в одном имени обречена — а разведение по разным уровням с переводом на границе (файл сопоставления в Renga, именованные наборы в IFC) позволяет каждому словарю оставаться самим собой.
Пять общих советов
Оставляйте состояние вне имени. Статус, версия, автор и дата живут в полях, ревизиях и системах документооборота. «Финал» в имени — не статус, а загадка.
Не дублируйте данные в имени. Если свойство уже есть — имени оно не нужно: спецификации работают по свойствам, а не по разбору строк.
Не смешивайте алфавиты и разделители. Кириллица — для человекочитаемых названий, латиница — для технических имён. Один разделитель между полями, один — внутри поля.
Сокращайте только с общепринятой расшифровкой. Марки из норм — можно; личные «шпм» и «тлщст» — лучше нет.
Не плодите сущности. Каждый дубль параметра — будущий конфликт версий истины.
Вместо заключения
Всё, о чём шла речь, умещается в один небольшой документ: коды дисциплин, шаблоны серий листов, статусные коды, словарь терминов. Собрать такой документ можно не спеша — записывайте в него те правила именования, которые в вашем проекте приходится повторять чаще всего, и через несколько недель у вас будет не абстрактная инструкция, а живая шпаргалка, проверенная реальной работой.
Совет по проверке простой: посмотрите на это глазами нового коллеги. Если ему на первой неделе легко найти нужный лист по названию — договорённости работают. Если нет — это не упрёк человеку, а подсказка, где систему стоит мягко поправить.
И последнее. Хорошее имя — это лицо проекта: оно читается глазами за секунду и не требует пояснений, чтобы понять, что перед вами. Имена, которые так устроены, незаметно делают совместную работу спокойнее — меньше переспрашиваний, меньше «какая из версий актуальная», меньше потерь. Каждый шаг к такому именованию окупается быстрее, чем кажется, а начать можно хоть с завтрашнего листа «Планы этажей. 2-й этаж» — просто переименовав его как следует.
Комментарии
Отправить комментарий