Комментарии 30
А к чему все это?
Очень интересно получилось. Ну и выводы вполне ожидаемы:
* больше всего драйверов в УТ,
* кода в регл.отчетности (хотя там сплошной копипаст)
* чемпион по размеру — обмен м контролирующими органами
* самая большая процедура — расчет налогов ПФР
И если первое еще можно принять как объективное требование поддержки кучи оборудования «из коробки», то остальное передает привет всем тем, кто захочет полноценно зайти на рынок автоматизации бухучета.
* больше всего драйверов в УТ,
* кода в регл.отчетности (хотя там сплошной копипаст)
* чемпион по размеру — обмен м контролирующими органами
* самая большая процедура — расчет налогов ПФР
И если первое еще можно принять как объективное требование поддержки кучи оборудования «из коробки», то остальное передает привет всем тем, кто захочет полноценно зайти на рынок автоматизации бухучета.
К чему используется круговая диаграмма?! Это же разные конфигурации, они не делают никакого «общего пирога».
Всегда задавался вопросом почему макеты отчетности и драйверы торгового оборудования хранят в конфигурации? Ведь можно их хранить уже в базе в ХранилищеЗначения. Можно было бы подгружать их с того же сайта ИТС только по мере необходимости. Файл конфигурации (.cf) сильно бы уменьшился
"Всё своё ношу с собой". © 1С.
Я думаю, что следующий этап — это более массовое использование расширений.
И регламентированной отчётности, и драйверам из БПО там было бы самое подходящее место.
В отличие от хранения всего этого добра в БД, расширения можно (и нужно) подключать, не входя в режим Предприятие.
И регламентированной отчётности, и драйверам из БПО там было бы самое подходящее место.
В отличие от хранения всего этого добра в БД, расширения можно (и нужно) подключать, не входя в режим Предприятие.
Больший размер конфигурации — дольше время обновления, а у 1с-ников оплата почасовая.
« Я думаю, многим знакома ситуация, когда стек вызовов достигает нескольких десятков вызовов и очень трудно понять с чем связана такая сложность. »
Может все дело в ограничении платформы и отсутствия ооп? Сложно слепить чистую архитектуру на всем этом. Но я вас утешу, на старом энтерпрайзном легаси где почти вся бизнес логика в pl/sql все примерно так же если не хуже.
Может все дело в ограничении платформы и отсутствия ооп? Сложно слепить чистую архитектуру на всем этом. Но я вас утешу, на старом энтерпрайзном легаси где почти вся бизнес логика в pl/sql все примерно так же если не хуже.
Мне вот интересно — как это собиралось все. Не в ручную же?
И было бы интересно увидеть еще пару графиков — уровни вложенности деревьев функций, т.е. есть функция проведения документов — и сколько разных функций используется при проведении и какой максимальный уровень вложенности этих функций, это бы наглядно показало разницу в сложности восприятия. Хотя, тут бы надо было делить БСП и прикладной функционал.
Ну и график когнетивной сложности функций. Есть подозрение, что в новых конфах хоть и увеличилось количество функций, и заложена логика того, что функции должны быть проще, но это было заметно только в первых релизах, а потом пошел жесткий допил.
Конечно, всем понятно — что эти графики ни о чем не говорят, и сравнение идет теплого с зеленым, но уж если есть желание сделать цифирки ради цифирок, то почему бы и нет :)
И было бы интересно увидеть еще пару графиков — уровни вложенности деревьев функций, т.е. есть функция проведения документов — и сколько разных функций используется при проведении и какой максимальный уровень вложенности этих функций, это бы наглядно показало разницу в сложности восприятия. Хотя, тут бы надо было делить БСП и прикладной функционал.
Ну и график когнетивной сложности функций. Есть подозрение, что в новых конфах хоть и увеличилось количество функций, и заложена логика того, что функции должны быть проще, но это было заметно только в первых релизах, а потом пошел жесткий допил.
Конечно, всем понятно — что эти графики ни о чем не говорят, и сравнение идет теплого с зеленым, но уж если есть желание сделать цифирки ради цифирок, то почему бы и нет :)
В новых конфигурациях алгоритм проведения (формирование наборов записей) реализован через SQL запрос, и как следствие сложность этого алгоритма выражается не в количестве вызываемых функций, а в количестве запросов в пакете. И да, их там может быть сотни.
И было бы интересно увидеть еще пару графиков — уровни вложенности деревьев функций, т.е. есть функция проведения документов — и сколько разных функций используется при проведении и какой максимальный уровень вложенности этих функций, это бы наглядно показало разницу в сложности восприятия. Хотя, тут бы надо было делить БСП и прикладной функционал. Следите за обновлениями
Об это будет отдельная статья, т.к вопрос крайне интересный и захотелось акцентировать внимание в целиком в одной статье.
Мне вот интересно — как это собиралось все. Не в ручную же?
В целом, было так: сбор и сохранение данных/метрик с помощью java, сущности сохраняла в mysql. Далее, написала небольшую конфиграцию, которой цеплялась к mysql и агрегировала данные для отчетов. Заключительным этапом выгружала таблицы в Excel и строила графики.
Для чего эти знания? Сейчас кто-то парится оптимизациями, минимизациями?
Было интересно узнать сколько там одинакового по функционалу кода копипасты в разных обьектах
Исследовал в свое время этот вопрос. Довольно давно, но не думаю, что что-то сильно изменилось. Некоторые результаты вот в этой статье: infostart.ru/public/294285. Правда, там основной акцент сделан на разработке инструмента для измерения копипаста — «копипастомера», но результаты тоже озвучены.
Коротко говоря, копипаста много.
Коротко говоря, копипаста много.
В 1С, действительно, перестали париться с оптимизациями, и это сильно заметно в последних обновлениях.
Интересно, почему разница в объеме драйвером УТ и ERP? Ведь УТ и КА получаются вырезанием "лишнего" из ERP
Подсчёт (и сравнение) общего количества методов (и модулей) в «старых» и «новых» конфигурациях получается не вполне корректным.
Дело в том, что в новых конфигурациях широко используются «библиотеки». И, если одна и та же библиотека входит в состав нескольких конфигураций — её модули и методы оказываются посчитаны многократно.
Было бы неплохо отдельно подсчитать статистику по библиотекам, хотя бы наиболее употребительным, вроде БСП, БПО, БРО и т.п. И исключить (или обособить) их при «обсчёте» конфигураций.
Дело в том, что в новых конфигурациях широко используются «библиотеки». И, если одна и та же библиотека входит в состав нескольких конфигураций — её модули и методы оказываются посчитаны многократно.
Было бы неплохо отдельно подсчитать статистику по библиотекам, хотя бы наиболее употребительным, вроде БСП, БПО, БРО и т.п. И исключить (или обособить) их при «обсчёте» конфигураций.
Контекстная подсказка в 1с есть — ставишь точку после модуля, выскакивают имена функций, ну или Ctrl + Пробел после точки или части имени. Но это мелочи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статистика 1С или насколько глубока кроличья нора