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

[a33ik]

Простите, что влезаю не в свой огород, но в Ax нет такого понятия как статические методы? Сишарпом навеяло, понимаете ли. В шарпе запросто прекрассно статические методы например string.Format и т.п. Так что в данном случае вызвать метод класса - можно, но конечно не класс.

[S.Kuskov]

Цитата:

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

в Ax нет такого понятия как статические методы?

Есть конечно.
Вообще говоря в аксапте можно и класс "вызвать". Т.е. есть поддерживаемая ядром точка входа в класс в виде статического метода с зарезервированным именем "main". Именно через него происходит связь menuitem с классом.

[Deepoint]

Если говорить о чистом кодинге то соглашусь с уважаемым EVGL. Но как только дело касается смежных областей... Все-таки высшая школа необходима имхо. У нас есть программист, не обучавшийся в высшем учебном заведении. Кодит хорошо, но не понимает элементарных вещей, с которыми приходится работать. Например первичный ключ, протокол TCP и прочий базис который дают на любой IT специальности.

[Pustik]

Цитата:

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

Есть конечно.
Вообще говоря в аксапте можно и класс "вызвать". Т.е. есть поддерживаемая ядром точка входа в класс в виде статического метода с зарезервированным именем "main". Именно через него происходит связь menuitem с классом.

Самое важное в этой области. Еще и кучу параметров может принять.

[BOAL]

Цитата:

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

Например первичный ключ, протокол TCP и прочий базис который дают на любой IT специальности.

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

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

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

[Pustik]

После сообщения BOAL, вспомнил как кто-то из бывших внедренцев (кто? - так и не удалось установить, компанию тоже не упомяну) умудрился включить в состав первичного ключа таблицы InventDim RecId. Зачем? - остается догадкой. Зато это оказалось бомбой замедленного действия. Представляете у вас в этой таблице куча одинаковых комбинацией с разными InventDimId. Представим работу пользователя. Он хочет сделать списание или перенос неважно. Смотрит удобную кнопку в наличии на справочнике номенклатур и видит, что все ок. Пытается разнести журнал - фига с два. Потому что хоть и комбинация аналитик одинаковая - InventDimId - другой. А теперь представьте во скольких местах лежит InventDimId ? А все потому, что кто-то добавил в индекс, который должен быть уникальным в разрезе комбинаций Recid, тем самым косвенно сделав его уникальным только для одной записи. Ужас.
Цитирую слова BOAL : А хороший программист без понятия первичных ключей, индексов, оптимизации запросов, алгоритмов (любитель вкладывать циклы) - не может быть "хорошим"

[S.Kuskov]

[OFFTOP]

Цитата:

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

Зачем?

Зачем нужен уникальный index, содержащий RecId?
Возможно он как-раз наоборот слишком много знал и немножко перемудрил
[/OFFTOP]

[veps]

если не будет теоретической подготовки у программиста,
то это будет не программист, а кто-то другой. пусть будет слово программолог.
он будет подобен
химику, не знающему химии, то есть алхимиком
астрономом, не знающим астрономии, астрологом.

[S.Kuskov]

Программолог - суппер определение!

Слой магии

[RVS]

Цитата:

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

Можно пойти еще дальше и сказать, что каждому надо поработать с ассемблером, чтобы понять, как на самом деле исполняется код.

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

Задача была - шифровка/дешифровка данных on fly. То есть - в базе лежит полная... хрень, а прога видит все, как надо..

Цитата:

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

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

"Это вряд ли" (с) Сухов, "Белое солнце пустыни".

Потому как "программистов" Axapta - не бывает. Это... гм... программирующие консультанты скорее. IMHO.

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

Повторюсь : водитель авто _обязан_ знать ПДД.

[Pustik]

Ассемблер может быть и что-то даст, но вот тут выступает интерес к другой теме, А добавят ли знания первоисточников проффесионализма? Может быть стоит открыть новую ветку? .Лично я не знаю ассемблер, знаю про этот язык в общих чертах. Нужно ли мне его знать? Я знаю точно, что если я ткну пальцем в лежащий на столе предмет, то этот предмет двинется - это раз, двинется в нужном мне направлении это два и т.д. Нужно ли мне знание почему предмет двинулся? Почему в том направлении? Т.е. нужен ли мне переход в более глубокую, подробную область знаний ?

[RVS]

Цитата:

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

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

Да не уперлось ничто... в ассемблер... был пример, не слишком, имхо, удачный... "Доведение до абсурда", типа

Цитата:

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

А добавят ли знания первоисточников проффесионализма?

Вам лично - не знаю. В среднем - вряд ли

Цитата:

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

Может быть стоит открыть новую ветку? .

И она (ветка) точно так же скатится в оффтоп...

Цитата:

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

Лично я не знаю ассемблер, знаю про этот язык в общих чертах. Нужно ли мне его знать? Я знаю точно, что если я ткну пальцем в лежащий на столе предмет, то этот предмет двинется - это раз, двинется в нужном мне направлении это два и т.д. Нужно ли мне знание почему предмет двинулся? Почему в том направлении? Т.е. нужен ли мне переход в более глубокую, подробную область знаний ?

Речь, как мну кажется, была вот о чем : можно ли человеку, не знающему основ, и при этом - "желающему странного" - доверять программирование в ERP-системе.

Мой ответ, из опыта, что у мну был - нет категорически.

[ice]

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

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

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

Каждый язык программирования, а в особенности FrameWork (чем является Axapta), в своей основе имеют некую идею того, как "правильно" надо программировать. Все конструкции языка "затачиваются" под эту идеологию. К сожалению, я не встречал чтобы кто-нибудь, когда-нибудь, озвучивал эту самую идеологию конкретной среды программирования. Однако ее можно почувствовать по косвенным признакам.

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

Разумеется, есть Best Practices, но это не совсем то. Точнее, это слишком "низкий" уровень абстракции. Нужно подняться чуть выше

Пример. Первичный ключ. Основа основ реляционной базы данных. Какая идея (по моим предположениям) была положена в основу реализации связи PK-FK? Показательным примером может служить цепочка: Шапка заказа - строки заказа - складские проводки.

Идея звучит так: Если Вам нужен первичный ключ, то Вы создаете (!) новое поле и формируете его значение по-умолчанию на основе номерной серии. Пример: SalesId, InventTransId.

Если Вам нужен внешний ключ, исходя из предположения, что таблица может быть связана с несколькими таблицами-родителями, то в качестве идентификатора таблицы-родителя Вы создаете (!) новый Base Enum. Пример: TransType + TransRefId в складских проводках.

А что сделали "знатоки теории"? Понадобился первичный ключ? Посмотрим, какое поле подойдет на эту роль? Да вот же оно - RecId. Нужны ссылки на разные таблицы-источники? Да вот же есть TableId.

И что имеем в результате? Постоянные матюки и пожелания самых разных "успехов" тем "умникам", которые сделали связку через RecId+TableId. Никаких тебе "автоматических" "плюшек" в виде "перехода к основной таблице", поиска по ключу на форме и т.д. и т.п. Постоянное программирование, программирование и еще раз программирование.

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

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

Смотрим на классы. Насколько я понимаю, предполагалось, что "точкой входа" в любой класс в Axapta должен быть статический метод main(). Это, в свою очередь, предполагает, что при программном вызове класса необходима предварительная подготовка по формированию параметра args. Причем объект args имеет входные параметры в методе new().

А что в результате сделали знатоки "теории"? Про метод main() они узнают только тогда, когда оказывается невозможным привязать класс к пункту меню. Никто и никогда не инициализирует объект args (если вообще про него вспоминают) передавая в метод new() параметры. В общем случае, найти в коде, каким же образом инициализируется и запускается тот или иной класс - это всегда проблема. Каждый разработчик выдумывает что-то свое. Особенное. В соответствии со своим пониманием того, "как правильно".

Знание теории, откровенно мешает "правильному" программированию с точки зрения конкретного FrameWork. "Теоретик" все время пытается сделать "по теории", а не так, как это предполагает конкретный FrameWork. В результате, просто "ломает об колено" среду разработки.

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

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

[S.Kuskov]

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

Цитата:

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

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

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

[oip]

Цитата:

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

А что сделали "знатоки теории"? Понадобился первичный ключ? Посмотрим, какое поле подойдет на эту роль? Да вот же оно - RecId. Нужны ссылки на разные таблицы-источники? Да вот же есть TableId.

И что имеем в результате? Постоянные матюки и пожелания самых разных "успехов" тем "умникам", которые сделали связку через RecId+TableId. Никаких тебе "автоматических" "плюшек" в виде "перехода к основной таблице", поиска по ключу на форме и т.д. и т.п. Постоянное программирование, программирование и еще раз программирование.

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

[Vadik]

Цитата:

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

"Знатоки теории" побеждают.

Цитата:

А что сделали "знатоки теории"? Понадобился первичный ключ? Посмотрим, какое поле подойдет на эту роль? Да вот же оно - RecId. Нужны ссылки на разные таблицы-источники? Да вот же есть TableId

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

[gl00mie]

Цитата:

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

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

Чтобы правильно задать вопрос, нужно знать большую часть ответа, чтобы понимать, сделала ли за тебя среда "Б", "В" и "Г", нужно банально про них знать. Мне в этом плане вспоминается пример с теми же обработчиками изменения полей. Начинающих программистов тянет напихать их на форму, кому-то хватает ума перекрывать modified() на поле datasource'а, а не на контроле - если он, к примеру, слышал про пользовательскую настройку форм и возможность добавления новых контролов, связанных с одним и тем же полем. Следующим шагом идет вынос логики в modifiedField() таблицы - это уже очень большое достижение. Но потом возникает, скажем, задача при изменении определенных полей в шапке пробрасывать их в строки - и там подтягивать связанные значения полей. Хм, это уже интереснее, потому что пробрасываться могут значения сразу нескольких полей; подождите-ка, где-то это уже было... А, в заказах же такое сделано! Сейчас посмотрим, как именно... Опа! а там, оказывается, какие-то непонятные ax-классы с вывернутой наизнанку логикой, и выходит, все потуги выноса кода в modifiedField() таблицы пошли прахом... По-моему, невозможно такое угадать, не может это прийти "само по себе": про такие вещи либо знаешь и заранее готовишься к ним, либо не знаешь и потом "огребаешь" в один прекрасный день, а до того дня среда никак тебе не намекнет, что все на самом деле надо делать по-другому.

Цитата:

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

Насколько я понимаю, предполагалось, что "точкой входа" в любой класс в Axapta должен быть статический метод main().

По-моему, разработчики Х++ просто слишком увлекались Java

Цитата:

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

А что в результате сделали знатоки "теории"? Про метод main() они узнают только тогда, когда оказывается невозможным привязать класс к пункту меню.

Точно помню, что в экзамене Development Introduction есть такой вопрос. Если знатоки "теории" не сдавали базовые экзамены, зачем допускать их к разработке?..

Цитата:

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

Никто и никогда не инициализирует объект args (если вообще про него вспоминают) передавая в метод new() параметры.

Сама по себе идея Args как универсального "транспорта" для передачи (фиксированного перечня) параметров вызываемому объекту приложения имеет свои ограничения, которые наиболее ярко проявляются как раз-таки в классах. Где-то числовые параметры передаются через строковый parm(), а где-то и вовсе через parmObject() передается ссылка на объект со всей необходимой информацией, которую не удалось "запихнуть" в свойства Args. К тому же, для наследников RunBase метод main() традиционно вызывает prompt(), который при вызове класса из кода оказывается ну совсем не кстати, поэтому в коде вызовы main(args) класса скорее - дурной тон (если уж надо что-то интерактивное запустить, для этого есть MenuFunction).

Цитата:

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

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

Если разработчик не пренебрегает модификаторами доступа (public/protected/private) и придерживается контрактного подхода, то обычно все не так плохо

Цитата:

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

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

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

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

Цитата:

Сообщение от 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-систем, но все равно оказалось, что без программистов не обойтись...

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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