Цитата:
Сообщение от
S.Kuskov
Владимир Максимов, вопрос не в том изучать или не изучать FrameWork, имея базовые знания, а в том можно ли изучать/использовать FrameWork не имея этих самых базовых знаний.
Так я про это и говорю. Факт наличия базовых знаний вне контекста (знания) конкретного FrameWork приводит к очень печальным последствиям. А при наличии знания FrameWork наличие базовых знаний, лежащих в основе этого FrameWork, становится уже не обязательным.
Цитата:
Сообщение от
S.Kuskov
На курсах автомобильного вождения, на теоретических занятиях обязательно касаются устройства автомобиля (основных его систем). Зачем?
Понятия не имею! Вот каким боком знание устройства двигателя внутреннего сгорания поможет Вам в управлении автомобилем?
Цитата:
Сообщение от
oip
Угу. "Старая" Axapta умерла. Создается новая. Происходит смена идеологии самой Axapta. Именно от практиков к теоретикам. Что из этого получится, пока не понятно.
Цитата:
Сообщение от
Vadik
Тот кто видел как в терабайтной БД элементы справочников (клиенты, номенклатуры, основные средства) переименуются при работающих пользователях, в выводах не так котегоричен
Идеология Axapta сама по себе не лишена недостатков. Один из основных - невозможность сброса архива. Выделить в отдельную базу те данные, которые уже не используются в текущей работе. Вот и тащится сзади громадный хвост "мертвых" данных как чемодан без ручки. И нести тяжело и выбросить жалко.
Цитата:
Сообщение от
gl00mie
Чтобы правильно задать вопрос, нужно знать большую часть ответа, чтобы понимать, сделала ли за тебя среда "Б", "В" и "Г", нужно банально про них знать.
В том-то и прелесть, что не надо! Если программирование выполняется в рамках "идеологии" среды, то нужный инструмент окажется создан автоматически вне зависимости от того, используется он или нет. Знает о них разработчик или нет. Все происходит как-бы само по себе. "Автоматически"
Цитата:
Сообщение от
gl00mie
Мне в этом плане вспоминается пример с теми же обработчиками изменения полей.
Это другое. Здесь каждый уровень имеет свой смысл и логику. "Подъем" на следующий уровень происходит "естесственным" путем, как только возникает подозрение на дублирование кода. Если дублирования кода нет, то и смысла переходить на следующий уровень тоже. Не вижу никакого смысла писать код в табличных методах, если обработка требуется только и исключительно при модификации одного объекта формы.
Это похоже на создание иерархии классов не путем предварительного системного анализа, а по мере увеличения функциональности.
Цитата:
Сообщение от
gl00mie
Здесь Джоэль явно не договаривает. Точнее, он опускает "совершенно очевидные" вещи. Очевидные для него.
Ну, вот нашли Вы дырку в абстракции. И что Вы дальше будете делать? А ничего! Вы находитесь не на том "уровне" чтобы исправить эту дырку. Вы можете ее только обойти или смириться с ее существованием. Дырка допущена на этапе разработки ядра FrameWork куда доступа программисту просто нет.
А Джоэль, если я правильно понимаю, находится как раз на том уровне, на котором он может исправить эту дырку. Т.е. на уровне разработки этого самого ядра FrameWork. Именно для него подобные знания необходимы. Но вовсе не для поиска этих самых дыр, а просто как инструмент с которым он и работает.
На языке программистов это уже давно называется либо баг, либо фича. В зависимости от критичности найденной дырки.