Как вы думаете: смог бы Линус Торвальдс в одиночку за 20 лет полностью повторить Асапту версии 3.0?

[Raven Melancholic]

Цитата:

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

В локальном коде надо находить максимально полезные вещи и делать их глобальными. Например, чешские предоплаты.

Да, идея там хорошая. Но в чистом виде использовать сложно. Видимо разработана под определенные кейсы, а при других ситуациях сопоставление ломается.
Пытались взять её в чистом виде для Польской дочки, но с остальным польским функционалом получилась каша.
Это, кстати, как пример что нужно досконально продумывать и тестировать в системе плагинов/микросервисов - один плагин может ломать работу другого.

[fed]

Цитата:

Сообщение от Raven Melancholic

Это, кстати, как пример что нужно досконально продумывать и тестировать в системе плагинов/микросервисов - один плагин может ломать работу другого.

Позволю себе переформулировать это так: Система плагинов при обновлениях экономит время на апгрейде кода, но сильно повышает время на тестирование результата обновления. Как раз потому, что в системе со слоями или какими-то бранчами Version Control можно проанализировать большую часть изменений и взаимосвязей между ними статически, просто за счет анализа кода, а в системе с плагинами - только динамически, тестируя то что получилось.
И что-то мне кажется что экономия на апгрейде кода не окупает повышенные трудозатраты на тестирование.
Так что если бы новую ERP проектировал я (c), то я бы начал ее проектирование с какой-то смеси технологии слоев и технологии TFS (но не GIT). А с плагинами пущай микрософт мучается.

[Logger]

Цитата:

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

... А с плагинами пущай микрософт мучается.

Неее. Ему то пофиг. Это мы будем мучаться.

Напомнило:

Цитата:

- Папа, ты теперь будешь меньше пить ?
- Нет сынок, это теперь ты будешь меньше есть.

[mazzy]

Цитата:

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

Позволю себе переформулировать это так: Система плагинов при обновлениях экономит время на апгрейде кода, но сильно повышает время на тестирование результата обновления.

согласен.

но есть внешние системы (olap, отчеты)
для внешних систем нужна метаинформация.
о relation, о правах, о типах, о конфигурационных ключах...

внутренние структуры типа utilElements - не катят. (См. как мучаются в ER)
хранить как relation и constraints в MS SQL? а как права, типы форматирование?

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

чтобы "подключать", базовая система должна предоставлять базовые объекты (тип, класс, форма, отчет, таблица, запрос и т.п.)
базовая система не должна предоставлять бизнес-логику совсем. (см. системы сборки в java - maven и gradle)

[mazzy]

Цитата:

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

чтобы "подключать", базовая система должна предоставлять базовые объекты (тип, класс, форма, отчет, таблица, запрос и т.п.)

наверное, экранная форма и экранный отчет - это тоже можно вынести в плагины. чтобы можно было запустить базовую систему как сервер (сервис/демон).

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

отдельная тема - отладчик.
все существующие в аксапте сложные фреймворки типа расчета зарплаты, финансовых отчетов, финансовой разноски, reporting service, AIF - это боль при отладке. некоторые псевдовнешние подсистемы типа ER, Retail Sync Service и пр. вообще не имеют отладчика.

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

мы видим код бизнес-логики, потом хоп - xRecord, а потом myTable.validationWrite.
или наш класс, потом хоп - xInfo, а потом снова выныриваем в другом нашем методе. Примерно так.

[belugin]

Цитата:

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

некоторые псевдовнешние подсистемы типа ER, Retail Sync Service и пр. вообще не имеют отладчика.

Есть, но, конечно, далеко не студия. И профайлер тоже есть, да.

Цитата:

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

мы видим код бизнес-логики, потом хоп - xRecord, а потом myTable.validationWrite.
или наш класс, потом хоп - xInfo, а потом снова выныриваем в другом нашем методе. Примерно так.

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

Не хочешь видеть чужого кода - не видишь. Хочешь видеть - видишь.

[belugin]

Цитата:

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

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

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

После чего мы получаем систему со слоями. Преобразовав версию 1 и версию 2 такой системы можно приступать к анализу диффа.

Цитата:

TFS (но не GIT).

А чем гит не угодил?

Для совместимости имхо главное чтобы был понятный контракт.
Поставщик должен знать в резльтате каких его действий потребитель сломается, а потребитель знать, что он может использовать.

Потребитель, правда, норовит вместо следования предписаниям посмотреть на текущую реализацию и привязаться к ней

[fed]

Цитата:

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

После чего мы получаем систему со слоями. Преобразовав версию 1 и версию 2 такой системы можно приступать к анализу диффа.

Не очень понял, что ты хочешь сказать. В D365FO способа сравнить тексты двух версий нет. А если мы о гипотетической новой системе говорим - так я как раз против плагинов в принципе. Потому что если у нас система расширяется путем создания и редактирования бранчей, то как раз правильнее не создавать точек расширения, делегатов и тд и тп, потому что они как раз снижают шансы найти изменения путем сравнения текстов.

Цитата:

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

А чем гит не угодил?

Ну мне кажется что Git слишком гибкий и тяжелый для данной проблемы. На конкретном проекте редко когда больше 5-7 разработчиков работает, редко когда больше двух активных веток разработки ведется, редко когда нет онлайна к репозиторию исходных текстов и тд и тп. В такой ситуации, особых преимуществ Git не дает, а шансов прострелить самому себе ногу - в Git гораздо больше.
Идеальным было бы что-то типа TFSVC, но с возможностью импорта diff между двумя версиями как новой ветки.
Еще можно было бы подумать на тему, что было бы, если бы система хранения версий знала бы о семантике метаданных и могла бы показывать например разницу между двумя версиями таблицы как "таблицу", но с одним индексом, тремя полями (с разной подсветкой в зависимости от типа изменения) и т.п. Это не стало бы прорывом, но затраты на мерджинг уменьшило бы раза в 2-3. Кроме того - если система версий знает о семантике объектов, то можно было бы сделать какие-то пользовательские расширения, которые например позволяли бы мерджить какие-то типы объектов автоматически, выдывали бы варнинги при всяких сомнительных мерджах и несовместимых изменениях и тд и тп.

[belugin]

Цитата:

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

Не очень понял, что ты хочешь сказать. В D365FO способа сравнить тексты двух версий нет.

Взять XPO из старой версии, взять XPO из новой версии, сравнить.

Цитата:

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

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

В данном треде мы обсуждаем идеи топикстартера. Это и есть гипотетическая новая система.

Соответственно вопрос, то, про что ты говоришь - фундаментальное ограничение или недостаток тулинга.

Цитата:

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

В такой ситуации, особых преимуществ Git не дает, а шансов прострелить самому себе ногу - в Git гораздо больше.

В целом согласен. Да, гит сложнее, но его знают больше.

[mau]

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

В Аксапте, как мне кажется, наоборот, уровень описания слишком низкий - таблица, класс, форма, отчет, специфические сущности.Это по сути высший технологический уровень. Порой не хватало элементов AOT типа справочник, журнал, документ, бизнес-процесс (который потом появился).

Мне представляется полезным возможность расширения ядра для возможности реализации системы на том уровне абстракции, который требует прикладной домен, для которого разрабатывается система. И это расширение как раз можно сделать плагинами.

[Ace of Database]

Цитата:

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

В Аксапте, как мне кажется, наоборот, уровень описания слишком низкий - таблица, класс, форма, отчет, специфические сущности.Это по сути высший технологический уровень. Порой не хватало элементов AOT типа справочник, журнал, документ, бизнес-процесс (который потом появился).

Вот и мне интересно, они специально так делают? Всякие заказы на продажу, складские журналы, спецификации, сопоставления, маршруты комплектации, заказы на производство. Это же все можно засунуть в "документы". И обрабатывать их одинаковым API у которого наружу выставлены одинаковые методы. Вместо это сделали так, что каждый тип документа надо обрабатывать по-своему, изучать его кишки, изучать его структуру классов.
Прикладной программист, по сути, превращается в некоего хакера.
Пусть к "документу" будет низкоуровневый доступ как к таблице. Но хочется чтобы классы, которые обрабатывают "документы" имели одинаковые внешние точки вызова.Меня именно запутанность и разношерстность классов напрягает. А доступ к документам на уровне таблиц - это как раз преимущество.
Даже если брать не Аксапту, а например, сравнить веб-аутлук и майл-ру. В веб-аутлуке все запутано, где-то сообщения снизу вверх идут, где-то сверху вниз. И как-то мало полезной информации на экране, хотя весь экран загроможден чем-то. А в майл-ру с первых же дней использования сразу все понятно. Мне кажется, американские разработчики софта как-то запутались. И странно то, что те разработчики, которые делали удобные инструменты, например Борланд, исчезли. А остались те, которые делают неудобные Я например, в 1989 году не осилил Microsoft MSC, а на Борланд ТурбоВижн написал многооконный текстовый редактор с подсветкой синтаксиса и перекрывающимися окнами в текстовом режиме DOS. А на турбо-ассемблере написал графический редактор с закрашиванием областей.
Я 17 лет работаю со всеми версиями Аксапты, и все равно считаю Аксапту парадоксальной. Но такова жизнь Квантовая запутанность, жизнь состоит из парадоксов. И само явление жизни - это чудо. Поэтому я воспринимаю всю эту корявость как должное - просто я попал в ту вселенную, где такая Аксапта. Волновая функция вселенной так чудит.