Делай как надо, а как не надо - не делай. Личный ТОП-10 ошибок в коде 1С, от которых дергаться глаз
Разработка - Рефакторинг и качество кода
💡 Дисклеймер:
Это не стандарт, не методичка и не "истина в последней инстанции". Это мой личный ТОП косяков в коде 1С, которые меня раздражают и чаще всего приводят к боли в сопровождении. Я составил его, основываясь на многолетнем опыте работы с реальными проектами, как от независимых разработчиков, так и от коллег из фирм-франчайзи 1С, да... там часто встречается подобный код.
Конечно, существует гораздо больше реальных и тяжёлых проблем, от блокировок до транзакций и запросов в цикле, но целью этой статьи не было составить полный каталог всех возможных ошибок. Я делюсь именно своим практическим опытом и тем, что чаще всего встречаю в реальных проектах.
Пятница, 17:55, открываешь чужой модуль (а иногда и свой, написанный много лет назад) и глаз начинает нервно подергиваться. Что это? Как так можно было написать?
В голове сразу проносится: "То ли начать разбираться в этом коде, то ли сразу закрыть и переписать все с нуля". Вариант уволить автора этого кода, мы пока рассматривать не будем - это уже крайняя мера, но в голове мысль такая сразу промелькнула )
Делюсь тем, как я НЕ пишу код сегодня, чтобы спустя время не хотелось оторвать себе руки. В основе личные правила и немного стандартов разработки 1С.
📝 1. Про личные дневники в коде
Видел в одном модуле… Человек, видимо, очень сильно переживал, когда писал.
Каждая его процедура была с предисловием:
// Сюда я вчера дописал до трёх ночи, вроде работает, но если сломается — я не виноват
// (Сергей, тут блин всё сложно!)
Процедура ЧтотоСделать()
КонецПроцедуры
Прикольно, конечно, читать, но через месяц, когда всё-таки сломается, искать причину в этих исповедях будет… скажем так, неэффективно. Код должен быть понятным, как инструкция в аэропорту.
Сообщение "Выход там" гораздо важнее, чем "Блин, я сегодня не выспался". Оставляйте комментарии о том, почему сделано именно так, а не о том, в каком настроении вы были.
🎭 2. Про языковой барьер
Я много раз видел смесь языков: Result = Новый Массив. Такое ощущение, что человек, который это написал, будто забыл, на каком языке думает и пишет.
Если уж пишем на 1С в России - давай писать по-русски, для международных проектов пишем на английском.
МассивРезультатов - звучит более корректно и глаз не режет, не правда ли?
🔎 3. Про НайтиПоНаименованию - костыльный костыль
Есть отдельная категория боли - это когда в коде встречаешь:
НайтиПоНаименованию("Название элемента справочника")
И вот тут уже не просто дергается глаз, он начинает жить своей жизнью. Потому что этот код ломается от:
- опечатки,
- переименования,
- и просто плохого настроения пользователя.
Это не код, это лотерея.
Да, НайтиПоКоду - чуть лучше. Код хотя бы стабильнее, чем наименование. Но это всё равно костыль: код могут поменять, скопировать базу, загрузить данные из другой системы и всё, привет.
Если нужна настройка, нормальный путь только один: не искать по строке, а хранить ссылку. Лучше всего завести новую константу или отдельный регистр сведений.
Например, сделать регистр РегистрКонстант с измерением ИмяКонстанты (Строка), и ресурсом Значение (ЛюбаяСсылка, Булево, Строка, Дата, Число).
Однако, как верно заметил коллега gybson в комментариях, более верным и контролируемым архитектурным решением будет использование Плана видов характеристик (ПВХ) с предопределёнными элементами. Так вы полностью исключите риск опечаток в именах настроек. В коде вы будете работать со ссылками на элементы ПВХ, а не со строками.
В итоге ваш код не ломается от переименований справочников или кодов и вообще исчезает целый класс "магических строк". Это не усложнение - это элементарная гигиена кода.
📁 4. Про жёстко прошитые пути к файлам - мина замедленного действия
Есть ещё одна категория кода, от которого хочется сразу закрыть модуль и пойти пить "чай":
ИмяФайла = "\\FileServer01\\Share\\Reports\\Отчет.xlsx"
На первый взгляд - работает. А потом:
- переименовали файловый сервер,
- поменяли шары в домене,
- изменили структуру папок или перенесли файлы,
- или просто сменили среду.
И всё. Программа больше не работает.
Это даже не лотерея - это мина замедленного действия, просто с отложенным взрывателем. Вопрос уже не "если", а "когда".
Любые пути к файлам должны быть вынесены в настройки или храниться в константах/регистре или определяться динамически.
Жёстко прошитый путь в коде - это не удобство, это технический долг с очень коротким сроком погашения.
🧬 5. Про дублирование процедур - когда копипаст становится архитектурой
Бывает, открываешь один объект, а там процедура. Открываешь второй, а там же самая процедура. Третий и снова она. Только с мелкими правками, комментариями от разных людей и разным уровнем отчаяния.
Почему так происходит? Да потому, что:
- проще скопировать, чем аккуратно вынести
- сейчас работает, потом разберёмся
- страшно трогать рабочий код
В итоге одна логика живёт в пяти местах. Нужно что-то поправить, правишь в одном, забываешь про остальные и получаешь загадочные баги "только в этом документе".
Повторяющийся код должен жить в общем модуле, в отдельной процедуре, которую вызывают все.
Копипаст - это не ускорение разработки. Это рассрочка на баги, проценты по которой платит уже не тот, кто копировал.
📏 6. Про строчки, которые не помещаются
Это вообще моя любимая история. Открываешь модуль, а там условие на всю ширину экрана плюс ещё надо долго вправо скроллить. Типа такого:
Если (Не Документ.Проведен И (Документ.Дата >= НачалоМесяца(ТекущаяДата()) И Документ.Контрагент.ИНН = "1234567890")) Тогда
Читаешь такое, читаешь и чувствуешь, как взгляд начинает метаться от начала строки к концу, а потом обратно в начало. Ты как будто бежишь стометровку, у которой финиш постоянно отодвигается. Ты уже начинаешь забывать, зачем вообще бежишь и куда. Если не видно конца строки без скролла - обязательно разбивать, так и дышать легче и понимать проще.
💀 7. Про код-призрак
Это, наверное, самое грустное. Открываешь модуль, а там наслоение истории и эпох, как археологический раскоп:
// Версия от 2015 (не удалять! Мария сказала может пригодиться)
// Процедура СтарыйРасчет()
// КонецПроцедуры
// Доработка от 2017 (работало не всегда)
// Процедура НовыйРасчет()
// КонецПроцедуры
// Текущая, вроде стабильная
Процедура РасчетПоПоследнимТребованиям()
КонецПроцедуры
Спрашиваю: "А зачем всё это?". "А вдруг понадобится или нужно будет откатиться". Но "вдруг" никогда не наступает, а читать и понимать код втрое дольше. Система контроля версий или хранилище конфигураций может хранить историю, правда? Храните историю там и не засоряйте настоящее.
🎪 8. Про области-матрёшки
Области, штука, конечно, полезная и по стандартам 1С обязательная. Но когда видишь:
#Область Основное
#Область Расчеты
#Область ВспомогательныеРасчеты
#Область ОченьВспомогательные
#КонецОбласти
#КонецОбласти
#КонецОбласти
#КонецОбласти
Понимаешь, что человек просто увлёкся, как ребёнок с новой игрушкой. Сворачивать и разворачивать их - это отдельный квест. Область должна упрощать жизнь, а не создавать лабиринт.
🩺 9. Про пробелы и табы
Признавайтесь, бывало такое: выравниваешь блок присваивания переменных пробелами, чтобы все знаки "равно" стояли строго друг под другом? Смотрится как произведение искусства. А потом передаете файл своему коллеге, а у него шрифт другой и всё поплыло. Неловко как-то получается.
Таб, он как волшебная кнопка. Нажал и получил идеальный отступ. У каждого он может выглядеть по-своему (2, 4, 8 пробелов), но структура остаётся.
Tab он и в Африке Tab.
🚨 10. Про отсутствие обработки ошибок - "авось не упадёт"
Есть особый вид оптимизма - это писать код так, будто ошибок в принципе не существует. Ни соединение не отвалится, ни данные не придут кривые, ни пользователь тыкнет "не туда".
А потом, в логах пусто, в интерфейсе "ничего не происходит" и тут начинается магия настоящих шаманов: "Странно, а у меня все работает...".
Делайте хотя бы минимальную обработку ошибок, например, внятное сообщение пользователю, логирование или хотя бы намёк, где искать причину.
🎻 Вместо заключения
Уже не помню, где я это слышал, но аналогия мне очень понравилась: "Пиши код так, будто его будет сопровождать кровожадный психопат, который знает, где ты живешь". Со временем начал понимать, этот психопатом часто оказывается тот же, кто написал этот модуль, через полгода-год, особенно в пятницу вечером, когда всё сломалось и ничего не работает.
Писать нужно так, чтобы будущий я (или коллега) не вздохнул тяжело, глядя в свой монитор, а тихо порадовался: "А вот тут аккуратно сделано и все понятно".
Можно годами изобретать свой велосипед, но зачем? Существуют же Система стандартов и методик разработки конфигураций 1С. Нужно просто почитать на досуге и сделать для себя выводы и стараться их придерживаться.
Конечно, если вы не планируете отправлять свое решение на сертификацию "1С:Совместимо", никто не придет к вам с проверкой вашего кода. Возможно, все будет работать и так, но соблюдение стандартов - это не бюрократия, а знак качества, порядок и уважения к себе и к своим коллегам.
P.S. Если в этом тексте узнали не только чужие, но и свои ошибки - welcome to the club.
Думаю, мы все здесь немного такие. Главное это замечать и становиться немного лучше.
Хотя бы ради себя будущего, который будет тебе благодарен в 3 часа ночи перед релизом.
Делитесь в комментариях своими примерами кода, от которого хочется закрыть модуль и пойти выпить рюмочку чая. Уверен, у каждого есть хотя бы один такой экспонат.
Если вам знакома эта боль - возможно, мои готовые решения помогут сэкономить вам время, нервы и ночные релизы:
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Нейросети Рефакторинг и качество кода Запросы Разработчик 1С 8.3 Абонемент ($m)
Нейросеть написала запрос или процедуру для вашей базы 1С, и непонятно, все ли имена в нём настоящие. Обработка компилирует текст без выполнения, сверяет его с метаданными этой базы и к каждой ошибке пишет настоящее имя, например ВНаличииОстаток вместо выдуманного КоличествоОстаток. Список ошибок с подсказками одной кнопкой копируется обратно в чат с моделью.
10 стартмани
02.11.2026 386 2 nedomolkov.ivan 3
Рефакторинг и качество кода Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Одна проверка в обработчике кнопки может выглядеть достаточной, пока ту же операцию не вызовут из другого места. На примере управляемой формы разберём, почему так происходит, как разместить проверку в общей серверной функции и чем отличается удобная проверка ввода от обязательного условия выполнения операции.
29.10.2026 399 YA_777378709 0
Рефакторинг и качество кода Разработчик Бесплатно (free)
Рассказываем, почему качественный код – это не техническая прихоть, а актив, который помогает бизнесу быстрее адаптироваться к изменениям и запускать новые фичи без бесконечного преодоления техдолга. Показываем, как объяснить бизнесу ценность рефакторинга через понятные признаки: замедление разработки, неточные оценки, страх перед legacy и хрупкость системы. Разбираем, почему неправильный рефакторинг может быть дороже его отсутствия, какие анти-паттерны ломают процесс и как не превратить улучшения в бесконечную переделку ради переделки. Объясняем, как сделать рефакторинг частью культуры команды: договориться с бизнесом, научить разработчиков видеть проблемные места, закрепить правила и поддерживать улучшения на уровне тимлидов, архитекторов и всей команды.
28.10.2026 509 Pavel791 0
Рефакторинг и качество кода HighLoad оптимизация Системный администратор Разработчик Стажер 1С 8.3 Абонемент ($m)
Если к HTTP-сервису 1С обращаются сразу несколько программ, сколько запросов в секунду он успеет обработать? Я опубликовала простой HTTP-сервис на нашей "подопытной" конфигурации «Нано-УТ» (файловая база, Apache, без прав администратора) и нагрузила его скриптом на Python. Ответ: около 15-16 запросов в секунду, сколько бы клиентов ни обращалось одновременно. Запросы ждут своей очереди, и при 32 клиентах ответ приходит через 2 секунды вместо 64 мс. Заодно разобрала скрипт из первого варианта статьи: он «проверял» сервер, который отвечал по одному, и считал ошибки вместе с успешными ответами. В архиве исправленный скрипт, учебный сервер, HTTP-сервис для 1С и инструкция по запуску.
1 стартмани
23.10.2026 544 Ninel_S 3
Рефакторинг и качество кода Разработчик 1С 8.3 Абонемент ($m)
Запустили Analyzer 1C 2.7.65 на промышленной конфигурации (596 модулей, 13 669 функций) и исследовали перегруженные функции (до 1887 строк), циклические зависимости и экран «Циклы» (кольцо из 64 модулей). Разобрали, почему популярные метрики (McCabe, связность) не представлены в продукте вендора, и составили пошаговый план разделения модуля. Привели проверенный платформой 8.3.27 пример до и после рефакторинга и выявили скрытую ловушку загрузки модулей с точкой в имени.
9 стартмани
19.10.2026 482 Ninel_S 2
Рефакторинг и качество кода EDT СКД Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Одиннадцать граблей схем компоновки, которые не видно в конструкторе и не ловит EDT, на реальных отчетах БП КОРП. Формат числа задается в двух местах, и условное оформление варианта перебивает формат поля. Ресурс складывает штуки с часами, и помогает выражение «только когда единица одна». Ресурс пуст в детальных записях, параметр не появляется в шапке без userSettingID, valueListAllowed ломает границы периода, Остатки и СрезПоследних с параметром периода падают с «Несоответствием типов», title без xsi:type дает «Исключение XDTO» при загрузке. В конце код проверки схемы из файла до обновления базы, сводная таблица и чеклист.
16.10.2026 560 Konstmax13 2
Инструментарий разработчика Нейросети Рефакторинг и качество кода EDT Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Как ИИ-агент (Claude Code) работает в живом EDT-проекте 1С:Бухгалтерии КОРП 3.0: из чего собрать стенд с MCP-сервером для EDT, как ставить задачи агенту, где он ломает проект и какие проверки это ловят. Реальные случаи: рукописные метаданные, ронявшие конфигуратор; четыре дня зависшего обновления из-за порядка блоков в Rights.rights; ошибки, которые EDT пропускает, а платформа нет; сплошная сверка вместо «вроде работает». В приложении шаблон CLAUDE.md, шаблон правила, чеклист перед обновлением базы и скрипты проверки ролей и схем СКД.
15.10.2026 3568 Konstmax13 11
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Инженерный анализ влияния (Impact Analysis) при изменении общего метода в 1С:Предприятии: почему штатный поиск ссылок скрывает 99% зависимостей и как обратный обход графа вызовов выявляет 370 скрытых потребителей на глубине 3 уровней. В статье — верификация сквозной цепочки обмена с маркетплейсом; в архиве-компаньоне — автономный BFS-анализатор на Python, слепки графа и план регрессионного тестирования.
1 стартмани
12.10.2026 343 Ninel_S 0
и ошибайтесь уже в этом имени =)))))
Сделайте лучше ПВХ с предопределенными значениями. Их правильное написание проконтролирует система.
Коллега, спасибо за важное и очень конструктивное замечание!
Для стабильного, известного на этапе разработки набора параметров использование ПВХ с предопределёнными элементами является каноничным и самым корректным решением. Это даёт типизацию и контроль ошибок на уровне метаданных, чего не хватает простому регистру с полем-строкой.
Мой пример с универсальным регистром, это скорее паттерн для иного сценария, когда нужна гибкость добавления настроек пользователем в режиме Предприятия.
Я добавил ваш вариант с ПВХ в статью как предпочтительное архитектурное решение.
Теперь у читателей будет полная картина: строгая типизация для системных настроек и гибкость для пользовательских параметров. Главная цель, это уйти от НайтиПоНаименованию() достигается обоими путями, но ваш путь более правильный и надёжный.
И даже если вы привяжете регистр к справочнику, то как это избавит от необузданных желаний?
Можно хоть в текстовый файл записать, суть не изменится. Речь не идет о чем-то типа регистра курсов валют. Такие регистры разрабатываются под задачу и их десятки. Классификаторы и прочее. Это не задача. Задача связать код и данные так, чтобы эту связь нельзя было легко порвать из режима клиента. Чтобы не писать в инструкции "Создать запись с именем Чебурашка", потому что напишут "ЧИбурашка" и все свалится. А чтобы такого не произошло, надо написать обработку, которая создаст константу и в ней не ошибиться. И одна сплошная головная боль.
Работа заканчивается на эксплуатации. Не раньше.
Давайте еще раз, на примерах тогда.
1) Чтобы создать настройку "Таймаут соединения" вы можете:
// Создать элемент ПВХ с именем "ТаймаутСоединения", типа "Число". Обращение:
Таймаут = ПланыВидовХарактеристик.НастройкиПрограммы.ТаймаутСоединения.Значение;
// Или же создать константу "ТаймаутСоединения" с типом "Число". Обращение:
Таймаут = Константы.ТаймаутСоединения.Получить()2) Идем дальше. Чтобы создать настройки для контрагента и договора по умолчанию, которые всегда используются совместно:
// Создать два элемента ПВХ. Обращение:
Контрагент = ПланыВидовХарактеристик.НастройкиПрограммы.Контрагент.Значение;
Договор = ПланыВидовХарактеристик.НастройкиПрограммы.Договор.Значение;
// Или же создать регистр без измерений для хранения этой пары в ресурсах:
Настройки = РегистрСведений.КлиентПоУмолчанию.Получить();
Контрагент = Настройки.Контрагент;
Договор = Настройки.Договор;Опишу тезисно. Создаете ПВХ "Костыли". Создаете РС "ЗначенияКостылей" где измерение это необходимые разрезы аналитики по костылям (организации, подразделения, склады и т.п.) и сама характеристика, а в реквизитах указываете характеристику соответствующую ПВХ. Далее в ПВХ создаем предопределенный элемент "Костыль1" и используем его в коде "КостылиПовтИсп.ПолучитьЗначение(ПланыВидовХарактеристик.Костыли.Костыль1))"
Добавляем в регистр значение и вуаля.
Четверть века уже так делают, стандартная практика.
Нравится вам хранить данные в ПВХ, ну ладно. Я вам могу рассказать как еще можно извратиться и это в типовых есть - РС с одной записью, где каждый реквизит это вот такая настройка-константа. Тоже вариант и вообще без ПВХ.
А если всего этого не делать, то в чем прикол такой полуработы?
1. Запрос также надо писать, и он будет сложнее, т.к. будут дополнительные отборы на саму настройку. И тут более свободное поле для ошибок: установи отбор на элемент ПВХ не там, и отсутствие записи в регистре значений приведет к исключению записей в основной выборке. Такое я уже пару раз наблюдал.
Более того, запрос к спец. регистру можно и не писать вовсе в некоторых ситуациях. Код я привел выше: он простой, он гарантированно возвращает значение, даже если записей в регистре нет.
2. Проектирование регистра не сложнее, чем добавить настройку. Просто вместо предопределенного добавляете ресурс регистра или константу с тем же именем. Все.
3. Тестировать нужно все. И настройку в ПВХ, и константу/регистр. Не понимаю, почему здесь может быть какая-то разница.
4. С правами да, засада: часто разработчики забывают добавить роли для просмотра/изменения новых объектов, т.к. разработку ведут сами под полными правами. С другой стороны, перед универсальным ПВХ порой встает вопрос: а как разделить правами настройки? Чтобы в одной группе редактировали настройки одни пользователи, в другой группе - другие. С отдельными константами/регистрами эта задача тривиальная, с ПВХ - нет.
5. С интерфейсом двоякая ситуация. Если специальный не нужен, ПВХ здесь выигрывает простотой. Если мы хотим выдать отдельным пользователям некоторый набор настроек для редактирования, а другие настройки спрятать, если хотим настроить параметры выбора, связи параметров выбора между настройками и прочее - однозначно с константой/регистром проще, чем с универсальным ПВХ.
А потом ревьюете код где-нибудь в Gitlab, и вся структура кода опять развалена. :) Ну кажется удивительным, что у кого-то в IDE используется не моноширный шрифт в редакторе кода.
Вроде как в стандартах есть такое:
"При следовании друг за другом нескольких однотипных операторов допускается их выравнивание. Выравнивание следует выполнять с помощью пробелов"
Раньше выравнивал табами, но когда прочитал это, то стал выравнивать пробелами. Оказалось гораздо быстрее и проще.
И да, почему у коллеги не моноширинный шрифт? )
Автор, стоило бы проверить примеры за ИИ.
"МассивРезультатов - звучит более корректно и глаз не режет, не правда ли? " — еще как режет, это венгерская нотация, которая в современных конфигурациях не рекомендуется (.
Также смущает выбор ошибок стандартов этого топа. Это действительно ваш топ или то, что предложила нейросеть?
Ничего нет про когнитивную сложность, запросы в цикле, транзакции и блокировки — а это более серьезные проблемы, чем то, что вы описали.
Для изучения настоящих стандартов:
— практический подход
— официальные стандарты 1С
Коллега, спасибо за ссылки! Ссылаться на документацию, это почти всегда признак хорошего тона.
Отвечу по порядку:
1. Про "руку ИИ".
Если мой стиль кажется вам слишком структурированным, приму это за комплимент, но спешу расстроить, нейросети пока не обладают такой "профессиональной деформацией" (которая накопилась у меня за 25 лет), чтобы составлять личные хит-парады боли 1С-ника.
Кстати, забавно, что вы обвиняете меня в "машинном стиле", хотя сами используете в комментарии идеальные типографские длинные тире. Чтобы ставить их вручную, а не просто дефис, нужно обладать либо очень специфической привычкой, либо... отличным промптом. )))
2. Про мой ТОП
Это именно мой личный хит-парад "боли". Запросы в циклах и блокировки, это называется профнепригодность, ну или временный костыль, тут главное чтобы он был именно временный.
3. Про МассивРезультатов
Да, это отголоски венгерки, но в реальных проектах такая явная типизация часто спасает больше нервов, чем слепое следование рекомендациям.
Но опять же это мое мнение, ни кого не учу и ни кому не навязываю.
1. У меня большая насмотренность на различные ИИ, так что "торчащие уши" сильно бросаются в глаза. Понятно, что это дело привычки, но пока у меня это вызывает чувство "зловещей долины". И я не против использования ИИ в качестве помощника, я сам регулярно им пользуюсь, но конкретно такой стиль изложения не по мне.
"—" длинные тире на самом деле легко настраиваются небольшим скриптом в AutoHotkey (":*:--::—"), кстати решение использовать их было также рождено в горячих спорах с ИИ, оказывается так правильнее.
2. Большинство этих и других ошибок решается проверкой через АПК и SonarQube, особенно в больших проектах. Даже если не исправлять прошлый код, то строгое соблюдение стандартов в текущем коде со временем дисциплинирует разработчиков.
Ну а если интересует анализ что именно в тексте "не так", то вот он:
Claude Sonnet 4.5
Проанализировав текст статьи и комментарии, я могу с высокой долей вероятности сказать, что это текст-«киборг». Это классический пример человеческой идеи (и боли), «причесанной» или развернутой нейросетью, а затем снова отредактированной человеком.
Вот подробный разбор на «ИИ-уши» и человеческие факторы:
🤖 Признаки ИИ (Генерация текста) — 60-70%
Структура и Заголовки с эмодзи:
Стиль заголовков 📝 1. ..., 🎭 2. ..., 🧬 5. ... — это «визитная карточка» ChatGPT/Claude, когда их просят «оформить красиво для блога». Человек редко сам подбирает тематические эмодзи к каждому пункту (например, ДНК для дублирования кода).
Сама структура «Вступление -> 10 пунктов -> Заключение» — стандартный шаблон генерации.
«Водянистые» метафоры и клише:
Фразы вроде «Это не усложнение — это элементарная гигиена кода», «Это мина замедленного действия», «технический долг с очень коротким сроком погашения» — это любимые обороты LLM, обученных на технической публицистике. Они звучат правильно, но слишком «литературно-стерильно» для обычного разговора программистов.
Примитивизация примеров:
Пример с Если (Не Документ.Проведен И ...) — это классический синтетический пример из учебника. В жизни «строчки, которые не помещаются», выглядят куда страшнее и запутаннее.
Странная аргументация (галлюцинация логики):
Пункт про Tab: «Tab он и в Африке Tab. Нажал и получил идеальный отступ». Это очень поверхностное суждение. ИИ часто игнорирует холивар «табы против пробелов» (где главный аргумент за пробелы — одинаковое отображение везде) и выдает самое простое объяснение: «это просто кнопка».
👤 Признаки Человека (Авторский вклад) — 30-40%
Грамматические и стилистические ошибки:
«Открываешь код и глаз начинает дёргается» (вместо «дёргаться»). Нейросети пишут грамматически идеально. Такая ошибка характерна для живой речи.
«Вариант уволить автора... мы пока рассматривать не будем» — специфический юмор, который ИИ генерирует редко (или генерирует более топорно).
«Староверские» привычки (которые ИИ обычно не советует):
Венгерская нотация: Автор топит за МассивРезультатов. Современные стандарты 1С и, следовательно, ИИ (который на них учился), обычно рекомендуют писать Результат (если тип очевиден) или избегать типа в имени. Настаивание на префиксах типа — это маркер человека, привыкшего к старым школам программирования (или C++/Delphi бэкграунду). Комментатор AndRoman.pro справедливо заметил это несоответствие.
Специфический контекст (Боли 1С-ника):
История про «Мария сказала может пригодиться» — это слишком жиза. ИИ мог бы написать абстрактно «коллега просил оставить», но имя и конкретная ситуация выдают личный опыт автора.
Агрессивный маркетинг (SEO):
Вставка ссылок на свои платные продукты в конце («Маркировка в древней УТ», «Дубликатор кодов») — это точно делал человек. ИИ не умеет так нативно вплетать контекстную рекламу своих обработок без прямого промпта.
Вердикт по коду (сниппетам)
Код в статье слишком примитивен, чтобы судить о его авторстве. Это просто однострочники.
НайтиПоНаименованию — стандарт.
ИмяФайла = "\\FileServer01..." — стандарт.
Однако, совет использовать РегистрКонстант вместо ПВХ (в тексте) или вместо типовых Констант — это спорное архитектурное решение. ИИ (например, GPT-4) чаще предлагает использовать именно ПВХ (ПланиВидовХарактеристик) для хранения типизированных настроек, так как это «best practice». То, что автор изначально предложил свой «велосипед» (регистр с ресурсом ЛюбаяСсылка), а потом добавил upd про ПВХ после комментария — говорит о том, что писал человек, опираясь на свой (возможно, устаревший) опыт.
Итог
Статья написана по методу «Сэндвич»:
Человек накидал тезисы (боли): «бесят комменты-дневники», «бесит НайтиПоНаименованию», «бесят длинные строки».
ИИ (ChatGPT/Claude) развернул эти тезисы в красивые абзацы, добавил эмодзи, структуру и «воду» про гигиену кода.
Человек вычитал, добавил пару «живых» шуток (про Марию и пятницу), вставил свои ссылки и опубликовал.
Оценка: 70% текста сгенерировано ИИ на основе промпта автора, 30% (смысл, ошибки, реклама) — от человека.
Коллега, вы сегодня сделали мой воскресный вечер!
Интересно, что в споре об аутентичности и "живом" тексте вы делегировали написать свой ответ нейросети. Получается, чтобы доказать мою "нечеловечность", вам пришлось нажать кнопку "Отправить" запрос нейросети.
Комично. )))
Насчет вашего предложения проанализировать "что в тексте не так", спасибо, мне не интересно разбирать очередную "простыню" от Клода на тему моего опыта, для меня это просто пустая трата времени.
Скажу коротко для остальных читателей, вдруг кто-то будет читать наш диалог:
Про 25 лет стажа - правда. Поэтому и "староверские" привычки и венгерка и умение структурировать свои мысли. Просто раньше это называли "хорошим образованием", а теперь "признаком LLM".
Эмодзи и структура? Я ценю время людей, длинные тексты без акцентов в 2026 году уже никто не читает, кроме нейросетей.
Про AutoHotkey и тире, спасибо, что подтвердили мою догадку про специфическую привычку использовать промпт )))
На этом дискуссию предлагаю закончить.
Ценю вашу лаконичность в комментарии - жаль, что в своих статьях вы ей не всегда следуете. От Торг-12 до игр путь большой, а вот от "раскатал" до содержательного обсуждения, видимо, еще длиннее.
В следующий раз, когда захотите поддержать кого-то, попробуйте написать аргументированный текст, а не просто междометие.
А этот комментарий пусть останется вашей маленькой слабостью.
Коллега, вы невнимательны. Я говорю о вашем комментарии к статье. Ни внешность, ни возраст, ни характер я не трогал, я только указал на недостаток ваших аргументов. Где здесь переход на личности? А я подскажу, переход на личности начинается именно там, где аргументы заканчиваются, а у меня они пока есть.
И кстати, кто тут "плачется"? Я веду дискуссию со всеми, как автор, если для вас аргументированный ответ, это "плач", тогда, мы просто говорим с вами на разных языках.
Если хотите обсудить статьи милости прошу, если нет оставим эту игру в "сам такой" тем, кому нечего сказать по делу.
Такое название сообщает разработчику читающему этот код, что использование данной переменной имеет локальное использование, буквально в пределах одного-двух абзацев.
Я про другое писал: в книге Роберта Мартина "Чистый код" Глава 2: Содержательные имена.
Автор пишет: однобуквенные или слишком общие имена допустимы только для локальных переменных в коротких методах. Длина имени должна соответствовать его области видимости — чем локальнее переменная, тем короче имя может быть."
Когда же бесполезное нагромождение областей - конечно плохо, как и любой неаккуратный код.
Остальные пункты - однозначно поддерживаю.
С учётом взаимной "взрослости" могу перейти на "Ты"?
Но ты меня раззадорил по одному вопросу, который я-то для себя давно решил. Надо текст набросать....
Коллега, спасибо за "минусу", тема отступов для вас, видимо вопрос принципа. Однако тут важно разделять два разных понятия: отступ (в начале строки) и выравнивание (внутри строки).
Отступы делаются табами, это стандарт 1С. Это вопрос уважения к коллегам: один любит отступ в 2 пробела, другой в 4, и таб позволяет каждому видеть код так, как ему удобно.
А чтобы "красота не ехала" при просмотре, выравнивание (например, знаков "=") делается уже пробелами.
Ну и конечно, база, это когда в разработке 1С используется моноширинный шрифт, где ширина любого символа, в том числе пробела всегда одинакова. Если соблюдать эти два правила, структура не поплывет ни в одном редакторе.
Раз уж вы так категоричны в своих оценках, было бы любопытно увидеть вашу "экспертную" статью. Критиковать чужой опыт "минусом", дело нехитрое, а вот поделиться своим мнением на широкую аудиторию, это уже совсем другое.
Жду вашу публикацию!
Какое-то не то оформление из серии я за чистоту кода, но точно не ошибки.
Согласен, технически платформа выполнит этот код без ошибок. Но давайте копнем чуть глубже:
1. НайтиПоНаименованию - это ошибка логики, так как в 1С наименование не уникально. Сегодня код работает, а завтра после создания дубля начинает "рандомно" выбирать объект или просто изменят наименование.
2. Хардкод путей в коде - это "ошибка", которая гарантированно сломает процесс при переезде на другой сервер или смене пользователя или структуры каталогов.
3. Дублирование процедур - это тоже "ошибка", из-за которой через месяц при обновлении логики исправят одно место и забудут про другое.
4. Отсутствие обработки ошибок - это "ошибка", которая оставит нас без логов и понимания, почему всё упало у клиента в 2 часа ночи.
Может по синтаксису это и "оформление", но с точки зрения архитектуры и надежности - это самые настоящие ОШИБКИ и реальные причины инцидентов в проде.
Типа:
- забыли включить блокировку регламентных заданий в копии базы
- поставили интерактивное удаление объекта в роли
- не поставили индексироваться ключевые реквизиты поиска в объекте или расположили измерения в регистре некорректно
- вытягивают реквизиты составного типа в запросе
- забыли поставить флаг составной тип у составного типа и потеряли типы в данных
- обновление релиза конфигурации сравнением объединением
- не индексируют временные таблицы или не добавляют индексы в таблицы значений
- не проверяют обязательность заполнения реквизитов
- не понимают разницу клиента и сервера и опции без контекста
- забыли поставить в общем модуле флаг внешнее соединение
- и т.д.
Интересный у вас переход сразу на "ты", но давайте вернемся к сути.
Детский сад, это когда такие ошибки кочуют из проекта в проект годами фирмами франчайзи, потому что их считают "неважными" или вообще за ошибки не считают.
А насчет того, что мне "предстоит узнать"... Честно улыбнуло. ))) За мои 25 лет в 1С я видел достаточно "взрослых" катастроф, которые начинались именно с таких вот "детских" привычек и "не ошибок" в коде.
Но я всегда открыт к новому опыту! Буду искренне рад почитать именно ваш список ТОП-ошибок из "высшей лиги", если это не секрет.
Уверен, сообществу Инфостарт будет полезно поучиться у эксперта с таким рейтингом.
Может поделитесь?
P.S. Вижу, вы оперативно расширили свой комментарий списком технических проблем. Это хорошая иллюстрация того, что мы говорим о разных, но одинаково важных вещах. Теперь дискуссия выглядит завершенной.
(31)
Для sapervodichka это похоже норма. Но стоило мне как-то на это указать, и он занес меня в черный список.
Sapervodichka, на Инфостарте принято уважительное обращение. И принято общаться на "вы" с незнакомыми вам лично людьми. Внутри организации - чаще на "ты" бывает, но не всегда и не везде.
У каждого второго администраторы "забыли включить блокировку регламентных заданий в копии базы" и интеграции пошли налево. Потом ты делаешь конечно там блокировку по имени базы для интеграций и инструкцию как копию разворачивать.
Ещё частая ошибка забывают использовать кратность валют, только курс. И когда Юань перешел выше 10 рублей, внезапно для многих кратность стала не 1. И сотни комментариев от спецов клиентов тут, какие долбоящеры программисты франчайзи и фрилансеры.
Конкретно ошибка с интеграцией решается сбросом настроек подключения при перемещении базы, например. Это самое простое и надежное как нож.
Если уж так утрировать, то взрослые ошибки это дети-наркоманы.
Мой топ будет тоже другой.
1. Указание в ТЗ технических деталей
2. Работа сразу над двумя ветками релиза, когда связанные изменения оказываются разодраны.
3. Скрытая передача параметров - когда результат возвращается в параметре вызова.
4. Магические структуры, когда не прописана процедура, которая возвращает структуру обязательную для всех.
5. Если без Иначе
6. Вложенные Если
7. Процедуры свыше 50 строк
8. Комментарии "Добавил строчку начало", "Добавил строчку конец", которых больше кода.
9. Модули по 1000 строк.
10. Рандомные точки останова при отладке фоновых заданий.
А "если без иначе" вполне себе вездесущая типовая вещь если код по некому флагу выполняется, а как ты хотел его ограничить если не через если? ))) ладно не отвечай, просто я обещал немного и тебе говна на вентилятор
А вот не использование общего модуля получения повторных значений из кеша при получении таких объектов, это довольно частая ошибка.
Даже предопределенные значения, например в плане счетов не спасают т.к. меняются, а поиск по коду работает стабильно.
"НайтиПоНаименованию" - абсолютно "студенческое", обывательское и примитивное решение. По-хорошему, такой метод вообще исключить бы из справочников. Отсутствие этого "костыля" хоть кого-то принудит к нормальному администрированию своей же НСИ. А пока в головах пользователей свято верование в то, что компьютер не только умеет читать, но ещё и интерпретировать прочитанное. И с точки зрения пользователя достаточно "накидать" в строку наименования комбинацию "фамилия имя отчество" в любом порядке, с точками или без них, с произвольным количеством пробелов в любой части строки и этого будет достаточно - "Компутер, он же умный! Я же смотрю и понимаю, он тоже должен понимать." И программисты радостно ведутся на эту фигню, пытаясь показать своё непревзойденное величие, пишут для пользователя удивительнейшие "эвристические анализаторы", позволяющие найти "Васю Иванова" из любых "Ивановых Вась".
С точки зрения построения качественной предсказуемой системы, опора на машинное чтение строковых (текстовых!) значений - убогое решение на уровне калымящего студента второго курса.
(41)
Какой-то сюр… Видимо, желание уколоть автора сильнее, чем логика и профессиональное достоинство.
Забавно наблюдать вашу "коалицию желающих" щёлкнуть меня по носу и поучить жизни.
Пока вы пытались сообща доказать мне, что мой ТОП, это "детский сад", вы умудрились публично разругаться между собой в этой же ветке.
Один высокомерно называет советы другого "позором" и "стыдом", а тот в ответ признаётся, что у него просто "нет возможности делать красиво" из-за конвейера в "тысячи баз".
Я вас прекрасно понимаю. Моя статья для вас, как соль на рану. То, что вы называете "бредом" и "детским садом", в мире крупных франчайзи действительно считается нормой. Так ведь? Сами же написали. Там важнее быстрее закрыть часы и сдать проект, а костыли и говнокод становятся просто рабочими инструментами. Поэтому вам так и неуютно читать про "детский сад", он просто мешает вашему конвейеру.
За 25 лет я часто видел, как именно из-за оправданий, в том числе и франчайзи в духе "нам некогда делать красиво" потом годами мучаются люди на поддержке. Для вас это "мелочи" и "обезьянья работа", а для меня уровень профессиональной ответственности. Пока вы спорите друг с другом, чей костыль "стыднее", я лишний раз убеждаюсь, у нас просто разные пути.
Судя по одобрению хамства в комментариях и этой внезапной внутренней грызне, с культурой общения у вас всё так же, как и с культурой кода.
Для "экспертов" с таким рейтингом как у вас это выглядит… очень специфично.
Жаль, только, что ваши клиенты не читают Инфостарт, особенно ваши комментарии. Думаю, многое бы прояснилось.
P.S. Было большое искушение отправить обоих в мой черный список за нарушение культуры общения и закончить этот диалог, но признаюсь, стало любопытно. Вы так увлечённо и качественно дискредитируете себя и свою профессиональную репутацию собственными же комментариями, что было бы досадно прерывать этот процесс.
Пожалуй, оставлю всё как есть для истории и в назидание молодым коллегам.
Но ты вызвал живое обсуждение, и прими это как плюс
Я же не писал, например, что у меня 22 года опыта с 1С и не тыкал этим в лицо в ответах.
Нормально общаемся, и ты нормально отвечаешь.
В заявках в друзья меня добавь что ли.
Нет ничего плохого в поиске по Наименованию("Товары"), Товары они всегда Товары.
Пункт 5 - так делают, потому что виновата сама 1с, которая всё затащила в конфу. Используйте внешний регламент с подключение общих внешних модулей и тогда общая функция сразу работает на нескольких базах одновременно.
Пункт 7 - полностью согласен,
Комментарии должны чо временем удаляться, для этого есть система сравнения версий
Пункт 8 - согласен, области это излишество, которое мешает смотреть код, комментарии должен быть всегда внутри функции в начале...
Надеюсь, что по итогам комментов этой статьи вы помирились, а не пошли друг другу бить морды.)))
P.S. В который раз убеждаюсь, что подобные разговоры (дискуссии) надо вести за кружечкой пенного под рыбку или холодного графинчика с шашлычком и картошечкой.
Всё мирно )))
Морды целы, клавиатуры тоже. Согласен, живые разговоры за пределами комментариев часто куда продуктивнее и приятнее. А если там еще и "кружечка пенного под рыбку или холодный графинчик с шашлычком и картошечкой"
то тут просто без вариантов )))
"Черт побери! Вы так вкусно рассказываете, что у меня аж слюнки потекли".
В нормальной организации существует регламент к доступу к справочникам и любое изменение наименования справочника должно быть обосновано и информация об изменениях поступает в отдел разработки.
Есть во всех конфигурациях регистр сведений "Штрихкоды" сгенерируйте для справочников штрихкоды и с помощью запроса всегда выберите из справочника искомый элемент. Самое главное штрихкоды не повторяются.
Коллега, не соглашусь
Запросы в цикле, это всё-таки скорее временный компромисс, а не нормальная архитектура. Да, локально они могут казаться проще, понятнее и быстрее в изменении, особенно когда задача небольшая. Но на реальных объёмах данных почти всегда всплывают классические проблемы: лишние обращения к базе, непредсказуемая производительность и эффект "вчера работало быстро, сегодня почему-то тормозит". Поэтому лично я рассматриваю такой подход только как временный костыль, который потом нужно обязательно убирать.
Важный момент, на практике быстрота решения не равна надёжности. Скорость иногда действительно критична, особенно когда процесс встал и нужно срочно восстановить работу. В таких случаях быстрый фикс оправдан. Но после этого всё равно нужен разбор полётов и нормальное архитектурное решение, иначе временное решение очень быстро становится постоянной проблемой.
По поводу регламентов и наименований, в идеальном мире да, изменения контролируются. Но практика показывает, что базы живут долго, проходят через разных людей, интеграции, загрузки данных и человеческий фактор никто не отменял. Поэтому опираться на строки (наименования), всё равно риск, даже при хорошем, отлаженном процессе, кроме того зачем привлекать ИТ туда где не нужно, зачем замыкать на ИТ не свойственные им процессы. Я не считаю, что эта хорошая практика, любой бизнес процесс должен быть выстроен без участия ИТ
Идея со штрихкодами конечно интересная, но по сути это всё тот же дополнительный идентификатор. Если уже вводить стабильную идентификацию, то обычно проще и прозрачнее работать со ссылками, предопределёнными элементами или ПВХ, тогда система сама гарантирует 100% целостность без дополнительных механизмов.
Ну прежде всего области удобны для работы в EDT, где по областям строится древовидная схема с возможностью перехода на место в модуле. Для себя взял за правило (чисто для удобства работы именно в конфигураторе) в строке с КонецОбласти оставлять в виде комментария имя области, например:
#Область ВспомогательныеПроцедурыИФункции
......
#КонецОбласти // ВспомогательныеПроцедурыИФункции
З.Ы. в целом не очень понятна претензия "Сворачивать и разворачивать их - это отдельный квест". Можно и не сворачивать, чтобы потом не разворачивать, как-будто их вообще и нет) Это в любом случае удобнее же, чем отделять куски кода комментариями типа
////////////////////////////////////////////////////////////////////////////////
// Общие процедуры и функции для работы с данными в базе.Ну тут, наверное, больше вопросы к логическому мышлению разработчика) В принципе глобально даже больше 2 уровней и не встречал на практике (корневая область для процедур и функций + области без вложений в самих процедурах/функциях). Иначе скорее всего есть смысл вынести кусок в отдельную процедуру. Но даже и без этого избыточную вложенность я бы не отнес к "ошибкам", как это обозначено в заголовке статьи. Это скорее "личный раздражитель/индивидуальная непереносимость")
Справочники.ВидНоменклатуры.ПолучитьСсылку(Новый УникальныйИдентификатор("aaaaaa99-9999-9999-9999-001559109999")) // Просто, дешево, навсегда и никаких новых костылей взамен старых
Рад, что вы узнали в этих ошибках учебник, видимо, именно по нему и учились многие авторы кода, который я потом сопровождаю. 😊
А если серьёзно, то возраст ошибки не отменяет её живучести. Вирус гепатита тоже открыли в прошлом веке, но он почему-то до сих пор встречается чаще, чем хотелось бы. Так и с НайтиПоНаименованию - вроде все знают, что так нельзя, а в каждом втором проекте он гордо красуется, особенно после франчайзи, причем некоторые из них потом приходят на Инфостарт комментировать статьи про ошибки с видом экспертов
P.S. А насчет "седобородости" - борода, она как стаж: если её правильно носить, она добавляет мудрости, а не закостенелости.
Рейтинг: 823
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 2595842
Создание 31.01.26 10:30
Обновление 31.01.26 10:30
Просмотры 5576
Загрузки 0
Рейтинг
6
Комментарии 89
Код открыт Да
Рубрики Рефакторинг и качество кода
Кому Разработчик
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)