D365FO: Организация разработки - слияние модификаций

[sukhanchik]

Не.. это все понятно. Вопрос не в этом. Я бы тоже хотел лепить все в кучу для экономии времени разработки. Вот разработчику дали задачку - добавить поле на форму. Он должен сбилдить свой проект, чтобы все запустилось. Если он не билдит свой проект, то как он отлаживается? Если он билдит - то как долго? (Ему ж надо весь App Suite перебилдить?)

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

[belugin]

Цитата:

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

Если он не билдит свой проект, то как он отлаживается? Если он билдит - то как долго? (Ему ж надо весь App Suite перебилдить?)

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

Разделять по модулям удобно, если надо их как-то отдельно использовать или контроллировать их связи, как "полочки" для разделения функционала по логическим кусочкам. Если работает несколько функционально специализированных команд удобно что можно сделать internal классы и знать, когда обраная совместимость нарушается, а когда точно нет.

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

[fed]

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

1. Проектный опыт у разработчика
2. Понимание разработчиками предметной области
3. Хорошие коммуникации в комманде

Поскольку на реальных проектах все это в дефиците, то безусловно проще все складывать одну модель/package. (Что мы кстати и делали на своих проектах до этого). Тем не менее я думаю попробовать использовать такой подход:
Все мелкие, не очень понятные и не очень хорошо определенные модификации складываются один большой модуль/package. НО: Для некоторых отдельных хорошо определенных доработок (например - если мы что-то подобное уже делали на других проектах и уже понятно что и как делать), разработчик может выделить отдельную модель и пакет. Я что-то подобное уже делал. Например всякие дополнительные индексы по существующим таблицам или служебные поля для синхронизации с CRM (которые в аксапте показываются, но никак не обрабаываются) я складывал в отдельные модели. Вроде бы пока проблем не было.

[sukhanchik]

Цитата:

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

ао типичаная доработка мелкая.

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

А для проектов, где этого контроля нет - то да, решение skuull логичное и оправданное. Хотя вот это вот "Только иногда этого недостаточно и надо перебилдивать модуль" - это конечно угнетает (и угнетало).