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

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

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

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

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

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

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

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

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

[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. Где собственно бизнес-фич исчезающе мало. Зато куча технических нововведений, которые вводятся для решения чисто технических задач.

[ax_mct]

Цитата:

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

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

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

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

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

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

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

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

Очень странное утверждение! Знания ПДД нужны не только автослесарю, но даже мойщику машин - чтобы сдать экзамен на права А иначе как автовладелец вам передаст управление автомобилем, чтобы перегнать его 5 метров из гаража или мойки на стоянку? КоАП, ст.12.7 п.3 "Передача управления транспортным средством лицу, заведомо не имеющему права управления транспортным средством" - административное правонарушение. Если автомойщик без прав, к примеру, разобьет ваш автомобиль в хлам - виноваты будете вы: нечего было передавать управление абы кому

Цитата:

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

Если работаете водителем, то наоборот, знание устройства ДВС - не особо нужно

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

Цитата:

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

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

Это, наверно, про задачи поддержки на давнишнем внедрении. На новых внедрениях и запусках нового функционала на давнишних внедрениях всё совсем не так: сегодня пилим заявки на оплату и банковские выписки с учетом факторинга, завтра - интеграцию с WMS, послезавтра - кроссдокинг и заказы на перемещение... И везде надо понимать, о чем речь и зачем это всё нужно.

Цитата:

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

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

Знание бизнес-процессов поможет, в первую очередь, не делать из формы какую-то мега-супер-пупер-сводную таблицу с тремя сотнями полей из 20-и источников данных, чтобы она потом тормозила у всех при каждом открытии. Поможет спроектировать UX для различных ролей в процессе, чтобы все не лезли на одну форму за нужными данными, а, к примеру, смотрели на стопочки необработанных документов на плитке в своей рабочей области и, тыкая в плитку, открывали пусть ту же форму, но уже отфильтрованную по нескольким записям. А когда программисты действуют по принципу "пускай слон консультант думает - у него голова больше", как раз и получаются в итоге тормозные монструозные формы.

[sukhanchik]

Цитата:

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

Очень странное утверждение! Знания ПДД нужны не только автослесарю, но даже мойщику машин - чтобы сдать экзамен на права А иначе как автовладелец вам передаст управление автомобилем, чтобы перегнать его 5 метров из гаража или мойки на стоянку?

Сильно сомневаюсь, что этот автослесарь вписан в каждую ОСАГО всех машин, которые приезжают. И потом ни разу не видел, чтобы мойщик перегонял машины даже на 5 метров. Знаю, что такие есть, но лично не видел. Это означает, что реально мойщику (если он сам не водит машину) реально права не нужны (=легко без них можно обойтись).

Цитата:

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

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

Я. Жена. Последний раз попадали в аварию лет ... 7 назад, но при этом в год наматываем километров на 2 ТО. Понятия не имею, что там внутри, не собираюсь изучать (пока не припрет) и до сих пор не понимаю, зачем это все рассказывали в автошколе - на практике за 15 лет ничего из этого не пригодилось.

Цитата:

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

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

В жизни обычно не так бывает. В жизни сначала поступает вопрос - "а почему тормозит", а потом уже квалификация программиста должна быть такова, что он должен догадаться что три сотни полей с 20-ю источниками данных не ускоряет открытие формы, а наоборот замедляет.
Т.е. определить причины болезни и вылечить больного - это разные задачи. Для лечения нужны знания бизнес-процессов, а для определения причин - не нужны. Но без определения причин назначать лечение бессмысленно. Т.е. без знаний технических знания бизнес-процессов в данном случае не помогут.
На начальном проектировании - да. Но опять-таки без знаний технических можно такую форму и спроектировать ))

[ax_mct]

Цитата:

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

В жизни обычно не так бывает. В жизни сначала поступает вопрос - "а почему тормозит", а потом уже квалификация программиста должна быть такова, что он должен догадаться что три сотни полей с 20-ю источниками данных не ускоряет открытие формы, а наоборот замедляет.
Т.е. определить причины болезни и вылечить больного - это разные задачи. Для лечения нужны знания бизнес-процессов, а для определения причин - не нужны. Но без определения причин назначать лечение бессмысленно. Т.е. без знаний технических знания бизнес-процессов в данном случае не помогут.
На начальном проектировании - да. Но опять-таки без знаний технических можно такую форму и спроектировать ))

И прочитанные три тома Дональда Кнута несомненно являются частью такой квалификации

Хотя очевидно что ERP программист это не программист. А точнее только на 20% программист.

Вот что дает поиск по словосочетанию "ERP-программист"

Цитата:

ERP-программист – это специалист, основная задача которого заключается в обеспечении бесперебойной работы ERP-системы.

Цитата:

ERP-программист занимается разработкой, внедрением и эксплуатацией информационной системы планирования ресурсов предприятий - ERP-систем.

Цитата:

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

Цитата:

ERP-программист - это специалист, основной задачей которого является обеспечение функционирования ERP (Enterprise Resource Planning — Управление ресурсами предприятия) системы на фирме или предприятии.

Цитата:

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

И вот что дает термин программист

Цитата:

Программист — это разработчик алгоритмов и компьютерных программ.

Цитата:

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

Цитата:

Программи́ст — специалист, занимающийся программированием, то есть созданием компьютерных программ.

Цитата:

Программист — это специалист, который пишет и тестирует код для программного обеспечения.

Цитата:

Программист – это специалист, занимающийся разработкой алгоритмов программ. Основой для написания являются математические вычисления.

[Lucky13]

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

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

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

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

[Pandasama]

Цитата:

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

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

[Lucky13]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

[Lucky13]

Цитата:

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

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

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

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