Проблема накопления опыта в командах разработки 1С стоит очень остро. Часто знания распределены между головами экспертов, а при их уходе из проекта часть компетенций безвозвратно теряется, превращая код в «черный ящик». Рассмотрим подробнее, какие инструменты и подходы существуют для создания единой среды накопления опыта, начиная от специализированных решений на платформе 1С и заканчивая современными ИТ-практиками.
Разберем первый и наиболее логичный путь для экосистемы 1С — использование СППР. Это конфигурация от фирмы «1С», специально созданная для управления процессом разработки. Проанализируем, почему она может стать фундаментом вашего «Облака знаний»:
Однако стоит учитывать, что СППР — довольно тяжеловесный инструмент, требующий дисциплины от всей команды. Если ваша цель — быстрая фиксация «заметок на полях», возможно, стоит рассмотреть более легкие альтернативы.
Посмотрим на опыт команд, которые выносят базу знаний за пределы 1С. Традиционным решением является использование Wiki-движков или корпоративных порталов типа Confluence. Выясним причины их популярности:
Проанализируем современный тренд — использование Obsidian. Это приложение для ведения заметок, работающее с локальными текстовыми файлами в формате Markdown. Рассмотрим, почему оно идеально подходит для формирования «базы связей»:
В отличие от классических папок, Obsidian позволяет строить граф знаний. Вы создаете атомарную заметку (например, «Оптимизация запроса к Регистру Бухгалтерии») и связываете ее с другими заметками через двойные скобки. Постепенно у вас формируется сеть взаимосвязей, где видно, какие подсистемы наиболее сложны и как они пересекаются.
Пример оформления ссылки в Markdown, который понимает Obsidian:
[[МетодыОбменаСГИСМ]] — такая ссылка мгновенно создаст связь между текущей статьей и описанием модуля маркировки.
Разберем один из самых прогрессивных подходов, который решает проблему устаревания знаний. Суть заключается в том, что документация хранится в том же репозитории Git, что и сам код 1С. Выясним преимущества этого метода:
readme.md обновляет описание функции.Посмотрим, как автоматизировать создание базы знаний с помощью инструментов тестирования. Vanessa Automation позволяет писать сценарии на языке Gherkin. Рассмотрим пример такого сценария:
Функционал: Создание документа Реализация
Как ведущий менеджер
Я хочу создавать документ реализации
Чтобы отразить отгрузку товара
Сценарий: Проверка заполнения даты
Допустим, я открываю форму документа "Реализация товаров и услуг"
Когда я нажимаю кнопку "Записать"
Тогда система должна выдать предупреждение "Поле 'Дата' не заполнено"
Этот текст является одновременно и тестом, и актуальной инструкцией. Если логика программы изменится, тест упадет, что заставит разработчика обновить «живую документацию».
Проанализируем мнение экспертов о том, что «хороший код — это уже документация». Выясним, как писать код так, чтобы его не пришлось расшифровывать через год:
тз или стр для переменных «дальнего действия». Используйте понятные имена: ТаблицаОстатковТоваров, ТекущаяСтрокаЗаказа.Рассмотрим пример правильного оформления заголовка функции для автоматического сбора знаний:
// Проверяет возможность отгрузки товара по складу.
//
// Параметры:
// Номенклатура - СправочникСсылка.Номенклатура - Товар для проверки
// Склад - СправочникСсылка.Склады - Склад отгрузки
//
// Возвращаемое значение:
// Булево - Истина, если остаток положителен
//
Функция ПроверитьДоступностьТовара(Номенклатура, Склад) Экспорт
// Логика функции
КонецФункции
Выясним причину скепсиса многих разработчиков относительно баз знаний. Часто они превращаются в склад старых файлов на сетевом диске (File System - FS), где невозможно ничего найти. Чтобы этого избежать, мы рекомендуем:
obsolete или переноситься в архив, чтобы не вводить в заблуждение новых участников команды.Таким образом, выбор инструмента зависит от масштаба команды. Для небольших групп идеально подходит Obsidian или Git с Markdown-файлами. Для крупных корпоративных внедрений лучше смотреть в сторону СППР или интеграции 1С:Документооборот с процессами разработки.