Драконограф писал(а):
alexus писал(а):
Вот, собственно, и вся история... и никакого рефакторинга...
Верно я понимаю, что:
* метаметафорой замены рефакторинга является: "каждой предметке - правильную её схему";
* задача программистов - создавать средство работы со схемами предметок
?
Вопросы... "не в бровь, а в глаз"...
Задача программистов состоит в программировании. Формирование моделей задача аналитиков, а проектировщики должны... конечно... проектировать. У каждой предметной области, несомненно, должна быть "правильная схема". (Вопрос в том, какую схему считать правильной?) Программисты должны стараться создавать качественные инструменты в тех случаях, когда речь идёт о том, что предметную область невозможно или не нужно/бесполезно (как в приведённом случае) формализовать.
Драконограф писал(а):
Под "правильной" понимается схема, которую предметник может преобразовывать наиболее естественно - следовательно, можно переложить на него эту работу. Тогда язык схемы - результат информатизации языка предметки - т.е. DSL. Он включает лексику, передающую "вещи предметки и отношения между вещами - и м.б. отношения между отношениями" и правила употребления лексики для составления схем.
В примере просто устранялось "лишнее звено" - программисты, при решении конкретной задачи. Программисты занимались развитием инструмента.
Что понимается под "правильной схемой"?.. Схема/модель должна быть, как и любая другая модель, адекватной предметной области. ... Нет, решил удалить дальнейшие комментарии... если у форумчан не сложилось понимание того, чем отличается "рефакторинг" от "развития", то говорить о более "тонких материях" смысла не имеет. Может быть потом...
Драконограф писал(а):
Понятно, что "схема" - термин условный по отношению к форме записи. Это м.б. графы, изображения, тексты, таблицы в различных сочетаниях (но алгоритмически формируемых).
Да, конечно. Изображение (проекция модели) должно быть понятным, а, следовательно, "изображать" надо понятными/принятыми в данной предметной области средствами/языками/образами.
Драконограф писал(а):
А развитие системы (разработчиками-программистами) в основном есть выявление сущностей/отношений предметки, операций над ними и закладка этого в программу - редактор/транслятор схем. Наряду с этим - конечно, отработка операций программы (над схемами и вспомогательных) и оптимальное их включение в операторский интерфейс.
Нет, это уже следствия. Развитие должно опираться на "правильную схему/модель"... иначе неизбежно вернёмся к рефакторингу (переделки то в одном месте, то в другом). Так вот... "выявление сущностей/отношений предметки, операций над ними" - это относится к получению "правильной модели", но не её развитию.
Драконограф писал(а):
Короче, всё, что перечислено Вами в
этом посте как шаги 1...6, делается только по вышеперечисленным поводам - а не по поводу конкретных задач предметников. Отсюда сосредотачиваемся на модели (информатической, а значит до этого/вместе с этим - математической и качественной) предметки в целом. Т.е. на "возможных/допустимых вещах и отношениях" - а не на "существующих/мыслимых задачах" - что есть дело аналитика, работающего в т.ч. и с данными эксплуатации среды. И тогда проще аналитику и программисту. Так?
Нет. Общее движение (аналитика, проектировщика, программиста) должно происходить от семантики в сторону насыщения/многообразия форм, а не от ошибок и недочётов (в модели/проектной документации/коде) к их исправлению. Исходная мысль здесь: "смысл всегда прост, трудно даётся его обретение". Ладно... я, кажется, опять увлёкся "тонкими материями"... Напрасно...
Драконограф писал(а):
В Вашем примере за правильную схему была принята метафора динамической (распространяющей <вычисления согласно зависимостям формул>, жарг. "электронной") таблицы.
Нет, основа в данной задаче ФОРМУЛА. Всё остальное "крутится" вокруг этого "центрального" понятия.
Драконограф писал(а):
Каковая на самом деле играла роль предметно-естественной формы определения параметров запросов к СУБД - как для манипулирования данными, так и для их расчётно-логических преобразований. Верно?
См. выше. (в конечном итоге данные брались не только из БД, но и других источников, от пользователей, например, в интерактивном режиме, из реальных электронных таблиц и пр.).
Драконограф писал(а):
А перейди мы к другой "предметке" - и понадобится новая метафора, новый язык - что оформляется как "домайно-специфичный плагин" над ядром (в данном случае - приложением СУБД)... isn't it?..
Разумеется.
Драконограф писал(а):
И ещё - логика подсказывает, что должна существовать "самая правильная схема" - т.е. инвариант всех мыслимых предметок.
Это неформально... можно понимать двояко... Например так, есть некоторая супер-модель ("правильная схема"), которая включает в себя все модели ("схемы"). Эта "супер-модель" является собирательным образом и постоянно дополняется новыми моделями (схемами). А можно так, супер-модель, проецируется на разные области, и поэтому она не является собирательным образом, а является про-образом тех образов-моделей, которые являются её проекциями на предметные области. Это два принципиально разных... взгляда/подхода... Первый путь объясняет рефакторинг, второй его вредность. И то, и другое... "тонкие материи"... Тьфу на них...
Драконограф писал(а):
На её базе выстраивается "домайная специфика" для каждой очередной предметки, добавляемой в список поддерживаемых в конкретной оргсистеме-эксплуатанте такого решения. Ещё и потому, что предметки м.б. не независимы - и тогда надо добавлять как "гибрид ужа с ежом" (а также лебедем, раком, щукой etc... только это не ирония над Вашим подходом, а художественно-наглядное обозначение проблем масштабирования решения - возможно, Вы уже знакомы с ними). При этом каждый раз имея инвариант как отправную точку - чтобы действительно всё не переделывать.
См. выше.
Драконограф писал(а):
Интуитивно из Ваших предыдущих рассуждений я понял, что схема-инвариант Вами представляется как модель трактов переработки оргсистемы (её выделенной части). Что и отразил в
этом посте. Что-то можете сказать по этому поводу?
Я читал... честно... но ничего не понял... (второй раз промолчу).