ERP программисту якобы важнее знания бизнес-процессов

[ax_mct]

Цитата:

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

Если оговорены типы то можно без дополнительных переменных.

static void swapExample(Args _args)
{
    container   swap(int _a, int _b)
    {
        int     a = _a;
        int     b = _b;
        ;
                   // a == _a;       b == _b;  
        a = a + b; // a == _a + _b;  b == _b;
        b = b - a; // a == _a + _b;  b == -_a;
        a = a + b; // a ==      _b;  b == -_a;
        b =    -b; // a ==      _b;  b ==  _a;
        
        info(con2Str([_a, _b, "       ", a, b]));
        
        return [a, b];
    }
    ;
    
    swap(1, 2);
    swap(1, 20);
}

Кстати, использование стека, это по сути и есть дополнительные переменные. Просто синтаксис другой. Все переменные как правило на стеке живут или в куче.

Цитата:

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

Стек я ему предложил на бумаге написать, чтобы проще было отлаживать, он там всю высшую математику вспомнил, а всё никак.

Цитата:

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

Да - это нормальный ответ для собеседования!

Цитата:

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

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

1. Она годится чтобы оценить гибкость ума и "соображалистость" студента, которого берут как стажера.

2. Вам же как я понимаю нужен чел с неким опытом и лучше в области ERP систем. - Там совсем другие шаблоны мысли. И главное это опыт и знание бизнеспроцессов и жизненных ситуация по применению ERP систем. Эта задачка никак тут не помогает.

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

....

Цитата:

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

Originally Posted by DesparioN View Post

Первичный анализ показал, что форма заказа на покупку:
1) при открытии затрачивает 10 секунд
2) при первом executeQuery 2 мин
3) при последующих 10-15 секунд.

Это к вопросу о том, что ERP программисту якобы важнее знания бизнес-процессов, а не программирования.

Цитата:

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

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

Ну а понимание бизнес-процессов, оно как коньяк - всегда полезно

[ax_mct]

Цитата:

И главное это опыт и знание бизнеспроцессов и жизненных ситуация по применению ERP систем

Абсолютно согласен с этим высказыванием.
Но потом Logger как-то сдался

Открытие формы это не сортировка пузырьком и особенности выделения памяти.
Это никак не отменяет того что уровень чисто классической программистской квалификации у нас паралелен успеху и карьере в ERP, и именно функциональные знания являются главными.

Попросту говоря тип VB/Access программиста который общается на одном языке с бизнесом более востребован рынком в нашей специальности. И именно знания бизнес-процессов являются главными и более важными.

[fed]

Я бы сформулировал это так: при найме на работу новичка, полезно проверить что он знает и понимает стандартные алгоритмы. Просто при найме на работу меня, или Logger или ax_mct можно поговорить про опыт в реальных проектах и понять уровень. При найме новичка такой возможности нет. Но если новичек понимает некоторое количество стандартных алгоритмов, значит он в целом имеет способности к программированию и его можно нанимать.

Такое внимание к соревновательному программированию объясняется тем, что эти вопросы любят задавать при приеме на работу в Google/Amazon/Facebook и тд. И задают эти вопросы по той же самой причине: Они там работают с уникальными для своей компани задачами, поэтому предыдущий опыт нанимаемого не особо показателен. (Все таки не так много компаний продукты масштаба facebook или gmail разрабатывают).
Ну а что случается, когда разработкой D365FO в Микрософте занимаются люди с опытом быстрой сортировки и обхода графа, но без минимального опыта бизнес-программирования, мы видим каждый день

[ax_mct]

Цитата:

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

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

А если действительно именно про тех кто уже работает?

То есть не про проверку знаний принципов работы двигателя внутреннего сгорания при допуске к работе, а про тех кто уже за рулем? Знание дороги куда важнее.

Сугубо техническая задача из той темы.
Предназначенная для программиста.

Цитата:

Первичный анализ показал, что форма заказа на покупку:
1) при открытии затрачивает 10 секунд
2) при первом executeQuery 2 мин
3) при последующих 10-15 секунд.

Отсюда:
Кэширование данных на форме (DAX2012)

Какие именно навыки программирования здесь применяет программист AX при решении этой задачи? Да, никаких на самом деле.

Много здесь тех кто пишет как кодер по техзаданию? Думаю что 90% ценны именно знанием системы и опытом, а не тем понимают ли они что такое делегаты или контроллеры/контракты в коде приложения.

То есть утверждение что

Цитата:

И главное это опыт и знание бизнеспроцессов и жизненных ситуация по применению ERP систем

абсолютно верно для программиста AX/365.

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

[fed]

Цитата:

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

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

Ну - если ты студента после универа нанимаешь, то вряд ли у него знание реального бизнеса есть.
Хотя да - в целом мысль понятна. Люди которые в институте на разработчика-технаря учились, вряд ли в ERP бизнес придут. А люди, которые учились технической кибернетике или чему-то подобному вряд ли очень глубоко алгоритмы изучали.

[Raven Melancholic]

Цитата:

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

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

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

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

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

Народ, вы опять путаете понятия. Только теперь уже с другой стороны

Есть разные задачи

• "Абстрактное" программирование не связанное с конкретным приложением
• Программирование в рамках FrameWork конкретного приложения
• Обсуждение постановки задачи и консультирование пользователя

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

То, чем занимаются разработчики Axapta - это программированием в рамках конкретного FrameWork. И здесь не требуется ни знания "абстрактного" программирования, ни знания бизнес-процессов. Здесь требуется знание этого самого FrameWork.

А знания бизнес-процессов требуются когда Вы начинаете общаться с пользователем. Но какое это имеет отношение к собственно написанию кода? Тут консультанта в пару к разработчику будет достаточно.

[sukhanchik]

Цитата:

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

Люди которые в институте на разработчика-технаря учились, вряд ли в ERP бизнес придут. А люди, которые учились технической кибернетике или чему-то подобному вряд ли очень глубоко алгоритмы изучали.

Суть понятна, но фраза не очень корректна. Но сформулировать лучше не могу .
Дело в том, что под одними и теми же фразами в разных учебных заведениях могут понимать совершенно разные понятия. Ну и дисциплины разные. Лично мне были гораздо интереснее дисциплины разработчика-технаря (базы данных, SQL-запросы, разные языки программирования), но в ERP-бизнес я попал практически сразу, совершенно случайно (так вакансия сложилась). А вот на кафедре кибернетики у нас народ изучал всякие графы, алгоритмы построения оптимального пути и т.д. Меня это тоже коснулось - но я для себя другой акцент поставил в дисциплинах. При этом некоторые мои коллеги, которые больше отдали времени графам и теории управления - также пошли в ERP-бизнес и эти графы им может и пригодились, но ни разу не сразу (даже начинающие консультанты графы не строят, а уж начинающие разработчики - тем более). А вот необходимость составлять по постановке задачи SQL-запрос - пригодилась всем и сразу.
А другой мой коллега - оставил эти алгоритмы в покое и пошел в изучение "железок" и удалился от ERP-бизнеса в принципе.

Так что тут сильно зависит всё от интересов конкретного человека и чем он заинтересовался на своих первых работах.

[ax_mct]

Цитата:

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

То, чем занимаются разработчики Axapta - это программированием в рамках конкретного FrameWork. И здесь не требуется ни знания "абстрактного" программирования, ни знания бизнес-процессов. Здесь требуется знание этого самого FrameWork.

А знания бизнес-процессов требуются когда Вы начинаете общаться с пользователем. Но какое это имеет отношение к собственно написанию кода? Тут консультанта в пару к разработчику будет достаточно.

Axapta/AX/D365FO это не технический фреймворк. Это продукт. Может быть D365FO и другой продукт, но все они продукты.

Он не служит целям структуризации кода и труда программиста, а служит целям обслуживания бизнес-процессов.

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

В теории:
Пользователь -> бизнес-аналитик -> функциональный консультант -> технический архитектор -> программист.

На практике по сути:
Пользователь -> бизнес-аналитик (который называется консультант) -> программист.

И насколько хорошо программист знает частности реализации кода типа

Number sequence framework
Financial dimension framework
Security framework
Dual write framework
Data management framework
SysOperation framework

всем просто по барабану. И это как-то более естественно чем необходимость в поводыре.

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

Если Вы работаете автослесарем, то знания ПДД Вам ни к чему. Если работаете водителем, то наоборот, знание устройства ДВС - не особо нужно

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

Большинство задач разработчика - это вовсе не написание новых бизнес-процессов, а задачи вида: "вот здесь - подмазать, здесь - подклеить". Вторая задача, упомянутая в стартовом топике темы - форма тормозит при открытии. Вот чем здесь поможет знание бизнес-процесса?

[mazzy]

Цитата:

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

Если Вы работаете автослесарем, то знания ПДД Вам ни к чему. Если работаете водителем, то наоборот, знание устройства ДВС - не особо нужно

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

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

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

Цитата:

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

Axapta/AX/D365FO это не технический фреймворк. Это продукт. Может быть D365FO и другой продукт, но все они продукты.

Именно технический.
Именно фреймворк.

Причем не самый лучший по современным меркам. И к тому же насквозь закрыто-проприетарный.

И в подтверждение тому современная D365FO. Где собственно бизнес-фич исчезающе мало. Зато куча технических нововведений, которые вводятся для решения чисто технических задач.

[Lucky13]

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

Отдельный интересный вопрос, а нужны ли такие теоретические знания при программировании в ERP-системах? Например, лет 30 назад, программировали на Си, но ассемблер знали и, если надо, на ассемблере вставки делали. О машинном коде тоже представление имелось, но его мало кто тогда использовал.Позже ассемблер стал постепенно выходить из обихода и использоваться только в очень специфичных областях.

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

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

[Pandasama]

Цитата:

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

Думаю, в теоретические знания по программированию (высокого уровня) такая задача не входит пару десятков лет.

[ax_mct]

Цитата:

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

...
именно про знания "разработчика" (программиста).
...
Большинство задач разработчика - это вовсе не написание новых бизнес-процессов, а задачи вида: "вот здесь - подмазать, здесь - подклеить". Вторая задача, упомянутая в стартовом топике темы - форма тормозит при открытии. Вот чем здесь поможет знание бизнес-процесса?

Есть личный опыт который может различаться. Есть реалии которые формируется рынком. Есть то что мы лично считаем правильным.

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

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

Правильно, на мой взгляд, когда мы понимаем что мы просто работаем с продуктом и расширяем его. И не нужно пять человек чтобы закрутить лампочку как в Java. Мы не они, они не мы. Достаточно двух.

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

По сути программисту нужно принимать фунционально-технические решения. То же изменение свойства на menuitem это уже не частности кода, это то что влияет на то что и как видит пользователь. После изменения этого свойства программист открывает форму и сравнивает до и после. Пытается смотреть и думать как пользователь. Это не два байта по http переслать и не просто листинг кода.

Цитата:

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

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

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

Именно технический.
Именно фреймворк.

Причем не самый лучший по современным меркам. И к тому же насквозь закрыто-проприетарный.

И в подтверждение тому современная D365FO. Где собственно бизнес-фич исчезающе мало. Зато куча технических нововведений, которые вводятся для решения чисто технических задач.

ERP продукт как технический фреймворк?
Да, есть правила и ограничения, есть трубы и заборы там и здесь.
Но это не делает AX/D365FO фреймворком.

Если мы продукта уберем бизнес-логику, то действительно остается
технический фреймворк. Не фреймворк для структурирования кода, но некий
технический фреймворк, это да. Генерация интерфейса, генерация запросов к базе и прочее.

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

Разработчики на проектах в принципе не могут работать без соответствующих знаний функционала и понимания пользовательских сценариев.

А вот внутри Майкрософт могут полноценно играть в разработку софта на уровне классов. Как истинные программисты.

Цитата:

Где собственно бизнес-фич исчезающе мало. Зато куча технических нововведений, которые вводятся для решения чисто технических задач.

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

Клиентам продолжают продавать D365FO как легко кастомизируемый и предназначенный для кастомизаций продукт. И это не внешний вид, и не отчеты, а именно особенности бизнес-процессов.

[Lucky13]

Цитата:

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

Думаю, в теоретические знания по программированию (высокого уровня) такая задача не входит пару десятков лет.

Кстати, да. Теория за десятки лет тоже меняется. Задача про переменные имела смысл, когда была актуальна проблема нехватки памяти. Интересно, а какие проблемы актуальны сейчас, когда проблемы вычислительных ресурсов далеко не всегда первостепенны?

[Logger]

О-о-о-о, какой хороший наброс получился !!!
Аж забурлило.

А то я думал форум скоро плесенью покроется ))

[sukhanchik]

Цитата:

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

Кстати, да. Теория за десятки лет тоже меняется. Задача про переменные имела смысл, когда была актуальна проблема нехватки памяти. Интересно, а какие проблемы актуальны сейчас, когда проблемы вычислительных ресурсов далеко не всегда первостепенны?

Ответ сильно зависит от объёма данных системе, количества пользователей в ней (в т.ч. одновременно работающих) и от приближённости бизнес-процессов клиента к заложенным бизнес-процессов в системе.
"Малым" предприятиям интересен уход "в облако", минимальная кастомизация (в плане объёма) и лёгкость настройки системы под решение их задач
"Средним" предприятиям интересен уход "в облако", кастомизация с лёгкостью обновления, контроль лицензий (составление ролей с минимальной стоимостью лицензий), автоматизированная интеграция данных с чем-нибудь внешним
"Крупным" предприятиям интересен полный контроль над БД, в связи с чем им удобнее локальная версия. Их интересует оптимальная работа с данными (скорость чтения / записи, объем потребляемой памяти и т.д.), кастомизация в первую очередь по неким внутренним правилам (упорядоченная), автоматизированные интеграции в разные стороны с чем-нибудь внешним.

[ax_mct]

Цитата:

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

Кстати, да. Теория за десятки лет тоже меняется. Задача про переменные имела смысл, когда была актуальна проблема нехватки памяти. Интересно, а какие проблемы актуальны сейчас, когда проблемы вычислительных ресурсов далеко не всегда первостепенны?

Была актуальна до эпохи персональных компьютеров. До появления пользователей. Был только мир программистов.

А как только появились пользователи, как только появился пользовательский интерфейс появились другие миры.

И самая актуальная проблема после нехватки памяти это нехватка программистов с пониманием бизнес-процессов и умением смотреть глазами пользователя. А вернее отрицание такой естественной потребности в IT индустрии.

Особенно нелепо это в AX/D365FO. Подавайте программисту консультанта по функционалу системы и желательно подробный технический дизайн как должна выглядеть форма, какие поля таблиц и откуда.

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

То проблема в том что программисты бесконечно далеки от народа и потребностей тех для кого они пишут код. Себя самобслуживают.

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

Что то неправильное в этом мире когда программист с 10 годами в ERP системе, как к примеру Lemming, начинает переписывать код ради кода и для других программистов.

Мы не true программисты, мы real программисты. Для реальности. Мы можем делать это в отличие от истинных эльфов. И сила наша она именно в знании бизнес мира и функционала продукта.

В X++ нет силы. А в полноценном прототипе решения для конечного пользователя который можно сделать за несколько дней. Что без фунциональных знаний - невозможно.

И Java нервно курит от зависти, переписывая тонны кода с версии на версию,
без какой либо обратной связи от реального мира.

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

[Lucky13]

Цитата:

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

Ответ сильно зависит от объёма данных системе, количества пользователей в ней (в т.ч. одновременно работающих) и от приближённости бизнес-процессов клиента к заложенным бизнес-процессов в системе.

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

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

[Lucky13]

Цитата:

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

Была актуальна до эпохи персональных компьютеров. До появления пользователей. Был только мир программистов.

А как только появились пользователи, как только появился пользовательский интерфейс появились другие миры.

Согласен. Раньше говорили, что программист - это прежде всего математик. То есть живет в абстрактном мире вычислений. Сейчас мир изменился

Цитата:

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

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

Ну вот откуда такая нелепая позиция?

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