|
![]() |
#1 |
Banned
|
|
|
![]() |
#2 |
Чайный пьяница
|
Простите, что влезаю не в свой огород, но в Ax нет такого понятия как статические методы? Сишарпом навеяло, понимаете ли. В шарпе запросто прекрассно статические методы например string.Format и т.п. Так что в данном случае вызвать метод класса - можно, но конечно не класс.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством. Подписывайтесь на мой блог, twitter и YouTube канал. Пользуйтесь моим Ultimate Workflow Toolkit |
|
![]() |
#3 |
Участник
|
Если говорить о чистом кодинге то соглашусь с уважаемым EVGL. Но как только дело касается смежных областей... Все-таки высшая школа необходима имхо. У нас есть программист, не обучавшийся в высшем учебном заведении. Кодит хорошо, но не понимает элементарных вещей, с которыми приходится работать. Например первичный ключ, протокол TCP и прочий базис который дают на любой IT специальности.
|
|
![]() |
#4 |
Участник
|
Цитата:
Что опять таки приводит нас к теории. А хороший программист без понятия первичных ключей, индексов, оптимизации запросов, алгоритмов (любитель вкладывать циклы) - не может быть "хорошим" ![]() Итого, вывод на данный момент из постов выше Высшее образование не показатель, оно просто дает базу и навык учебы. Но освоить все можно и самому, доки, примеры и видеокурсы есть. Вопрос лени и самомотивации ставит планку в развитии специалиста и качестве его кода на выходе. Без индексов и вложенными циклами с кучей статик методов,забыв про ООП, тоже можно кодить и оно будет работать. Вот у меня уже три года не доходят руки (и бюджет на это) переписать некий блок, сделанный спецом, пришедшим в АХ из какой-то процедурной системы, сделанным полностью на статик методах, тк чел так видел мир. |
|
|
За это сообщение автора поблагодарили: EVGL (1). |
![]() |
#5 |
Участник
|
После сообщения BOAL, вспомнил как кто-то из бывших внедренцев (кто? - так и не удалось установить, компанию тоже не упомяну) умудрился включить в состав первичного ключа таблицы InventDim RecId. Зачем? - остается догадкой. Зато это оказалось бомбой замедленного действия. Представляете у вас в этой таблице куча одинаковых комбинацией с разными InventDimId. Представим работу пользователя. Он хочет сделать списание или перенос неважно. Смотрит удобную кнопку в наличии на справочнике номенклатур и видит, что все ок. Пытается разнести журнал - фига с два. Потому что хоть и комбинация аналитик одинаковая - InventDimId - другой. А теперь представьте во скольких местах лежит InventDimId ? А все потому, что кто-то добавил в индекс, который должен быть уникальным в разрезе комбинаций Recid, тем самым косвенно сделав его уникальным только для одной записи. Ужас.
Цитирую слова BOAL : А хороший программист без понятия первичных ключей, индексов, оптимизации запросов, алгоритмов (любитель вкладывать циклы) - не может быть "хорошим"
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
![]() |
#6 |
Участник
|
[OFFTOP]Зачем нужен уникальный index, содержащий RecId?
Возможно он как-раз наоборот слишком много знал ![]() ![]() [/OFFTOP] |
|
|
За это сообщение автора поблагодарили: Pustik (8). |
![]() |
#7 |
Участник
|
если не будет теоретической подготовки у программиста,
то это будет не программист, а кто-то другой. пусть будет слово программолог. он будет подобен химику, не знающему химии, то есть алхимиком астрономом, не знающим астрономии, астрологом. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (1). |
![]() |
#8 |
Участник
|
|
|
![]() |
#9 |
Участник
|
Ассемблер может быть и что-то даст, но вот тут выступает интерес к другой теме, А добавят ли знания первоисточников проффесионализма? Может быть стоит открыть новую ветку? .Лично я не знаю ассемблер, знаю про этот язык в общих чертах. Нужно ли мне его знать? Я знаю точно, что если я ткну пальцем в лежащий на столе предмет, то этот предмет двинется - это раз, двинется в нужном мне направлении это два и т.д. Нужно ли мне знание почему предмет двинулся? Почему в том направлении? Т.е. нужен ли мне переход в более глубокую, подробную область знаний ?
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
|
За это сообщение автора поблагодарили: Gustav (1). |
![]() |
#10 |
Сенбернар
|
Цитата:
Вам лично - не знаю. В среднем - вряд ли И она (ветка) точно так же скатится в оффтоп... Цитата:
Сообщение от Pustik
![]() Лично я не знаю ассемблер, знаю про этот язык в общих чертах. Нужно ли мне его знать? Я знаю точно, что если я ткну пальцем в лежащий на столе предмет, то этот предмет двинется - это раз, двинется в нужном мне направлении это два и т.д. Нужно ли мне знание почему предмет двинулся? Почему в том направлении? Т.е. нужен ли мне переход в более глубокую, подробную область знаний ?
Мой ответ, из опыта, что у мну был - нет категорически.
__________________
Best Regards, Roman |
|
![]() |
#11 |
Участник
|
более простой пример зачем нужна теоретическая подготовка: использование калькулятора, без знания принципов сложения и умножения, бесполезно, разве что орехи колоть
|
|
![]() |
#12 |
Участник
|
Есть даже не анекдот, а быль советских времен. Когда ты приходил в институт, то тебе говорили: Забудь то, чему тебя учили в школе. Когда приходил на работу: Забудь то, чему тебя учили в институте. Не знаю, поменялось ли что-нибудь в этом плане сейчас...
Каждый язык программирования, а в особенности 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. Создателям "ядра" системы. Той области, куда программисту доступ просто запрещен. Даже на "посмотреть". Программист имеет дело уже не с теорией, а с неким продуктом, созданным на основе этой теории. Ну, условно говоря, программист - это водитель автомобиля, а вовсе не механик. Он должен знать правила (приемы) управления автомобилем, а не то, как "расточить гильзы" или "продуть свечи"
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Pustik (5), kALVINS (3). |
![]() |
#13 |
Axapta
|
Цитата:
Сообщение от Владимир Максимов
![]() А что сделали "знатоки теории"? Понадобился первичный ключ? Посмотрим, какое поле подойдет на эту роль? Да вот же оно - RecId. Нужны ссылки на разные таблицы-источники? Да вот же есть TableId.
И что имеем в результате? Постоянные матюки и пожелания самых разных "успехов" тем "умникам", которые сделали связку через RecId+TableId. Никаких тебе "автоматических" "плюшек" в виде "перехода к основной таблице", поиска по ключу на форме и т.д. и т.п. Постоянное программирование, программирование и еще раз программирование. ![]()
__________________
С уважением, Олег. |
|
![]() |
#14 |
Модератор
|
Цитата:
А что сделали "знатоки теории"? Понадобился первичный ключ? Посмотрим, какое поле подойдет на эту роль? Да вот же оно - RecId. Нужны ссылки на разные таблицы-источники? Да вот же есть TableId
Хотя наследование таблиц это конечно та еще песня ![]()
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#15 |
Участник
|
Цитата:
Сообщение от Владимир Максимов
![]() Если разработка происходит как бы "сама по себе". Не успел сказать "А", а среда уже сделала за тебя "Б", "В" и "Г". Значит, программирование идет в согласии с базовой идеей среды разработки. Ты "угадал" то, как "правильно" надо программировать в данной конкретной среде разработки.
Цитата:
![]() Цитата:
Цитата:
Цитата:
![]() Цитата:
|
|
|
За это сообщение автора поблагодарили: Pustik (5), kALVINS (3). |
![]() |
#16 |
Участник
|
Владимир Максимов, вопрос не в том изучать или не изучать FrameWork, имея базовые знания, а в том можно ли изучать/использовать FrameWork не имея этих самых базовых знаний.
На курсах автомобильного вождения, на теоретических занятиях обязательно касаются устройства автомобиля (основных его систем). Зачем? |
|
![]() |
#17 |
Участник
|
Цитата:
Цитата:
Цитата:
Сообщение от oip
![]() В этой связи не могу не вспомнить о axdaily: Surrogate keys in AX 2012. Все течет, все меняется. "Знатоки теории" побеждают.
![]() Цитата:
![]() Цитата:
Цитата:
Это похоже на создание иерархии классов не путем предварительного системного анализа, а по мере увеличения функциональности. Цитата:
Сообщение от gl00mie
![]() Дырявые абстракции зачастую заставляют "лезть под капот"...
Ну, вот нашли Вы дырку в абстракции. И что Вы дальше будете делать? А ничего! Вы находитесь не на том "уровне" чтобы исправить эту дырку. Вы можете ее только обойти или смириться с ее существованием. Дырка допущена на этапе разработки ядра FrameWork куда доступа программисту просто нет. А Джоэль, если я правильно понимаю, находится как раз на том уровне, на котором он может исправить эту дырку. Т.е. на уровне разработки этого самого ядра FrameWork. Именно для него подобные знания необходимы. Но вовсе не для поиска этих самых дыр, а просто как инструмент с которым он и работает. На языке программистов это уже давно называется либо баг, либо фича. В зависимости от критичности найденной дырки.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Pustik (13). |
![]() |
#18 |
Участник
|
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
![]() |
|
|
За это сообщение автора поблагодарили: Pustik (13). |
![]() |
#19 |
Участник
|
Цитата:
Вспомнить хотя бы MDA для Delphi или что-то похожее для Розы! ИМХО архитектор 2012 решил наступить на те же грабли, только сильнее!
__________________
Axapta 3.0 sp - хз какой, kr2 |
|
![]() |
#20 |
Участник
|
Цитата:
Цитата:
1. Системное администрирование чрезвычайно усложняется с ростом базы данных. Банально сделать Backup - крайне сложно. 2. Нерациональное использование дискового пространства. Информация уже не нужна, а место занимает. 3. Значительные проблемы при любой модификации структуры базы данных. Вставить/удалить поле - большая проблема 4. Как уже упоминал Vadik, изменение PK таблиц-справочников также будет выполняться очень долго Ну, отчеты - это отдельный разговор. Ну, не рассчитана Axapta на так любимые в РФ статистические отчеты. Попытка использования стандартных отчетов/классов приводит к глобальному подвешиванию системы на очень длительный срок. Цитата:
Если Вы этого не делаете, то в случае возникновения необходимости в пункте меню "Перейти к основной таблице" необходимо будет перекрывать методы и писать код. Система "тонко намекает", что Вы делаете что-то не то. Что-то, что идет в разрез с ее идеологией. Насчет того, что можно обойтись без программистов я вообще ничего не говорил. В конце концов, а кто же будет делать то самое "А", чтобы появилось "Б", "В" и "Г" ![]() Цитата:
Цитата:
Сообщение от gl00mie
![]() Как минимум можно сообщить разработчику абстракции и получить хорошие шансы на то, что дырка будет им вскоре залатана; если разработчик не будет знать о дыре, очень велика вероятность, что проблема так никуда и не денется.Ну как так... вот, к примеру, падает тот же АОС при выполнении определенного кода, или клиент виснет в каких-то ситуациях, или все работает, но на ровном месте памяти отжирается невообразимо много... Пусть проблема в АОСе/клиенте/виндах/еще ком-то - но это же не значит, что ее не надо пытаться решать или хотя бы пытаться смягчить ее проявления? Деньги-то не за то платят, чтобы руки разводить и говорить "я не на том уровне"
![]() 1. Нашли дырку в абстракции 2. Сообщили разработчику Наши дальнейшие действия? Сидим, ждем выхода следующего релиза или фикса? И сколько ждать? А программа не работает! А деньги нам за что платят? Что делает разработчки в этом случае? Ищет пути обхода. На своем уровне. А вовсе не на уровне дырки в абстракции. Тормозит Exists Join? Делаем Inner Join. Базовый класс сжирает всю память? Используем временные таблицы. И т.д. и и.п. В результате имеем решение проблемы вообще никак не связанное с осознанием причины "дырки в абстракции". Мы просто знаем, что "Ты туда не ходи. Снег башка попадет" (с). Ну, и протаптываем "обходные пути" ![]() Кроме того, для информирования разработчика вообще-то не нужно знать причину ошибки. Знать какая там "дырка в абстракции". Вполне достаточно по шагам описать свои действия, которые привели к этой ошибке. Тем более далеко не факт, что угадали верно. Мы видим только результат, а о точной причине можем лишь догадываться.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|