Низкий порог входа [в 1С] - миф, чаще требуется не столько знание языка, сколько знания предметной области...
Тоже об этом думал. Ведь алгоритмические конструкции условий и циклов плюс-минус одинаковые в разных языках, а вот обрабатываемые данные уникальны для различных стран и даже для различных областей бизнеса. Важно понять с чем и как нужно работать, лишь затем приниматься за программирование.
Мне кажется, что на текущий день знание какого-то конкретного ЯП вообще уходит на второй план. Даже стали появляться "вайпкодеры", которые вообще не знают языков и делегируют все кодирование специализированным ИИ. Потому еще более важным стало ЧТО ты пишешь, а не КАК.
Вспомнился отличный пример!
Этой зимой старый знакомый попросил глянуть отчет по кешфлоу на СКД, который очень долго формировался, а расшифровка статей ДДС до регистраторов вообще занимала более десяти минут. База - "Бухгалтерия 3" и данные для отчета хранятся в регистре бухгалтерии.
Сразу скажу, что проблема была из-за необходимости выводить все данные в валюте отчета и из-за расчета курсов этой валюты на даты каждой из операций. И все это в едином мегазапросе. У планировщика SQL просто не было никаких шансов сделать что-то помимо цепочки из Scan.
Такие задачи для меня одни из любимых - еще со "студенческой скамьи" люблю копаться в SQL-запросах, делая их более оптимальными. Я аккуратно развалил запрос на десяток временных таблиц и начал собирать свою версию финальной выборки. В оригинале для дебета и кредита были сложные условия из десятков повторяющихся конструкций для расчета суммы по крос-курсу, которые я стал минимизировать. При чем для упрощения использовал не только карты Карно, но и знание предметной области: в бухгалтерском учете все значения валютных операций хранятся в национальной валюте по курсу нацбанка на дату операции (если покупка и оплата в разные дни по разным курсам, то еще нужно рассчитать курсовые разницы, но тут это не важно) - т.е. кросс-курс в принципе можно не считать и пересчитывать суммы операций сразу в валюту отчета.
Вот только сравнение оригинального медленного и моего ускоренного отчетов показало различия. Сверка показала, что в декабре 2023 года в базе было несколько документов, в которых суммы операций были равны валютным суммам документов - кто-то указал курс 1:1 и исказил бухгалтерские данные. С одной стороны - отчет уже работает быстро, а документы пусть пользователи сами приведут в порядок. Но с другой стороны, у меня же есть знание предметной области: в бухгалтерском учете каждый год завершается сдачей годовой отчетности и закрытием периода; если находятся ошибки, то они исправляются ручными операциями в следующем отчетном периоде - т.е. мой предшественник просто вынужден был ввести крос-курсы, а совет исправить документы просто нереалистичен! Ок, добавил еще по одному условию в дебет и кредит (три кейс-ифа вместо моих предыдущих двух, но и вместо оригинальных десяти), после чего отчет сошелся.
Итого, в этом случае знание предметной области минимизировало необходимость консультироваться с экспертами и позволило не просто быстро самостоятельно понять существующий алгоритм, но и эффективно его оптимизировать. Плохо представляю, что на моем месте делал бы даже самый талантливый, но джун после курсов.