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

[sukhanchik]

Цитата:

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

Мне кажется, что стоит попробовать:

1) Выбросить несущественные объекты (джобы, меню-айтемы, может меню, ресурсы, может макросы). Степень их модифицированности IMHO мало существенна.

2) Попробовать считать от объектов верхнего уровня. Новый метод в существующем классе и новый метод в новом классе — не совсем одно и то же. Например, отдельно посчитать отношение модифицированных классов к стандартным, и уже только для них сравнить модифицированные и стандартные методы. Так картинка будет более наглядной.

3) Подумать над удельными весами значимости модификаций в тех или иных объектах.

Я понимаю, что это будет усложнением. Но если рассматривать это как временную меру, то это может помочь найти зависимости и выработать эффективную методику оценки степени модифицированности.

Джобы стоит выкинуть - согласен. Меню айтемы и меню являются неотъемлемой частью приложения - выкидывать их нельзя. Макросы тоже выкидывать нельзя. Ресурсы? А чем они провинились? Они также являются неотъемлемой частью приложения. Тем более - что в них иногда что-нибудь могут сохранить.

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

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

Получается - что погрешность джоба Сергея лишь в том, что он учитывал джобы в приложении. Но это уверяю - при всем кол-ве объектов - ничтожная погрешность

[glibs]

Цитата:

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

[Волчара]

Цитата:

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

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

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

Цитата:

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

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

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

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