Нужна ли теоретическая подготовка при программировании в Axapta?

[S.Kuskov]

Владимир Максимов, вопрос не в том изучать или не изучать FrameWork, имея базовые знания, а в том можно ли изучать/использовать FrameWork не имея этих самых базовых знаний.

Цитата:

Сообщение от Владимир Максимов

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

На курсах автомобильного вождения, на теоретических занятиях обязательно касаются устройства автомобиля (основных его систем). Зачем?

[Владимир Максимов]

Цитата:

Сообщение от S.Kuskov

Владимир Максимов, вопрос не в том изучать или не изучать FrameWork, имея базовые знания, а в том можно ли изучать/использовать FrameWork не имея этих самых базовых знаний.

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

Цитата:

Сообщение от S.Kuskov

На курсах автомобильного вождения, на теоретических занятиях обязательно касаются устройства автомобиля (основных его систем). Зачем?

Понятия не имею! Вот каким боком знание устройства двигателя внутреннего сгорания поможет Вам в управлении автомобилем?

Цитата:

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

В этой связи не могу не вспомнить о axdaily: Surrogate keys in AX 2012. Все течет, все меняется. "Знатоки теории" побеждают.

Угу. "Старая" Axapta умерла. Создается новая. Происходит смена идеологии самой Axapta. Именно от практиков к теоретикам. Что из этого получится, пока не понятно.

Цитата:

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

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

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

Цитата:

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

Чтобы правильно задать вопрос, нужно знать большую часть ответа, чтобы понимать, сделала ли за тебя среда "Б", "В" и "Г", нужно банально про них знать.

В том-то и прелесть, что не надо! Если программирование выполняется в рамках "идеологии" среды, то нужный инструмент окажется создан автоматически вне зависимости от того, используется он или нет. Знает о них разработчик или нет. Все происходит как-бы само по себе. "Автоматически"

Цитата:

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

Мне в этом плане вспоминается пример с теми же обработчиками изменения полей.

Это другое. Здесь каждый уровень имеет свой смысл и логику. "Подъем" на следующий уровень происходит "естесственным" путем, как только возникает подозрение на дублирование кода. Если дублирования кода нет, то и смысла переходить на следующий уровень тоже. Не вижу никакого смысла писать код в табличных методах, если обработка требуется только и исключительно при модификации одного объекта формы.

Это похоже на создание иерархии классов не путем предварительного системного анализа, а по мере увеличения функциональности.

Цитата:

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

Дырявые абстракции зачастую заставляют "лезть под капот"...

Здесь Джоэль явно не договаривает. Точнее, он опускает "совершенно очевидные" вещи. Очевидные для него.

Ну, вот нашли Вы дырку в абстракции. И что Вы дальше будете делать? А ничего! Вы находитесь не на том "уровне" чтобы исправить эту дырку. Вы можете ее только обойти или смириться с ее существованием. Дырка допущена на этапе разработки ядра FrameWork куда доступа программисту просто нет.

А Джоэль, если я правильно понимаю, находится как раз на том уровне, на котором он может исправить эту дырку. Т.е. на уровне разработки этого самого ядра FrameWork. Именно для него подобные знания необходимы. Но вовсе не для поиска этих самых дыр, а просто как инструмент с которым он и работает.

На языке программистов это уже давно называется либо баг, либо фича. В зависимости от критичности найденной дырки.

[gl00mie]

Цитата:

Сообщение от Владимир Максимов

Вот каким боком знание устройства двигателя внутреннего сгорания поможет Вам в управлении автомобилем?

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

Цитата:

Сообщение от Владимир Максимов

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

Какие, например? Накладные, проводки по клиентам/поставщикам/номенклатуре? Идеология системы предусматривает активную работу только с текущим, образно говоря, рабочим набором данных: открытыми проводками либо проводками только в открытых периодах, не полностью отгруженными заказами, ненулевыми остатками в наличии, etc. Проблемы обычно возникают из-за некорректных модификаций, когда становится невозможно удалять разнесенные журналы и те же полностью отгруженные заказы или когда что-то считается с начала времен.

Цитата:

Сообщение от Владимир Максимов

Если программирование выполняется в рамках "идеологии" среды, то нужный инструмент окажется создан автоматически вне зависимости от того, используется он или нет. Знает о них разработчик или нет. Все происходит как-бы само по себе. "Автоматически"

Утопия! О таких волшебных средах/framework'ах мечтали в свое время разработчики CASE-систем, но все равно оказалось, что без программистов не обойтись...

Цитата:

Сообщение от Владимир Максимов

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

Надеюсь, этот пассаж про смешение презентационной и безнес-логики был лишь стёбом...

Цитата:

Сообщение от Владимир Максимов

Ну, вот нашли Вы дырку в абстракции. И что Вы дальше будете делать? А ничего! Вы находитесь не на том "уровне" чтобы исправить эту дырку.

Как минимум можно сообщить разработчику абстракции и получить хорошие шансы на то, что дырка будет им вскоре залатана; если разработчик не будет знать о дыре, очень велика вероятность, что проблема так никуда и не денется.

Цитата:

Сообщение от Владимир Максимов

Вы можете ее только обойти или смириться с ее существованием.

Ну как так... вот, к примеру, падает тот же АОС при выполнении определенного кода, или клиент виснет в каких-то ситуациях, или все работает, но на ровном месте памяти отжирается невообразимо много... Пусть проблема в АОСе/клиенте/виндах/еще ком-то - но это же не значит, что ее не надо пытаться решать или хотя бы пытаться смягчить ее проявления? Деньги-то не за то платят, чтобы руки разводить и говорить "я не на том уровне"

[egorych]

Цитата:

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

Утопия! О таких волшебных средах/framework'ах мечтали в свое время разработчики CASE-систем, но все равно оказалось, что без программистов не обойтись...

+100500 !!!
Вспомнить хотя бы MDA для Delphi или что-то похожее для Розы!
ИМХО архитектор 2012 решил наступить на те же грабли, только сильнее!

[Владимир Максимов]

Цитата:

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

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

И как это поможет преодолеть проблему? Цель - беспроблемная езда. Тот факт, что я знаю из-за чего возникает проблема никак не помогает мне ехать.

Цитата:

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

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

Да. И в этом ее недостаток.

1. Системное администрирование чрезвычайно усложняется с ростом базы данных. Банально сделать Backup - крайне сложно.
2. Нерациональное использование дискового пространства. Информация уже не нужна, а место занимает.
3. Значительные проблемы при любой модификации структуры базы данных. Вставить/удалить поле - большая проблема
4. Как уже упоминал Vadik, изменение PK таблиц-справочников также будет выполняться очень долго

Ну, отчеты - это отдельный разговор. Ну, не рассчитана Axapta на так любимые в РФ статистические отчеты. Попытка использования стандартных отчетов/классов приводит к глобальному подвешиванию системы на очень длительный срок.

Цитата:

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

Утопия! О таких волшебных средах/framework'ах мечтали в свое время разработчики CASE-систем, но все равно оказалось, что без программистов не обойтись...

Если Вы делаете PK на основании EDT и устанавливаете Relation, то такой пункты меню, как "Перейти к основной таблице" появляется как бы "автоматически". Вы ничего для этого специально не делаете. Вы можете ничего не знать, про факт существования такого пункта меню, но он все равно появится вне зависимости от Вашего знания.

Если Вы этого не делаете, то в случае возникновения необходимости в пункте меню "Перейти к основной таблице" необходимо будет перекрывать методы и писать код. Система "тонко намекает", что Вы делаете что-то не то. Что-то, что идет в разрез с ее идеологией.

Насчет того, что можно обойтись без программистов я вообще ничего не говорил. В конце концов, а кто же будет делать то самое "А", чтобы появилось "Б", "В" и "Г"

Цитата:

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

Надеюсь, этот пассаж про смешение презентационной и безнес-логики был лишь стёбом...

Здесь непонимание с обеих сторон. Вы не поняли о чем я говорил, а я не понял какое отношение Ваш пример имеет к моим словам. О чем шла речь я пояснил чуть выше на примере появления пункта меню.

Цитата:

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

Как минимум можно сообщить разработчику абстракции и получить хорошие шансы на то, что дырка будет им вскоре залатана; если разработчик не будет знать о дыре, очень велика вероятность, что проблема так никуда и не денется.Ну как так... вот, к примеру, падает тот же АОС при выполнении определенного кода, или клиент виснет в каких-то ситуациях, или все работает, но на ровном месте памяти отжирается невообразимо много... Пусть проблема в АОСе/клиенте/виндах/еще ком-то - но это же не значит, что ее не надо пытаться решать или хотя бы пытаться смягчить ее проявления? Деньги-то не за то платят, чтобы руки разводить и говорить "я не на том уровне"

Замечательно. Разбираем по пунктам

1. Нашли дырку в абстракции
2. Сообщили разработчику

Наши дальнейшие действия? Сидим, ждем выхода следующего релиза или фикса? И сколько ждать? А программа не работает! А деньги нам за что платят?

Что делает разработчки в этом случае? Ищет пути обхода. На своем уровне. А вовсе не на уровне дырки в абстракции. Тормозит Exists Join? Делаем Inner Join. Базовый класс сжирает всю память? Используем временные таблицы. И т.д. и и.п.

В результате имеем решение проблемы вообще никак не связанное с осознанием причины "дырки в абстракции". Мы просто знаем, что "Ты туда не ходи. Снег башка попадет" (с). Ну, и протаптываем "обходные пути"

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

[ice]

Цитата:

Сообщение от Владимир Максимов

Если Вы делаете PK на основании EDT и устанавливаете Relation, то такой пункты меню, как "Перейти к основной таблице" появляется как бы "автоматически". Вы ничего для этого специально не делаете. Вы можете ничего не знать, про факт существования такого пункта меню, но он все равно появится вне зависимости от Вашего знания.

Если Вы этого не делаете, то в случае возникновения необходимости в пункте меню "Перейти к основной таблице" необходимо будет перекрывать методы и писать код. Система "тонко намекает", что Вы делаете что-то не то. Что-то, что идет в разрез с ее идеологией.

не совсем верно. знание, что можно настроить релейшн на EDT с неба не падают, это фича системы. причем настоев EDT на новую таблицу мы не получим автоматический переход к основной таблице,поле в таблице должно быть ключем, в таблице необходимо заполнить свойство FormRef, для заполнения которого нужен MenuItem, ссылающийся на форму с той самой таблицей, причем датасорс с таблицей должен быть главным на этой форме, таким образом, все таки приестся после "А", сделать и "Б", "В" и тд