|
27.05.2021, 17:48 | #1 |
Moderator
|
Цитата:
И что-то мне кажется что экономия на апгрейде кода не окупает повышенные трудозатраты на тестирование. Так что если бы новую ERP проектировал я (c), то я бы начал ее проектирование с какой-то смеси технологии слоев и технологии TFS (но не GIT). А с плагинами пущай микрософт мучается. |
|
|
За это сообщение автора поблагодарили: sukhanchik (5), mazzy (2), Logger (1). |
27.05.2021, 18:00 | #2 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
27.05.2021, 19:47 | #3 |
Участник
|
Цитата:
но есть внешние системы (olap, отчеты) для внешних систем нужна метаинформация. о relation, о правах, о типах, о конфигурационных ключах... внутренние структуры типа utilElements - не катят. (См. как мучаются в ER) хранить как relation и constraints в MS SQL? а как права, типы форматирование? все равно метаинформация нужна. так пусть по ней не только внешние системы работают, но и сама система по ней же. а раз так, то базовая система - это всего лишь платформа для подключения плагинов и управления ими. базовая система должна знать откуда брать подключаемые плагины, зависимости между плагинами. чтобы "подключать", базовая система должна предоставлять базовые объекты (тип, класс, форма, отчет, таблица, запрос и т.п.) базовая система не должна предоставлять бизнес-логику совсем. (см. системы сборки в java - maven и gradle) Последний раз редактировалось mazzy; 27.05.2021 в 19:53. |
|
27.05.2021, 21:26 | #4 |
Участник
|
Цитата:
система прав доступа - точно в плагины. т.е. в базовой системе должны быть точки расширения, в которых у плагинов запрашиваются права. и должна быть какая-то реализация по-умолчанию, в которой даются все права. также должен быть представлен плагин со стандартной реализацией прав. отдельная тема - отладчик. все существующие в аксапте сложные фреймворки типа расчета зарплаты, финансовых отчетов, финансовой разноски, reporting service, AIF - это боль при отладке. некоторые псевдовнешние подсистемы типа ER, Retail Sync Service и пр. вообще не имеют отладчика. с плагинами базовая система должна иметь отладчик, который показывает пользовательский код. но может скипать код базовой системы. в существующей аксапте, например, так работают методы классов и таблиц, которые находятся в ветке System Documentation. мы видим код бизнес-логики, потом хоп - xRecord, а потом myTable.validationWrite. или наш класс, потом хоп - xInfo, а потом снова выныриваем в другом нашем методе. Примерно так. |
|
28.05.2021, 00:01 | #5 |
Участник
|
Цитата:
Цитата:
Не хочешь видеть чужого кода - не видишь. Хочешь видеть - видишь. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
27.05.2021, 23:53 | #6 |
Участник
|
Цитата:
После чего мы получаем систему со слоями. Преобразовав версию 1 и версию 2 такой системы можно приступать к анализу диффа. Цитата:
TFS (но не GIT).
Для совместимости имхо главное чтобы был понятный контракт. Поставщик должен знать в резльтате каких его действий потребитель сломается, а потребитель знать, что он может использовать. Потребитель, правда, норовит вместо следования предписаниям посмотреть на текущую реализацию и привязаться к ней |
|
28.05.2021, 09:30 | #7 |
Moderator
|
Цитата:
Ну мне кажется что Git слишком гибкий и тяжелый для данной проблемы. На конкретном проекте редко когда больше 5-7 разработчиков работает, редко когда больше двух активных веток разработки ведется, редко когда нет онлайна к репозиторию исходных текстов и тд и тп. В такой ситуации, особых преимуществ Git не дает, а шансов прострелить самому себе ногу - в Git гораздо больше. Идеальным было бы что-то типа TFSVC, но с возможностью импорта diff между двумя версиями как новой ветки. Еще можно было бы подумать на тему, что было бы, если бы система хранения версий знала бы о семантике метаданных и могла бы показывать например разницу между двумя версиями таблицы как "таблицу", но с одним индексом, тремя полями (с разной подсветкой в зависимости от типа изменения) и т.п. Это не стало бы прорывом, но затраты на мерджинг уменьшило бы раза в 2-3. Кроме того - если система версий знает о семантике объектов, то можно было бы сделать какие-то пользовательские расширения, которые например позволяли бы мерджить какие-то типы объектов автоматически, выдывали бы варнинги при всяких сомнительных мерджах и несовместимых изменениях и тд и тп. |
|
28.05.2021, 11:53 | #8 |
Участник
|
Цитата:
Цитата:
Сообщение от fed
А если мы о гипотетической новой системе говорим - так я как раз против плагинов в принципе. Потому что если у нас система расширяется путем создания и редактирования бранчей, то как раз правильнее не создавать точек расширения, делегатов и тд и тп, потому что они как раз снижают шансы найти изменения путем сравнения текстов.
Соответственно вопрос, то, про что ты говоришь - фундаментальное ограничение или недостаток тулинга. В целом согласен. Да, гит сложнее, но его знают больше. Последний раз редактировалось belugin; 28.05.2021 в 11:58. |
|
03.06.2021, 18:46 | #9 |
Участник
|
Давным-давно я работал в проекте разработки учетной системы в одной российской софтверной фирме. Уровень описания прикладной логики там был очень высокий - документ, папка документов, библиотека документов и папок. Она позволяла очень просто реализовывать простые решения, но были существенные проблемы при реализации более тяжелой функциональности. Необходимо было спускаться ближе к системному коду.
В Аксапте, как мне кажется, наоборот, уровень описания слишком низкий - таблица, класс, форма, отчет, специфические сущности.Это по сути высший технологический уровень. Порой не хватало элементов AOT типа справочник, журнал, документ, бизнес-процесс (который потом появился). Мне представляется полезным возможность расширения ядра для возможности реализации системы на том уровне абстракции, который требует прикладной домен, для которого разрабатывается система. И это расширение как раз можно сделать плагинами. |
|
|
За это сообщение автора поблагодарили: Lemming (5). |
04.06.2021, 09:15 | #10 |
Участник
|
Цитата:
Прикладной программист, по сути, превращается в некоего хакера. Пусть к "документу" будет низкоуровневый доступ как к таблице. Но хочется чтобы классы, которые обрабатывают "документы" имели одинаковые внешние точки вызова.Меня именно запутанность и разношерстность классов напрягает. А доступ к документам на уровне таблиц - это как раз преимущество. Даже если брать не Аксапту, а например, сравнить веб-аутлук и майл-ру. В веб-аутлуке все запутано, где-то сообщения снизу вверх идут, где-то сверху вниз. И как-то мало полезной информации на экране, хотя весь экран загроможден чем-то. А в майл-ру с первых же дней использования сразу все понятно. Мне кажется, американские разработчики софта как-то запутались. И странно то, что те разработчики, которые делали удобные инструменты, например Борланд, исчезли. А остались те, которые делают неудобные Я например, в 1989 году не осилил Microsoft MSC, а на Борланд ТурбоВижн написал многооконный текстовый редактор с подсветкой синтаксиса и перекрывающимися окнами в текстовом режиме DOS. А на турбо-ассемблере написал графический редактор с закрашиванием областей. Я 17 лет работаю со всеми версиями Аксапты, и все равно считаю Аксапту парадоксальной. Но такова жизнь Квантовая запутанность, жизнь состоит из парадоксов. И само явление жизни - это чудо. Поэтому я воспринимаю всю эту корявость как должное - просто я попал в ту вселенную, где такая Аксапта. Волновая функция вселенной так чудит.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ Последний раз редактировалось Ace of Database; 04.06.2021 в 09:24. |
|
|
За это сообщение автора поблагодарили: Lemming (5). |