💡 Дисклеймер:
Это не стандарт, не методичка и не "истина в последней инстанции". Это мой личный ТОП косяков в коде 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 часа ночи перед релизом.
Делитесь в комментариях своими примерами кода, от которого хочется закрыть модуль и пойти выпить рюмочку чая. Уверен, у каждого есть хотя бы один такой экспонат.
Если вам знакома эта боль - возможно, мои готовые решения помогут сэкономить вам время, нервы и ночные релизы:
Вступайте в нашу телеграмм-группу Инфостарт
