Почему «обычный 1сник» не любит чистый код
Вот живёт себе «большой мир программирования». Формулирует всякие SOLIDы, выращивает Дейкстр и Кнутов, шпарит computer science не покладая голов. И новичков, приходящих в телеграмм с вопросом «Чуваки, хочу стать программистом, с чего начать?» по-отечески, с шутками и прибаутками, сразу отправляет в гит, алгоритмы, паттерны и читать Дядюшку Боба.
А рядом с этим розовым миром с понями и радугой, в отдельном закутке, за противотанковыми ежами и электрическими разрядами на колючей проволоке, на копьях с головами «этих ваших новаторов» гордо реют желто-красные знамена 1с.
Когда я захотел стать новатором, я не думал, что моя голова окажется на пике. И теперь, чтобы избежать этой участи, пришлось задуматься — а почему, собственно?
Почему тех, кто приходит из «большого мира» наперевес с фразами «вы чо, пацаны, так же проще и удобнее?!!», встречают в лучшем случае суровым молчанием,
а чаще — начинается открытое противостояние «деды так писали!», «в типовых код видел? Вот и пиши так же» и прочее в таком духе.
Так и родился этот маленький опус — в размышлениях о судьбах.
0. Демографическая яма
Когда я приходил в профессию (больше 20 лет назад), за клиентов приходилось конкурировать. А сейчас мне даже некому отдать всякое, которое я делал уже 100500 раз — нет в профессии вьюношей со взором горящим. Настолько нет, что сам вендор уже целого амбассадора выделил — разобраться, что же не так. Когда человек сам приходит в телеграмм с вопросами, он открыт всему миру, он хочет учиться. А когда вдруг ты приходишь к 1сникам, ты видишь серьезных людей, уже занятых делом. По 10 лет и больше, опытные — отвал башки, сертификатами увешаны, как ёлки. И ты такой «Хай, ребята! А вы неправильно программируете!» И они тебе «Ага, смешно. Ээ, ты не шутил? А ну стой иди сюда!». Ну и вот и поговорили.
1. Опыт поколений
Именно эти ребята, суровые и с сертификатами, и начинают учить тех немногих, кто всё-таки решил пойти в 1сники. Чему? Понятно чему. Тому, чему научились они сами. Откуда они научились? У таких же суровых, которые были давно. И у вендора. Типовой код для 1сника — это же как мама для утенка. 1 раз увидел — и всё. На всю жизнь. А там, в типовом коде — легаси и обратная совместимость. И вот тут-то и всплывают аргументы «процедура на 8 тысяч строк с 13 параметрами? А что не так? Идешь отладчиком, пыщ пыщ, всё понятно. Комментарии от прошлых комиттеров бледненькие, читать код не мешают. Тебе мешают? У ти какие мы неееежные. Мне вот твои 500 функций из одной строки мешают, как по ним отладчиком прыгать? В смысле зачем? А как по-другому-то? Иди, короче, не мешай работать».
2. Не смотрите наверх!
А еще 1с — это квинтэссенция NIH-синдрома.
«Всё, что надо — есть у нас. Сделано нами для тебя, зачем тебе остальной мир?»
«VCS? — У нас есть хоронилище!»
«ШПД — их есть у нас! Красивое, между прочим.»
«Что, нужен мессенджер? А вот на тебе систему взаимодействия.»
«Что ты хочешь? Отчеты? Вот же СКД».
«Бухгалтер принес excel-ку? Так мы ее платформенно и прочитаем.»
И 1сники не смотрят по сторонам. Те, кто отрывает взгляд от хм.. земли, сразу попадают на Инфостарт. И уже на таких глазастых остальные начинают смотреть, как на обезьянок. Чего-то лопочут на вражьем, прикольные такие. Руками машут, глаза горят, но ничего непонятно же. Пойду-ка я дальше ошибки в регламентированной отчетности исправлять.
3. Too busy to improve.
«Работы и так выше ушей, не успеваю делать, а этот со своими гитами лезет. Всё ему не так, руками машет, глаза горят, тьху. Я, если будет надо, папочку сделаю с датой — 5 сек и всё. А гит учить некогда, сроки же. Мы так 15 лет программируем, и вон бухгалтерша за меня замуж хочет даже. Нормально же всё, ну что за кипиш? Не хочу. И некогда мне».
И так далее и так далее и так далее...
255. Прогресс не остановить?
Ясно вижу 2х виноватых:
0. Большая и хмурая компания 1С. All for the money, ууу-уу. Но она меняется. БСП придумали, EDT замутили. По мне так он мертворожденный, но всё хлеб. Амбассадор опять же.
1. Природное сопротивление людей изменениям. Отрицание, гнев, торг, депрессия, принятие — это человеческая природа. Нужно признать, что ты не очень. И принудить себя вырабатывать эндорфины от изучения новых штук. А это далеко не каждый умеет и хочет. И в этом 1сники точно такие же, как все остальные. Даже у джавистов абстракции протекают, чего уж.
-1. Речь, Бульба! Речь!
Кхм..
И хотя мы сталкиваемся с трудностями сегодня и будем сталкиваться с ними завтра, у меня всё же есть мечта. Я мечтаю, что однажды все люди будут жить в соответствии с истинным смыслом принципа: «Мы считаем самоочевидным, что все программисты сотворены равными». Я мечтаю, что однажды на страницах гитхаба 1сники и шарписты смогут сидеть вместе в одном репо. Я мечтаю, что придёт день, когда люди разных языков будут судить друг о друге не по цвету их книжек, а в соответствии с отчетами сонара. И что еще при моей жизни условные RUSTовчане будут на полном серьезе поздравлять 1сников с днем программиста. Надежда есть. И ради этой мечты и надежды найдутся люди, которые продолжат продвигать принципы «большого мира программирования» в разработку 1с. Не боясь найти свою голову на острие копья.
ЗЫ. Статья написана 3.5 года назад, отлеживалась. Но решил таки выложить, развлечь вас.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
С 1998 года я писал код в 1С сам, руками, от первой строки до последней. В марте 2026 я рассказывал, как проект на пять месяцев ИИ воспроизвёл за час. Прошло полгода, и теперь я не пишу код совсем, я даже не проверяю его и при этом закрываю 30-40 задач в месяц. Это история о том, что осталось от программиста, когда из его работы ушёл код, почему у одних коллег этот переход получается за месяц, а у других не получается вообще и почему ИИ без опыта за плечами это умножение на ноль.
20.10.2026 6145 GarriSoft 385
О жизни 1C:Бухгалтерия Бесплатно (free)
Как я считаю стоимость своего часа, почему не извиняюсь за цену и что отвечаю на «дорого». Без теории — только то, что работает в разговоре с заказчиком.
11.09.2026 4539 qwerty1414 73
О жизни Россия Бесплатно (free)
Расскажу, как это было у меня. Собеседования я не умею проходить от слова совсем, особенно когда начинают задавать вопросы типа: • Что такое структура? • Что такое соответствие? • Чем соответствие отличается от структуры? • Как обратиться к общему модулю из формы документа? • Как надо обновлять доработанную конфигурацию?
28.07.2026 6227 chuevsf 176
О жизни Россия Бесплатно (free)
Моё личное мнение о перспективах ИИ в среде 1С.
23.06.2026 5382 1c-intelligence 114
30 лет в 1С, 51 год, жёсткие требования к формату работы. За 1.5 месяца нашёл работу, используя DeepSeek как персонального HR-ассистента. Один раз настроил, отправил три своих резюме - дальше просто скидывал вакансии в чат и наговаривал ощущения через микрофон. ИИ анализировал, отсеивал фейки, писал сопроводительные письма, готовил к собеседованиям и разбирал ошибки. Результат: 127 откликов, 2 оффера, выход на работу 1 июня с достойной зарплатой (гибрид, к сожалению, мы с ним не нашли)
20.05.2026 9406 GarriSoft 227
О жизни Россия Бесплатно (free)
В далеком 2007 году я услышал впервые слово «Инфостарт» от своих коллег по работе и нашел этот сайт в Интернете, а 29.06.2007г. успешно зарегистрировался на нем. В течение долгих лет я был «молчуном»: не выкладывал никаких наработок и не писал статей. Просто читал, время от времени, и получал на сайте информацию.
14.05.2026 6166 chuevsf 207
О жизни Россия Бесплатно (free)
Еще совсем недавно у программистов 1С было всё хорошо. Задачи на выполнение сыпались, как из рога изобилия. Счетчик времени зашкаливало от быстроты их выполнения. Чуть ли не каждый месяц был новый рекорд. Новые идеи генерировались бизнесом одна за другой. Но общее состояние экономики в России в 2026 году уже давали о себе знать, и группу компаний также стало лихорадить.
17.04.2026 12153 chuevsf 245
Личные заметки о том, как 1С-разработка столкнулась с вызовом времени. От FoxPro до "гаражной инженерии" - тридцать лет по одним и тем же граблям.
02.04.2026 13083 GarriSoft 280
Но проблема в том, что сейчас те самые "Деды" которые отладчиком 13000 кода смотрели, сидят руками отдела, тимлидами и тд...
И вот у них есть четкая позиция "бизнесу это не надо"
Я прихожу в 9 из 10 контор, там сервера на винде, и они хотят тестов, ci и автоматизации, но учить линукс - не хотят... и говорят, что они "для экономии времени, из за того что нет экспертизы" - будут все делать на винде.
И сразу выкидывают в помойку такую прорву времени, на пердолинг с кодировками, конфигами, клинапом, конкаренси и тд, которые могли бы просто решиться переездом в какие-нибудь контейнеры, или хотя бы на линуксовые виртуалки...
Но они по прежнему "экономят"... ну чтож... пусть экономят )
Кто этот человек и в чем его деятельность заключается?) Не смог в интернете найти публичной инфы про это, но очень интересно
С разработкой то же самое. Есть 80% банальных задач, есть 20% более творческих. Для 80% задач хватает и тех самых 80% обычных программистов с улицы. Но, как показывает практика, даже в рядовом ларьке появляются задачи из оставшихся 20%. И тут начинается печаль.
а что касается - закрытия комментариев - надоело читать всякие догадки и выводы от всяких "специалистов". один пишет не в тему, другие ему поддакивают)))
Гит - штука хорошая, но и у него есть моментики, когда приходится разбираться с конфликтиками. И это не так-то просто. Какой-то архитектор 1С-ный писал, что с конфликтами разбирается половину рабочего времени. Нафига? Да и зачем двум разрабам из небольшого отдела нужно копаться в одном и том же объекте вдвоем? А если не нужно вдвоем, то и храна хватает. Хочешь гит? Вот тебе гитсинк. Смысл в гите если только в интеграции с сонаром, а разворачивать на прод инкремент в автомате - это отдельный такой суицидный синдром, его надо лечить.
Типовая пытается натянуть на себя SOLID, по крайней мере часть этих букв. Но нет там приличного кода, который бы оперировал провайдерами, как механизмами доступа к ресурсам или как трансформеров для данных. В итоге все эти стеки вызова на 20 строк - это всего лишь попытка изпражнить из себя вялую деятельность, разбивая когнитивную сложность на тысячи мелких функций. И если ситуаций, где это действительно оправдано, будет больше 10% - это уже достижение. В остальном это программирование ради программирования.
Приличные специалисты в действительности не часто так вот активно сопротивляются нововведениям, а вот неприличные обычно никогда не сопротивляются - они прожуют все, что им в рот затолкают. И если тот же сонар помогает привести код в порядок, то он же помогает привести его в сущий хаос, если заставить неприличных выполнять все то, что он там пишет. В итоге одна связанная функция, оперирующая алгоритмом чуть сложнее, чем дважды два, начинает превращаться в десяток вызовов, теряя связанность. И если бы связанность в данном случае была не в одной функции, которую начинают дербанить на части, а в разных объектах, реализующих общий интерфейс, то все было бы неплохо, но когда это одна функция, рассчитывающая что-то сложное, то все эти попытки угодить сонару с целью упростить код, превращаются в усложнение этого кода за счет множества вызовов, которые в 1С очень даже не бесплатны. Вызов в цикле - это такой запрос в цикле, только дешевле. Но стоимость вызова в 1С существенна, и почему-то на это мало кто обращает внимание.
Только вот кофигуратор усложняет гит настолько, что хранилище все равно остаётся выгодней. Edt буксует и просвета не видно.
Если у тебя небольшой проект с тремя разрабами, то я сомневаюсь в том, что гитсинк с храна неспособен заменить связку ЕДТ + гит, в котором до сих пор разрабатывать - такое себе.
Так что и с гитом, и с проверкой, и с храном. Не вижу никаких проблем. Я сам пользуюсь и ЕДТ, и конфигуратором, и мне до сих пор в конфигураторе удобнее. И вроде бы кажется, что ответ на "и чего тебе еще, собака, надо" прост, но он постоянно ускользает от меня, стоит на нем сосредоточиться. ЕДТ заметно подтормаживает там, где конфигуратор отзывается мгновенно. ЕДТ периодически заставляет грузить конфигурацию целиком, чистить проект, вываливая тонны нечитаемой галиматьи при попытке сохраниться, ... Я не мазохист, я не могу к этому привыкнуть. Но если мне нужно порезать строки до 120 символов и только, то я использую ЕДТ, чтобы потом отправить в гит порипаный код, но для большего это унылое поделие из нулевых не подходит. А, да, в нем еще прикольно описание к методам делать. Для С++ у меня есть вижуал студио, для андройда - андройд студио, для 1С же пока конфигуратор, по крайней мере для оперативной отладки и исследования кода тех мест, куда я еще не заходил.
Сейчас как эталон есть база ERP на полной поддержке с замком. Есть пара расширений с изменением структуры БД. Расширения в зранилищах.
Всегда из хранилищ накатываем изменения сразу в прод после того как протестировали код в базе раразработчика.
Стараемся не затягивать время чтобы раньше оставшихся блох выловить и исправить ошибки, так же это позволяет не конфликтовать разработчикам за одни и те же объекты в хранилище.
Как-то вся эта мутатень с гитами и едт, изначально казалась бесполезной тратой времент.
Собственно на этом можно заканчивать. Если нет единого тестового контура- значит простой не стоит вам ничего.
В целом- можно и хранилище не юзать, это так, для порядку...
Наша сложившаяся практика работы нас полностью устраивает и я не лезу в чужой монастырь с советами, а говорю как можно успешно работать в группах до 20-ти человек не накручивая и не усложняя процесс разработки
Прошлая работа была в фирме с 1500 сотрудников и чутка более большими оборотами, множество часовых поясов где были филиалы.
Центр учета там и там это 1С ERP + Интеграции с сайтами, СКУД, WMS, отдельные рабочие места в смартфонах и на стационарных ПК....
Еще ранее работал в фирме из 980 сотрудников, атомное машиностроение, ну там была своя назовем ее ERP на делфях написанная. 1С БП + ЗУП, я был тогда один программист, там не требовалось хранилищ и гитов. И та ERP разрабатывалась группой прогеров в репозитории мелкомягких, по сути что-то типа хранилища 1С. Что-то они там не ныли что им гита не хватает.
Тесты окупаются тогда- когда простой системы стоит дороже из разработки. То же самое с версионированием и разделением.
Если для вас допустимо угробить прод, и восстанавливать его из бэкапа с потерей данных за n-часов, то в целом- можно и без тестов, когда это стоит миллионы потерь, то сразу тестирование не выглядит бесполезной затеей
По вине платформы так основательно может падать прод, что порой бывало волосы рвешь и решение ищешь на адреналине, как типа в скуле очистить всю таблицу с данными конфигурации и быстро копируешь такую же из соседней тестовой базы лишь бы поднять прод, а разбираться потом. Бэкапы есть, время восстановления несравнимо больше и простои выше.
И вообще перестаньте считать деньги фирм, фига вы в карман к владельцам лезете!!! Похожий ответ мне был когда-то дан, когда надо было на ERP 2.5.7 переходить, где ожидаемы простой базы 2 дня получался!!!!
Нам же сильно далеко до вас!
Назовем это величавым словом "Проекты", стараемся декомпозировать и делать частями и сразу в прод, тем самым минимизируем время захвата объектов и корня конфигурации. Ускоряем внедрение функционала, так же не плохо и на хомячках отладку провести чтобы сразу наныли что им там не ьак кажется и это сразу учесть, чтобы потом все не переделывать.
Яж надеюсь вы когда хотите создать отчет вы ради него не держете корень годами? Создали болванку и освободили корень?
У нас этих болванок отчетов и обработок десятками создано на перед и это тоже своего рода решение конфликтов захвата корня.
А еще можно общие модули плодить по областям учета, и варится в этих областях один два програмиста не бадаясь.
Ой да забыл, куда я с малым числом разработчиков лезу. У вас же их сотни!
И мне на малую группу разрабов нужно применить такие же трудозатратные методы момандной разработки и админить в одны рыло и стать не заменимым? Как уйду все рухнет. Не в моих правилах нагородить огородов и потом подставлять компании, когда я ухожу из них. Везде должна быть золотая середина.
Вы возможно ставили когда либо систему взаимодействия от 1С, там такой огород документации нужно перешерстить чтобы ее установить более менее адекватно. Уверен, что это подсилу 10% сообщества. И все ваши гиты из той же области. У меня в городе тупо специалистов по нему не найти. Накой ляд мне повышать порог вхождения там, где это не нужно?
А вот хранилище, мм, всё православненько, привычно мышкой тык тык галочки, изян.
а если у вас этих проблем нет (вас, напомню, все устраивает), то не похоже, что вы вообще занимаетесь групповой разработкой или даже индивидуальной с несколькими ветками.
я за адекватный симбиоз между сисадминами и программистами. Зашел на проект - говорю, я не смогу поднять скуэль, нашли сисадмина, который этим занимается, я решаю другого класса задачи, с которыми сисадмины не справятся.
То же самое с линуксом - сисадмин на другом предприятии предупредил, что будет переходить на линукс. Ок, я поправил код в 1с, от чего-то отказались из-за отсутствия комОбъекта, и все. Сисадмин бы наделал ошибок, если бы полез в конфигуратор исправлять алгоритмы, которые "не под линукс"....
Каждому свое.
Сисадмины не любят двойную запись в бухучете, и не шарят в управленческом балансе. Почему-то никто не пишет статьи "почему 1сные сисадмины не любят бухучет"...
* Создание статической основы сайта – структуры (HTML) и внешнего вида (CSS), а также обеспечение корректного отображения на разных устройствах.
Фронтенд-разработчик:
* Добавление интерактивности, динамических элементов и всей клиентской логики сайта, что требует навыков программирования.
Но ни тот, ни другой не занимаются дизайном - они воплощают этот дизайн в странице. Это как архитектор, который ваяет, и инженеры ПГС, которые в душе матерят архитектора, привязывая его попытки самоутвердиться в кирпичи и металлокаркас.
Но даже в части алгоритмов, то я за все время может быть три раза эти алгоритмы использовал. И в бухучете я не копаюсь почти - для этого есть аналитики и сами бухгалтера, которые должны знать, какие операции у них там формируются и что в них не так.
Так что бухгалтерский учет не является для 1С-ника обязательным, если это не 1С-ник ларька, в котором он один на всю планету. Если он выживет, то будет у него сто ларьков, в которых он по часу в месяц будет обновлять бухню. Но и в этом случае вряд ли он станет понимать, как, например, разделить бизнес, если бизнес достиг своего порога на УСН (реальный случай - ни бухгалтер в ларьке этого не знал, ни тот, у кого 100 ларьков, куча сертификатов 1С и высшее экономическое образование, хотя вроде бы что тут знать).
А SOLID - это методология разработки в ООП. Она позволяет создавать сложность постепенно, заворачивая ее в отдельные слои абстракции, определяя, как должны себя вести объекты, их коллекции, как они взаимодействуют друг с другом.
Вообще, разработка ПО сейчас достигла стадии зрелости приличной девелоперской компании, которая организует строительство большого здания. В нем есть фундамент, этажи, отделка, фасад, коммуникации, ... Появились стандарты с нормативами, постепенно разработка становится инженерной задачей, а не творческим изысканием. И это хорошо.
SOLID - это не методология, это набор принципов, призванных бороться со сложностью, привнесенной в мир программирования парадигмой ООП. Особенно это очевидно по букве L :). А методология - это набор методов и методик. Использование SOLID в 1С выглядит очень странно. 1С не поддерживает в должной мере ООП, у 1С должен быть свой набор принципов, где-то, может быть, похожий на SOLID, но им не являющийся. Кстати, SOLID уже не модно, в моду входит GRASP. Но с ним такие же проблемы:)
Но я говорил не о том, что SOLID или что-то еще. Я говорил о том, что амбассадоры обычно в этом неплохо разбираются, раз эти принципы отстаивают. Ну или они находятся на уровне догм, когда правила уже перестали быть мифами, т.к. сформированы в документ, но еще не были отрефлексированы через критическом мышление. Так, обычно, развивается религия, многие адепты которой библии не читали, но им уже рассказали, как правильно.
Отсюда мораль: библии надо для начала прочитать, отрефлексировать, попытаться понять, применить на практике, и после этого появляется право на мнение.
Полностью согласен. Могу добавить только "... или 3) мало работали по другим принципам, или 4) мы имеем дело с импринтингом (синдромом утенка)". Плохо то, что публицистика про эти "новые технологии" во многом основана на вере и на субъективном отношении автора к тем или иным аспектам технологии, а не на объективных критериях. Так если у Кнута какой-то алгоритм имеет временную сложность n*n, а другой n*log n - то это объективный критерий для сравнения. А если Мартин говорит, что вместо написания комментария к коду надо обернуть этот участок кода в функцию, то у меня большой вопрос к обоснованию этой необходимости.
Все циклично. Сначала был монолит, потом его начали раздербанивать на микросервисы. И этому была причина - выделение автономных команд для конкретного сервиса, которые бы занимались его поддержкой и развитием максимально эффективно, формируя контракты для других сервисов, для которых они поставляли данные, и применяя контракты тех сервисов, в данных из которых они нуждались. Дальше микросервисы сами стали монолитами - разраслись, и их развитие продолжалось или по пути включения в себя мелких одиноких микросервисов, или по пути разделения на меньшие микросервисы, выделения отдельных команд. Продукт начинал "дышать", можно сказать: "оживал".
Иногда менялась платформа и сервисы собирались в большой монолит, но даже в 1С продукты чаще дробятся, чем объединяются, чему свидетельством популяризация шин для организации интеграционных потоков. В больших проектах я, честно говоря, не видел, чтобы все было в ЕРП. Очень часто отдельная бухня, отдельная ЗУП, отдельная ЕРП, может быть это все потом соединяется в УХ. Но чтобы все было в одной корзине - не видел ни разу. Не удивлюсь, что есть кто-то, кто все-таки ценой неимоверных усилий загнал все в одну систему. Но я этого не понимаю.
- Цель статьи или какой вопрос поднимаете?
- Предметное описание
- Примеры
- Сравнения
- Собственное мнение
- Выводы
Статья хоть 10 лет пролежит на "полке", но это не вино, лучше не станет, если ее не дополнять и усиливать.
500 функций и процедур через команду "Выполнить" с асинхронными вызовами и оповещениями. Сука! Зачем асинхронность, где логичнее синхронность! Если команда выдать Х-отчет не работает, к лингаму асинхронность! Ждать 30 секунд - сказать не работает нафиг! Синхронно дай команду на 1 - 2 функции. Быстрее будет работать в +100500 раз. Пусть не так быстро как у конкурентов, но не 30 секунд или полторы минуты же на пробитие чека!
...и верно. Начинаешь искать в чём ошибка, почему маркировка не взлетает или ошибками сыплет. Пройдешь путь познания через 100+ процедур и функций с несколькими рекурсиями по разбору штрихкода, типу маркировки, запретами и разрешениями... кэши и хранилища из которого мы нет-нет да и что-то вытаскиваем нопонятно когда в них засунутое, мать их... ищем зачем-то наличие этой марки в МИЛЛИОНЕ-другом строк чеков с 2015 года ... Перезапускаешь этот скан в отладке 15 - 20 раз... Надеешься и веришь после такого что для "суровых и с сертификатами" в аду отдельный желтый котел с 2 красными символами предусмотрен.
"Исправьте печатную форму УПД" или "Нам надо по требованию маркетплейса добавить нестандартные поля в ЭДО в УПД чтобы в них значения попадали оттуда-то"... вообще тот еще квест. Кто делал - тот поймет.
Вот было бы забавно, если бы оказалось, что такой код написан специально, чтобы реализовать какой-то паттерн проектирования из числа описанных GoF, и авторы кода могут обосновать свое решение цитатами из книг Фаулера, Мартина и прочих публицистов. Надо понимать что "чистый код" это НЕ про скорость, это НЕ про лаконичность, и это даже НЕ про функциональность. Это про "чистоту" кода, отсутствие "запахов" кода, про чувство удовлетворения, когда смотришь на "чистый" код.
1. Полное понимание этого кода доступно только создателям этого кода
2. Универсальность обратно пропорциональна скорости работы и размеру конфигурации
3. Универсальность прямо пропорциональна количеству ошибок в коде
4. Пункты 1-3 затрудняют отладку кода и скорость работы программы
5. Пункт 4 сказывается на стоимости обслуживания и удорожании техники
6. Пункт 5 ведет к снижению конкурентоспособности
7. Исходя из п.6 видим как активно появляются и бурно развиваются конкуренты со своим кассовым ПО и товароучетными программами. (Эвотор, СБИС, Атол с сигмой, Семейство штриховых программ...)
Странно смотреть на старые программы, которые тоже писал 1С и в которых все просто. И отладка требует в 100 раз меньше времени. Например УТ10, КА, БП 2.0 и т.д написанные на базе этих конфигураций. Глаз отдыхает, когда видишь прозрачный код старых программ.
ЗЫ: "ты бы еще семерку вспомнил!.." - и да, помню. С неё и начинал.
Написано не для какой-то принципиальной галочки, что код чистый а автор умный. Написано так потому, что конфигурации с такой функциональностью по другому не напишешь. А если напишешь, будет очень больно добавлять новый функционал который взаимодействует с существующим.
Я тоже начинал с 7ки. Функциональность любой 77 и ЕРП из которой вытекают почти все текущие типовые конфигурации просто ставить в один ряд не имеет смысла.
Вам конечно виднее, какой процент кода покрыт тестами. И как разрабатывается. По моему субъективному ощущению, процент ошибок соразмерен, существующему функционалу.
Раньше было лучше(с) Вы как будто бы выпали из понимания как сейчас должно работать и немного злитесь не на себя, что не получается понять почему так сделано. А на тех кто сделал то, что у вас понять не получается. Чисто субъективная оценка разумеется.
Повторю, речь идёт о времени затрачиваемого на отладку. Все мы понимаем, что чем сложнее программа, тем сложнее ее понимание и ее отладка в поиске ошибок. Понимаем, что 1С идет по пути сделать основные конфигурации более универсальными, чтобы сделать их массовыми. Чтобы они легко интегрировались в любой бизнес. Однако это сильно нагружает конфигурацию и программный код. Библиотеки - это хорошо. Они обновляются, дополняются - тоже хорошо. Стыковка их после обновления - беда. Отсутствие своевременного описания или поддержки старого функционала для безболезненного перехода - так себе.
Другая альтернатива (понимаем, что речь не о ERP или КА) создавать небольшие профильные конфигурации для той или иной сферы бизнеса (не каждый же магазин или малая пекарня желает установить себе ERP и потратить на внедрение годовой бюджет города и 5 лет жизни (утрирую, конечно, но суть есть суть)). Вы скажете чем Вас не устроил УНФ или Розница (тоже УНФ)? А тем и не устроит, что для нормального функционирования УНФ требуется сервер и/или рабочие станции вполне себе недурные и недешёвые. Я не могу перевести клиентов с конкурентных продуктов на типовые 1Сы, т.к. придется менять весь парк машин и переделывать всю инфраструктуру. Это затратно для клиента и длительно по времени. Плюс постоянные ошибки. Сейчас решение - УТ11 + 1С Касса, НО почему-то не сообразили в 1С что нужно бы остатками обмениваться между этими программами. Опять нехорошо. Опять допиливать пробиваясь через хитросплетения универсального чистого кода и потери времени и уважения. Во! Запилил! Хоть на трибуну лезь с докладом!
Не было такого никогда! Всегда клиенты конкурировали за 1Сников!
Для хренового 1Сника - да, импринт на всю жизнь.Но из теоремы Тота есть исключения.
XDTO мертвее. Надеюсь, в Элемент его не потащат.
Хорошая статья. Вечная. 15 лет назад можно было бы сказать всё то же самое.
Я отдал программистам Jira свой АПИ с кириллицей. Прибежали, просят перевести на латиницу. Я им "А чо так?". Они "Не любит Жира кириллицу. Тяжко работать.". Сжалилися. Сделал им латиницу.
По клиентам - вкатуны и новички создают резонанс в рядах исполнителей, демпенгуя все что угодно …
А по поводу С++ и джавы - ну может быть, хотя там как раз с интерфейсами сейчас все хорошо - там или XML, или даже HTML+JS. Если же взять питон, то на нем уже другая скорость разработки. И не стоит забывать, что ИИ на этих языках гораздо лучше код пишет. Особенно на питоне. И скорость разработки, и скорость работы продукта и покрытие кода тестами - это не одно и то же. В 1С легко сделать что-то для верхнего уровня. Простую систему. Но когда сложность системы выходит за рамки простого, то наличие хорошего "фреймворка" для CRUD перестает быть преимуществом.
Порог вхождения в 1С вроде был когда-то не высок, чем и брал рынок, потом все усложнялось и усложнялось.
Домешивать к 1С еще и инородные механизмы, которые та по сути живут там по своим правилам, а в 1С свои правила.
Пытаться натянуть сову на глобус.
Повышать еще сильнее порог вхождения, пилить сотни батничков чтобы все между собой поженить...
На текущем месте работы, как только взяли, нужно было навести порядок как руководителю.
Начал вникать, что происходит, а там типа ведущий на тот момент прогер развернул гит и давай его навяливать всем, и как итог, он в него пытался пихать 40+ расширений и 300+ отчетов и обработок внешних.
Как негативный итог, гит не спасал от того, что разные люди взяли на редактирование один и тот же внешний отчет и по очереди его зайдя в рабочую базу заменяли в справочнике, один затирал изменения другого. С расширениями такая же канитель была.
В итоге, гит я похоронил, разработчик тот тонкой душевной организации сам свали (к счастью забрав с собой негативное настроение), оставшиеся разработчики сбросили с плеч этот гит, вернулись к разработке, а не попытке самоорганизоваться в гите.
За три месяца 40+ расширений слили в 2. (какой-то шиздец был искать что-то среди этих 40+ расширений, представляет сколько вкладочек открывалось?)
300+ внешних отчетов и обработок влили в эти два расширения.
Для каждого расширения свое хранилище естественно.
Колесо закрутилось, никаких инородных систем, все продуктивно работают с хранилищами, и не нужно вникать и знать как там работает гит.
Бизнес не простаивает, задачи выполняются.
Большего и не нужно.
Это как уравнения в третьем классе, где вместо X пустой квадратик и несколько правил про неизвестное слагаемое-вычитаемое, не до алгебры. Но и выхлоп простоват.
P.S. Чем гит не угодил именно в вашем случае остается загадочным. Как-будто это просто личный конфликт с ведущим.
Это мы, заполняя ЛУВР, гордо называем любимую платформу "1С", а прочие завистливо говорят "OdinAss".
Где-то есть белые господа, у них все слова умные и имена красивые "мартин" "джон" "давид".
А у нас всё не так, как у белых господ.
Поэтому не нужно разбираться что у нас, как у нас, просто надо срочно всем всё как у белых господ.
В этом и есть суть статьи: "не хочу как у нас, надо как у них".
Предлагаю методом "5 почему" разобраться, кому надо чтобы "как у них" и "чтобы что?".
Когда я читаю КоличесвоКлиентовПДоговоруОХ = КоличесвоКлиентовПДоговоруОХ + 1 - я уже понимаю о чем речь.
Ибо нефиг.1Сник пишет (упрощенно) код для других 1Сников ( в т.ч. и для себя самого +2 года). Потому что завтра хотелка НПА может поменяться с точностью туда-сюда. А обход графа как он был сейчас-10 лет - так он и остался сейчас.
И около птиц!
КоличесвоКлиентовПДоговоруОХ ++;2. Сокращает код.
3. Оптимизирует расход памяти.
4. Делает разработку праздником, а не унылыми буднями.
ЗЫ: дни 1С уже сочтены. Был у настоящих клиентов в регионе (а не у аналитиков, овнеров и прочих дармоедов, которые думают, что развивают продукт, но в действительности городят бюрократию). Они продают автозапчасти камазами направо и налево. И потребности у них больше в том, чтобы загрузить эксельку в веб-морду эмекса, в которой (веб-морде) они и приход делают, и расход, и приемку, и инвентаризацию, и... 1С у них сейчас больше этикетки для ПВЗ озоновского/вайлдберисовского напечатать, да и с этим у 1С трудности какие-то, ибо по какой-то причине современная 1С в обычных формах никак не хочет применять масштаб, при том по ширине страницы работает. Так вот, у них там запросы больше о загрузке экселек из почты, засовывания их в вебку. И да, 1С это может, но спецов в регионах, о ужас, нет почти. И я им показал дипсик. За полчаса дипсик на питоне нарисовал эту загрузку и скармливание сайту. Да-да. На 1С-ах местные тунеядцы делали это месяц и не сделали.
ЗЫЗЫ: И да, на 1С-ах это кто-то крутой сделает за пару дней. Может, если поднатужится, то и за день, но 6 часов на такую задачу ни один овнер не акцептует - че-та больно мало, а вдруг не успеем, а вдруг потом тестеры найдут баги и на доделку... Аджайл в 1С как раз помогает это все забюрократизировать донельзя. В итоге код после отработки сонара становится красивым, но ни у кого не будет времени это оценить после того, как задачу закроют. Про оптимизацию умолчим - это сонар не умеет от слова совсем.
Ну как бы просто они так привыкли. Когда нужен учет ГТД/серий, возможности ЭДО, маркировка товаров, интеграция с разными Битриксами, MindBox'ами, внешними WMS, ЗУПом, нужна отправка рег.отчетности, анализ себестоимости и валовой прибыли, рассылки отчетов и т.д. - тут никакой DeepSeek с Python'ом и Excel уже не помогут) Вот как выйдет маркировка автозапчастей из "пилота" - вот тогда такие потом и побегут со своими табличками за 1С. Уже сколько таких было - не счесть)
"Чистый код" - это вообще жупел от тех, кто "не смог".
Код бывает грамотный, неграмотный, грамотный здесь и сейчас, но перестающий быть таким вследствие изменения программного окружения.
Может быть приятно оформленным, а может быть куском чего-то нелицеприятного, который сначала навалили, а потом сели сверху всей своей тушей.
А чистый - это как? Постиранный в стиральной машинке?
Впрочем, если мне скажут, что "обычный 1сник" - это тот, кто считает, что существует "чистый код", и он его не любит, потому что никогда его не видел, потому что не понимает, что это такое, то, пожалуй, я останусь удовлетворён ответом.
Даже не касаясь архитектуры, языка и технологий - может потрясти внутрикорпоративная культура, позволяющая выпускать в типовых конфигурациях километровые процедуры (и километровые запросы, при этом склеенные из разных кусков), на которые даже не наденешь расширение, не расставив граблей для будущего шафла на каком-нибудь обновлении.
Смотрим типовой код. ШаблоныСообщений.СформироватьСообщениеИОтправить. Через какой транспорт отправится сообщение? Правильно, не очевидно. Если сделали шаблон с видом "Прочее", то вообще не отправится. Далее ШаблоныСообщенийСлужебный.СформироватьСообщениеИОтправить - если без закрывающего Иначе. Сколько лет уже не могут нормально сделать и висят эти прекрасные шаблоны сообщений мертвым грузом. А вещь хорошая, если допилить с умом.
Т.е. резюмируем : неудачное архитектурное решение и грязный код реально похоронили часть функционала, он просто не пригоден и висит мертвым грузом.
1. Огрехи архитектуры платформы
2. Огрехи синтаксиса ЯП платформы
3. Огрехи стандартной встроенной библиотеки платформы
4. Огрехи проектирования БСП
5. Огрехи оф Стандартов разработки для платформы
6. Огрехи разработки прикладных решений у руководства и исполнителей на местах эксплуатации
7. Огрехи сертифицированного обучения (документации и курсов)
8. Огрехи сертификации квалификаций, и контроля результирующих продуктов (серийных, и на местах)
9. Огрехи их доработки/расширения, условно "в отраслевых" (и прочих) решений, в сложившихся обстоятельствах
10. Огрехи сопровождения на местах в сложившихся обстоятельствах, усугублённые персональным мировоззрением
Там на каждом уровне 100500 своих проблем, часть из которых тянется с предыдущих уровней. И главное, что тут от самого корня проблем и до верха - по сути всем плевать на них!
Огрехи юзабилити и функциональности IDE (Конфигуратор, EDT) - всё очень сильно устарело, и совершенно не удовлетворяет современным методикам ведения разработки - а могло бы хотя бы отчасти сгладит большую часть остальных огрехов, даже высокого уровня
А по остальным, указанным Вами констатациям - я не придерживаюсь такой точки зрения. И очень хочу найти пути решения данных проблем
первый раз его "плоды" увидел в обработке обмена данными для УТ с заказами "Наполеон".
все что можно было вынести в отдельные процедуры или функции все было вынесено, чисто и красиво.
Но вот доработывать эту лапшу было полное мучение, постоянные прыжки туда сюда, открытие закрытие файлов. Поэтому да для нормального 1с-ника не вижу ничего плохого в процедуре на тысячу строк где вся логика спрятана в ней.
Это лет 20 назад - был только дядушка Боб Маратин - которого все 20 лет активно критиковали! И было/есть за что!
Но за 20 лет - множество других авторов наклепали своего виденья чистого кода и чистой архитектуры!
В 1С - есть Стандарты разработки для платформы 1С - и.... и собственно почти всё (если очень поискать - у Жёлтого клуба есть курс - "Практика чистого кода на 1С", по мотивам дядюшки Боба). А сообщество 1С так и делится либо на тех, кто свято соблюдает Стандарты разработки для платформы 1С, либо считает их "чуть ли не сатанинской библией программиста", либо мимикрирует под первых, придерживаясь взглядов вторых, либо им сугубо пофиг!
И мало где на местах пытаются внедрять свои стандарты разработки. Зато почти во всех более-менее серьёзных вакансиях 1С программистов/архитекторов требуют знание и соблюдение Стандартов разработки 1С (даже если их и не соблюдают по факту).
Но Стандарты 1С - это, всё-таки, не совсем "Чистый код" - это скорее "Грязная архитектура", но вознесённая в статус официального эталона! И поймите меня правильно, не всё там уж совсем плохо... здравые зёрна тоже есть (но порой с дядюшкой Бобом и они расходятся), и многое обусловлено "грязной" и устаревшей архитектурой платформы, и некоторыми, видмо, личными предубеждениями топов из 1С и архитекторов от туда же.
Но и в Чистом коде / Чистой архитектуре дядюшки Боба, тоже всё не так уж гладко (а критикуют там знатно, в отличии, кстати, от стандартов 1С - коих, почему-то почти никто открыто не критикует), так что истиной во языцах - и творчество Роберат Мартина считать не стоит. Тем более в среде ущербной 1С, тем более что он писал это для среды ущербной Java - что устарела так же сильно как и среда 1С:Исполнителя!
Вы лучше попробуйте почитать "Чистый Python" Дэна Бейдера - что к 1С8, наверное, чуть поближе будет, хотя Питон уже тоже далеко не современен. Но, признаю честно и чисто - сам ещё не читал сиё творение - так что не пинайте - я просто намекнул, что вот есть и такой вот взгляд!
Ну а что дальше.... в мире придёт великий AI LLM - и начнёт анализировать, контролить и рефакторить, а то и генерирть код - чтобы было красиво, чтобы было просто, чтобы было чисто и без ошибок!
А в 1С Предприятие .... не в этой жизни - тут рефакторинг уровня 20-летней давности то толком завести не могут! Не говоря уже о Копилоте и авторефакторинге (хотя да - 1С Напарника пилят... для ущербной EDT - ну поглядим...). Не говоря уже про синтаксис, который позволил бы действительно писать красиво и современно (да что там - уже давно введённое улучшение - для асинхронного программирования ни до ума довести не могут, ни в типовых конфигурациях применить)! Ауж про удобную IDE и мечтать не приходится...
Главное, что упускает автор, — это прагматизм. Профессионализм в нашей работе — это не слепое следование модным концепциям, а умение найти баланс между идеальным кодом и реальными потребностями бизнеса: сроками и бюджетом. Мы решаем конкретные бизнес-задачи, и часто самое эффективное решение — не то, которое понравится фанату «дядюшки Боба», а то, которое заработает быстро и будет стоить разумных денег.
Подобное высокомерие, как в статье, только отталкивает и не способствует никакому развитию. Диалог возможен только при взаимном уважении.
Если вам не приходилось иметь дело с кодом, который больше нельзя поддерживать, а переписать невероятно дорого, то конечно вы будет смотреть на чистый код скептически. А если поразбираете грязный код на части и подумаете, как надо было сделать, чтобы не оказаться в такой заднице, то скорее всего сформулируете те же всем известные принципы.
Проблема часто не в «грязи», а в «сложности». И это совершенно разные вещи.
Возьмем типовые конфигурации 1С. Они написаны по стандартам. На микроуровне, внутри одной конкретной функции, код может быть идеально «чистым». Но на макроуровне, чтобы отладить простую бизнес-операцию, нужно пропрыгать по десяткам модулей и понять, как вся система взаимодействует сама с собой. В итоге мы получаем архитектурно сложный код, который формально чист, но запутан.
И наоборот, я видел много «грязного» кода — например, процедура на 300 строк без единого комментария, — но логика в ней была простая и линейная. Разобраться в ней было делом 15 минут.
Так вот, код становится неподдерживаемым, когда он сложный, а не обязательно когда он «грязный». И парадокс в том, что погоня за идеальной «чистотой» и абстракциями очень часто порождает ту самую избыточную сложность, которая и убивает проект. Может, нам стоит бороться не столько за формальную чистоту, сколько за простоту и понятность?
Да, пока ИИ еще не может так же свободно писать полноценные доработки для 1С, как для Python или JS, но это лишь вопрос времени, причём очень недолгого.
И в этом свете весь наш спор выглядит, как будто старые ямщики жарко спорят, какие лошади лучше и как их правильнее запрягать, в то время как на дороге уже появились первые автомобили. Еще несколько лет — и все эти разговоры про упряжь и породы лошадей потеряют всякий смысл.
А еще гит, где правка одной мегапроцедуры или файла будет вести к каонфликтам. Никуда вы не денетесь от чистого кода.
Но мне кажется, мы немного путаем понятия. То, что вы называете «чистым кодом», я бы назвал «грамотной архитектурой». Мой же тезис был о другом: о локальных, тактических компромиссах. Иногда, чтобы успеть в срок, можно поставить деталь с неидеальной маркировкой (плохое имя переменной) или использовать не самый элегантный, но прямой и понятный крепеж (повторение 2-3 строк кода). Настоящий профессионал понимает, когда такой компромисс допустим, а когда он закладывает мину под будущую архитектуру. Слепое же следование правилам — признак специалиста, который боится брать на себя ответственность.
И самое главное, о чем мы забываем в споре о двигателе, — это сама дорога. Основная сложность — не в коде, а в бизнес-процессах, которые он отражает. Можно иметь идеально «чистый» и модульный автомобиль, но если вы не понимаете сложной карты местности (предметной области), вы разобьетесь на первом же перекрестке. Я видел множество проектов, где код был безупречен, но поддерживать его было невозможно, потому что никто уже не понимал заложенную в него запутанную бизнес-логику.
Поэтому настоящий профессионализм — это не только умение строить красивые архитектуры, но и глубокое понимание бизнес-задачи, а также умение выбирать адекватные инструменты и компромиссы для ее решения. Без первого мы получим «грязный» код, а без второго — красивую, но бесполезную или слишком дорогую игрушку.
До имен переменных нет смысла опускаться уже, не 2000 год на дворе.
Может быть проще пойти от "грязного кода". Если вы при смене транспорта переписываете весь обмен, например, значит это был грязный код.
Когда вы пишете, что в процедуре на 300 строк «архитектуры нет особо», вы показываете, что для вас архитектура — это исключительно то, как организован код: разбит ли он на функции или нет. Но это в корне неверное и очень узкое понимание. Архитектура решения — это комплексное понятие, включающее в себя структуру таблиц базы данных, их взаимосвязи, организацию бизнес-логики, пользовательский интерфейс и многое другое. Сам код — лишь малая часть, которая эту архитектуру реализует.
Забавно, что обсуждать имена переменных вы считаете «не 2000 годом», а разбиение на процедуры — актуальным. И то, и другое — всего лишь аспекты чистоты кода, а не архитектуры.
Моя позиция, которую я пытался донести, остается прежней: поддерживаемость кода — это комплексный вопрос. При грамотной архитектуре и глубоком знании бизнес-процессов код будет поддерживаемым, даже если он не идеально «чистый» в формальном понимании. И наоборот, можно иметь идеальный код в системе с порочной архитектурой, и поддерживать его будет невозможно. Тот, кто не понимает этой комплексности, к сожалению, обладает недостаточно глубоким опытом.
Спасибо за общение, но без единого понятийного аппарата дальнейший разговор бессмыслен.
Было очень интересно обсудить бесполезность солнечных батарей ночью, до Вас никто не обращал внимания на эту деталь.
В этой одной фразе — вся суть нашего расхождения. Для любого практикующего разработчика программирование — это и есть воплощение бизнес-логики в коде. Говорить о «чистоте кода» в отрыве от бизнес-задачи — это то самое «обсуждение бесполезности солнечных батарей ночью».
Честно говоря, я сначала не понимал вашу оторванную от реальности позицию. Но потом все стало на свои места. Я обратил внимание на ваш профиль: за 16 лет на профессиональном ресурсе у вас нулевой рейтинг, ни одной разработки, зато есть история комментариев в стиле, который здесь, на Инфостарте, мягко говоря, не принят.
Это объясняет всё. Вы рассуждаете как теоретик, а не как практик. Поэтому вам так легко игнорировать бизнес-логику.
Спорить дальше бессмысленно. Удачи в комментировании.
Даже не очень оптимальный код, но по хорошему алгоритму, "вывезет" поставленную задачу. И наоборот, идеально вылизанный и прошедший все оптимизации, код, описывающий надевание штанов через голову, никак не обрадует получателей этого "продакта".
Сразу вспоминается дедушка Ленин "Слишком далеки они от народа...."
Короче в статье все было про поливание какашками 1с в духе. Вот в мужицком с++ или джаве надо описывать все, а там платформа сама делает. Вот клиент сервер завезли. В плюсах это надо вручную ,а в 1с надо ОБМАЗЫВАТЬ все процедуры и функции инструкциями предпроцессора &НаКлиенте\&НаСервере и тд. аяяяяй.
Логично что в софтлокнутой платформе все уже сделано для решения задачи на которые эта платформа и предназначена. Однако мужЫцкие прогеры стандартных яп не готовы это принять
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 2475636
Создание 08.09.25 09:59
Обновление 08.09.25 09:59
Просмотры 11108
Загрузки 0
Рейтинг
7
Комментарии 145
Код открыт Да
Рубрики О жизни
Кому Разработчик
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)