Как сильно модифицировано ваше приложение Аксапты?

[glibs]

Цитата:

Сообщение от sukhanchik

...
нельзя
...

"Нельзя" — это не аргумент, если мы не в детском саду.

Я не программист, я экономист .

Я к вопросу подхожу с практической стороны. В статистике есть подход, когда сильно выбивающиеся из общего набора наблюдений значения отбрасывают чтобы лучше определить зависимость.

Цитата:

Сообщение от sukhanchik

...
В отношении методов - это вопрос спорный. И нет связи новыми класами и стандартными.
...

Не осилил мысль.

Цитата:

Сообщение от sukhanchik

...
Удельный вес модификаций джобом не вычислишь - так что это не получится.
...

О его вычислении речь и не шла. Его можно определить экспертным путем (в программистских терминах это константа). Но это потом.

[sukhanchik]

Цитата:

Сообщение от glibs

"Нельзя" — это не аргумент, если мы не в детском саду.

"Нельзя" в данном контексте - означает - что при выкидывании - мы намеренно исказим исходные данные, а это будет означать заведомую некорректность выходных данных.

Цитата:

Сообщение от glibs

Я к вопросу подхожу с практической стороны. В статистике есть подход, когда сильно выбивающиеся из общего набора наблюдений значения отбрасывают чтобы лучше определить зависимость.

Есть такой подход (сам выпускался по этой кафедре). Но я не понимаю каким образом макросы, ресурсы и менюшки являются "сильно выбивающимися".

В отношении методов - мысль моя состоит в том, что нельзя "завышать" оценки методам на стандартных классах перед методами на созданных классах (объектах).
Тогда уж надо рассматривать подробно что за класс и т.д. Если класс относится к целой иерархии классов - то да, добавление метода здесь - более значимо, нежели в (к примеру) классе - обертке ADO или COM-интерфейса к Excel

Цитата:

Сообщение от glibs

О его вычислении речь и не шла. Его можно определить экспертным путем (в программистских терминах это константа). Но это потом.

Это константа для одного отдельно взятого приложения. Но она разная для разных приложений - а значит это не константа в целом (опрос проводится среди множества приложений)

[mazzy]

Цитата:

Сообщение от sukhanchik

Может поэтому?

ну, не настолько же и не так регулярно...
сейчас видна систематическая погрешность, когда процент изменынных/новых объектов у многих меньше процента размера файлов.

надо подумать.

насчет джобов - думал, но согласен с тем, что джобы дают ничтожно малую погрешность. причем в сторону увеличения. а сейчас видим уменьшение.

насчет "Выбросить несущественные объекты" тоже думал. но так и предполагал, что возникнет спор "что считать несущественными". поэтому посчитал все объекты.

если уж и выбрасывать что-то, то я больше склоняюсь к предложению _scorp_: считать только те объекты, которые включены лицензионными и конфигурационными ключами. Но при таком подходе возникает вопрос а что делать с классами/формами/отчетами, которые не привязаны напрямую к конфигурационным ключам... И что делать с переменным числом объектов в знаменателе... поэтому также посчитал все объекты.

[gl00mie]

Цитата:

Сообщение от mazzy

У меня закрадывается подозрение, что подсчет по объектам дает существенно меньший процент, чем подсчет по размеру файлов. Но объяснить "почему так" я пока не могу.

Помнится, давно была тема, почему, мол, таблицы и классы хранятся в разных слоях в разрезе полей/методов, а те же формы и отчеты при модификации копируются в вышележащий слой целиком. Так вот, и тут это может влиять: если изменить несско свойств/метод на стандартной таблице или поменять метод в стандартном классе, то в другой слой перекочует лишь определение самой таблицы или отдетного метода, т.о. в размере вышележащий слой увеличится совершенно незначительно - от сотен до считанных тысяч байт. В то же время, если изменить одно-единственное свойство на элементе формы или отчета, то они - форма или отчет - целиком будут скопированы в вышележащий слой, а стандартные формы/отчеты подчас занимают в виде того же экспорта мегабайты. Вот и получается разница в процентах при подсчете изменений "на вес" и в штуках записей UtilElements.

Цитата:

Сообщение от sukhanchik

Джобы стоит выкинуть - согласен. Меню айтемы и меню являются неотъемлемой частью приложения - выкидывать их нельзя. Макросы тоже выкидывать нельзя.
В отношении методов - это вопрос спорный. И нет связи новыми класами и стандартными.

Мне кажется, надо разделить подсчитываемые объекты по принадлежности к бизнес-логике либо к презентационной логике и считать проценты по ним отдельно. Понятное дело, что и на форме можно навертеть бизнес-логики, и стандартный функционал этим местами грешит, но все же "модификация стандартного функционала" - это в первую очередь изменение классов и таблиц.

[mazzy]

Цитата:

Сообщение от gl00mie

а стандартные формы/отчеты подчас занимают в виде того же экспорта мегабайты.

Да, ладно?
У кого-нибудь есть время джобик проверочный сделать?
А то у меня руки только в выходные до этого вопроса дойдут.

Цитата:

Сообщение от gl00mie

Мне кажется, надо разделить подсчитываемые объекты по принадлежности к бизнес-логике либо к презентационной логике и считать проценты по ним отдельно. Понятное дело, что и на форме можно навертеть бизнес-логики, и стандартный функционал этим местами грешит, но все же "модификация стандартного функционала" - это в первую очередь изменение классов и таблиц.

Ой, спорно...

[sukhanchik]

Проверил. DAX 4.0 SP2 почти чистая. Почти, т.к. она чистая, но с залитыми туда разраб. утилитами+TaskRecorder в usr-слой
Экспортнул форму Address. Размер XPO: 50 533 bytes (смотрю не размер на диске, а именно размер файла)
Экспортнул форму SalesTable. Размер XPO: 422 313 bytes.
Обе формы - "чистые" - т.е. без изменений. Вывод - не каждая форма выгружается мегабайтами.

Замерил размер usr-слоя до модификаций. 13 835 034 байт (я ж говорю - не совсем у меня чистый usr)
Сделал модификацию в usr-слое - переименовал свойство Caption на дизайне формы SalesTable (форму специально взял большую - будет интереснее смотреть прирост).
Замерил размер usr-слоя после модификаций и остановки АОСа (aod изменяется именно в момент остановки АОСа). 14 111 185 байт

Итого - прирост - 276 151 байт. Чуть больше половины размера XPO.

Запустил АОС и удалил свои изменения. Остановил АОС. Размер aod-шника не изменился (в общем-то это ожидалось).

Зашел в usp-слой (его у меня не было).
Появился файл axusp.aod (8 192 байт)
Сделал тоже самое изменение на форме SalesTable
Вышел, остановил АОС.
Размер файла axusp.aod стал 310 573 байт. Прирост: 302 381 байт

Вывод - XPO более "пухлый", нежели AOD

ОС: Windows 2008 Server SP2, файловая система - NTFS.

Кстати - обнаружил интересный глюк в виндах (2008). Если встать на файл и смотреть на размер файла в строке состояния - то мы видим некий размер файла (допустим, 13 Мб). Далее, жмем F5 (обновить). О чудо! Размер файла уже "стал" 26 Мб. Снова жмем F5. Теперь файл "стал" 39Мб.
Но в свойствах файла размер показывается правильно.

[gl00mie]

Цитата:

Сообщение от sukhanchik

Проверил. DAX 4.0 SP2 почти чистая. Экспортнул форму SalesTable. Размер XPO: 422 313 bytes. Вывод - не каждая форма выгружается мегабайтами.

Ну да, в принципе, впечатления о мегабайтных экспортах форм наподобие SalesTable сформировались на 3-ке, где для объектов AOT выгружаются все свойства, а не только те, чьи значения отличны от значений по умолчанию (вроде с 4-ки сделали такую оптимизацию, чтобы упростить работу с системами контроля версий) Для сравнения, файл экспорта той же формы SalesTable со слоя dis на 3.0 SP5 EE FP1 занимает 985kb.
В любом случае, распухание слоя даже на несско сотен килобайт при изменении одного свойства на элементе формы существенно отличается от увеличения слоя на считанные сотни, ну, может, тысячи байт при, скажем, изменении свойства таблицы или метода класса. В то же время, в исходном опросе касаемо степени модифицированности приложения такие отличия не принимались во внимание.

Цитата:

Сообщение от sukhanchik

Кстати - обнаружил интересный глюк в виндах (2008). Если встать на файл и смотреть на размер файла в строке состояния - то мы видим некий размер файла (допустим, 13 Мб). Далее, жмем F5 (обновить). О чудо! Размер файла уже "стал" 26 Мб. Снова жмем F5. Теперь файл "стал" 39Мб. Но в свойствах файла размер показывается правильно.

Наверное, "глюк" не столько в виндах, сколько в проводнике, и связан он, видимо, со следующим:

• как та или иная программа пишет файлы: некоторые программы копирования, например, заранее резервируют все необходимое место под файл и лишь затем заполняют его данными, другие могут писать в файл последовательно, так что он после создания будет постепенно увеличиваться в размере;
• как (часто) винды посылают уведомления об изменении содержимого каталога, и для получения каких именно уведомлений регистрируется проводник (см., например, SHChangeNotifyRegister())

[sukhanchik]

2gl00mie: В отношении глюка в виндах я бы поверил Вашей версии, если бы не 2 но:
1. Нажатие не F5, а Refresh из контекстного меню к таком эффекту не приводит.
2. Переход в другою папку и возврат к исходной - приводит к правильному отображению размера.

[Волчара]

Цитата:

Сообщение от gl00mie

Помнится, давно была тема, почему, мол, таблицы и классы хранятся в разных слоях в разрезе полей/методов, а те же формы и отчеты при модификации копируются в вышележащий слой целиком.

Кстати, в первую очередь все исправляется в формах, во первых это людям кажется более очевидным, во вторых не у всех есть лицензия на x++, а на morfX есть у всех.

Цитата:

Сообщение от gl00mie

Мне кажется, надо разделить подсчитываемые объекты по принадлежности к бизнес-логике либо к презентационной логике и считать проценты по ним отдельно.

Я об этом говорил...

Предложу еще один вариант: Надо выделять исправленные объекты и СОЗДАННЫЕ НОВЫЕ.
1. Существует большое количество всяких отраслевых заморочек - это большие объемы кода написанные полностью с нуля, часто дублирующие стандартные функции системы
2. Для любого программиста легче написать модуль, чем разобраться в инструментах системы, которые есть - вот и пишут новички огромные трактаты на языке X++

[Павел Масленов]

Не очень понятен смысл опросов и как автор собирается интерпретировать результаты. Больше похоже просто на развлечение.

[glibs]

В данной теме уместно будет написать про "Сервис\Средства разработки\Обновить код\Отчет об оценке" и "Сервис\Средства разработки\Обновить код\Параметры".