Первые впечатления от программирования в D365FO

[sukhanchik]

Отвечу за себя (я не связан с EVGL)
Новизна подходов - безусловно отнимает кучу времени, но это временные трудности.
Тиражированием во все среды может заниматься как и раньше один человек, просто это по времени физически дольше (создал package, залил его в библиотеку активов на LCS, разлил его по средам, нажал в каждой среде кнопку выход после заливки (0,5 часа-1 час ожидания; в момент заливки среды находятся в нерабочем состоянии)). Если на целевой среде есть студия, то процесс заливки без package занимает пару минут с учетом билда и синхронизации (система на время билда будет в нерабочем состоянии, после завершения синхронизации - оборвет все сессии, т.о. с т.з. пользователя система чуток повисит, сбросит сессию и продолжит работу).

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

Требования к железу... вопрос условный, т.к. скорость клиента после АХ2012 явно выросла. Скорость БД - на демо-данных визуально незаметна.

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

Раз встает вопрос выделении каждому разработчику своей виртуалки - значит сразу возникает вопрос о выделении времени на ее создание. Штатная виртуалка, которую можно выкачать на локал (и которую готовит МС) требует ее обновления каждые кажется 40 дней (у винды заканчивается демо-режим) и имеет стандартный код и демо-данные. Т.о. после ее выкачивания потребуется ее подключить к системе контроля версий, синхронизировать модели и обновить БД. И так делать регулярно из-за ограничений по времени работы. При этом эта виртуалка будет иметь ограничения - она не будет видна снаружи и соответственно тестировать подключения снаружи на ней будет нельзя. Это коснется проверок веб-сервисов, entity и мобильного приложения.

Как вариант - можно развернуть виртуалку в облаке. Тогда на нее нужно будет только иногда накатывать свежую копию БД и один раз синхронизировать ее с системой контроля версий (все остальное будет работать). Но облако стоит денег.

Т.е. если так рассуждать - в АХ2012 и ранее вход в АХ нечасто осуществлялся через веб-портал, да и портал мог иметь внутренний адрес. Многие использовали Windows-клиента, которому для подключения не требовался внешний URL-адрес АОСа. В D365FO версия стала облачной и эти проблемы всплыли естественным образом. В версии On premise вполне вероятно, что облачные проблемы уйдут, но тогда уйдут и облачные преимущества.

Ключевые потери времени при программировании в D365FO (по сравнению с AX2009) которые я вижу сейчас:
1. Тестирование. Билд+синхронизация+запуск браузера и вход систему. Не засекал точное время, но секунд 30 если не минуту ждать приходится. Раньше это было мгновенно. Даже инкрементная сборка CILа в 2012 не сильно увеличила времени. Более того - полный билд в D365FO у меня длится порядка 1,5 часа против 20 минут сборки CILа в 2012. Это сопоставимо с глобальной компиляцией в AX2009 / 2012, но в них запуск билда не мешал работе системы.
2. Отладка. Установка точек останова + Загрузка отладочных символов. Все, кто отлаживался в клиенте АХ 2009 / 2012 - никто с этим не сталкивался и никто не ждал загрузки отладочных символов, которая может занять и несколько минут. Мало того - они еще не все могут подгрузиться. Кто программировал (отлаживался) в студии для АХ 2012 уже столкнулся с отладочными символами в АХ 2012. Так вот в ней загрузка всех символов была практически мгновенной по сравнению с D365FO. Возможно потому что кода было меньше
3. Невозможность быстрого запуска кода из студии без предварительного билда. Ну т.е. раньше можно было при дизайне формы быстро ее открыть, посмотреть - криво ли накидал поля или нет, поправить и снова открыть. Сейчас такого сделать нельзя. Предпросмотр формы есть на этапе дизайна и это помогает в поиске нужного контрола на форме, но он не покрывает функциональность открытия формы и просмотра окончательного ее внешнего вида. Это в первую очередь относится к своим формам, т.к. про расширения я скажу в следующем пункте.
4. Расширения (extensions). Относительно форм появился процесс поиска "в каком расширении добавлена эта кнопка на форме". Этого процесса раньше не было, а сейчас большей частью процесс поиска делается эмпирическим путем, что отнимает время. Также нет никакого средства посмотреть на дизайн результирующей формы, после того, как на нее наложатся все расширения, если не считать средством билд+запуск системы (п.1) В формах код расположен как раньше, а вот в расширениях код отделен от дизайна и появляется процесс поиска класса, который бы обрабатывал это расширение или форму.
5. В алгоритмах к времени поиска нужного места, куда нужно вставить код добавилось время на продумывание и реализацию способа вставки кода. Все расширения и Event handler-ы вызываются в случайном порядке (имеется в виду, подписанные на одно событие, либо расширяющие один объект) и нужно написать код так, чтобы он не конфликтовал с другими расширениями / обработчиками.
6. Права доступа теперь требуют синхронизации и применяются только после синхронизации БД и синхронизации индексов (не помню как это в 2012 было, может также, но в 2009 точно такого не было). Т.е. если наложить уникальный индекс на данные, на которые он не накладывается, то помимо ошибок синхронизации мы получим невозможность корректировки прав доступа. Учитывая, что со времени 2012 разработкой прав доступа занимается разработчик, разрабатывая привилегии с указанным уровнем доступа - то при сборке кода, если в данных не наложился какой-то индекс (возникла ошибка), то и изменения в правах не применятся. Т.о. добавляется время на содержание синхронизации без ошибок.
7. Рестарт IIS-а и Batch чаще требуется, чем раньше АОСа при разработке. Правда выполняется на порядок быстрее

В общем все это влияет на скорость разработки (пусть местами и незначительно, но при большом количестве незначительного увеличения времени в сумме время увеличивается заметно) и поэтому отсюда такой коэффициент по времени