Цитата:
Сообщение от
Владимир Максимов
...
именно про знания "разработчика" (программиста).
...
Большинство задач разработчика - это вовсе не написание новых бизнес-процессов, а задачи вида: "вот здесь - подмазать, здесь - подклеить". Вторая задача, упомянутая в стартовом топике темы - форма тормозит при открытии. Вот чем здесь поможет знание бизнес-процесса?
Есть личный опыт который может различаться. Есть реалии которые формируется рынком. Есть то что мы лично считаем правильным.
По моему опыту на западном рынке от старшего программиста ожидают функциональные знания и без них на половине проектов было бы невозможно работать. Прямо сейчас я разбираюсь в нюансах модуля производства. Иначе я просто не справлюсь со своей работой как программист.
В реалиях рынка нет заполненных отдельными людьми ролей функционального архитектора и технического архитектора. Эти функции распределяются естественным образом между двоими, консультантом и программистом, в зависимости от их опыта.
Правильно, на мой взгляд, когда мы понимаем что мы просто работаем с продуктом и расширяем его. И не нужно пять человек чтобы закрутить лампочку как в Java. Мы не они, они не мы. Достаточно двух.
Re: "форма тормозит при открытии"
Если это форма заказов к примеру, то в принятии решения какую именно информацию можно не показывать, какую перенести, что важно что нет - без функциональных знаний и кругозора никак.
По сути программисту нужно принимать фунционально-технические решения. То же изменение свойства на menuitem это уже не частности кода, это то что влияет на то что и как видит пользователь. После изменения этого свойства программист открывает форму и сравнивает до и после. Пытается смотреть и думать как пользователь. Это не два байта по http переслать и не просто листинг кода.
Цитата:
Сообщение от
mazzy
Добавлю, что важно различать разработчиков на проекатах и разработчиков распространяемых решений (фреймоврков). Да, сейчас разработчики решений остались только в Майкрософте. Но важно понимать, что их цели совсем другие.
Во-первых, для них самих важно понимать.
Во-вторых, вдруг кто-то из участников этой дискуссии путает
Именно технический.
Именно фреймворк.
Причем не самый лучший по современным меркам. И к тому же насквозь закрыто-проприетарный.
И в подтверждение тому современная D365FO. Где собственно бизнес-фич исчезающе мало. Зато куча технических нововведений, которые вводятся для решения чисто технических задач.
ERP продукт как технический фреймворк?
Да, есть правила и ограничения, есть трубы и заборы там и здесь.
Но это не делает AX/D365FO фреймворком.
Если мы продукта уберем бизнес-логику, то действительно остается
технический фреймворк. Не фреймворк для структурирования кода, но некий
технический фреймворк, это да. Генерация интерфейса, генерация запросов к базе и прочее.
В то же время мы не может отделить этот фреймворк как сущность от продукта, мы не можем создать другой продукт на этом фреймворке.
Разработчики на проектах в принципе не могут работать без соответствующих знаний функционала и понимания пользовательских сценариев.
А вот внутри Майкрософт могут полноценно играть в разработку софта на уровне классов. Как истинные программисты.
Цитата:
Где собственно бизнес-фич исчезающе мало. Зато куча технических нововведений, которые вводятся для решения чисто технических задач.
И соответствующий челлендж для программистов которые могут выполнить задачу только если понимают обе стороны и фунциональную и техническую.
Клиентам продолжают продавать D365FO как легко кастомизируемый и предназначенный для кастомизаций продукт. И это не внешний вид, и не отчеты, а именно особенности бизнес-процессов.