CodenamedДавайте сразу определимся. Я рассуждаю не умозрительно. У меня есть некоторый опыт использования управляемого данными функционала. Достаточно ограниченный - но всё таки опыт. Я вижу, что пользоваться им удобно и это экономит массу времени. Я могу ошибаться, когда пытаюсь разобраться в причинах этого удобства, но только не пытайтесь меня убедить в том, что мне на самом деле неудобно.
Если слово "удобно" кажется вам недостаточно строгим, подставьте вместо него "заметно меньшие трудозатраты на проект\задачу". Я часто играю роль ПМ и считать трудозатраты - моя работа.

Ещё одна мысль. Предложения типа "переделайте свои процессы разработки, увольте таких программистов, перепишите клиента, но только не делайте Ужасный Функционал Управляемый Данными", звучат не очень серьезно. Давайте соотносить цели и средства.


Codenamed bebop
1) в гуёвом коде клиентского приложения написанного несколькими поколениями программистов средней ценовой категории разбираться, почему-то, на порядок сложнее чем в серверном
Бывает, согласен. Но разбираться так и так надо. Иначе что это за система, в которой вы сами не разбираетесь?Ну мы и разбираемся. Просто это занимает заметно больше времени. Объектные модели гуёвых библиотек и клиентских приложений сами по себе имеют высокую сложность.Кроме того клиентское приложение предоставляет программисту гораздо больше возможностей выпендрится, чем код хранимой процедуры.

Codenamed bebop
2) следствие 1 - риск возникновения проблем при изменениях в клиенте, по факту (в нашей конторе) оказывается существенно выше, чем при изменениях на сервере (соответственно тратится больше времени на тестирование)
Видимо, у вас очень сложный клиент. У вас бизнес-логика сосредоточена там? Это не издевка, как могло бы показаться.. Наличие или отсутствие БЛ на клиенте мне не кажется существенным фактором. Принципиален факт того, что в клиенте что-то изменилось. Например поле переставили на 2мм ниже. Для нас это означает гемор "пересборка-регрессия-выкладка-общение с пользователями". Почему у нас это гемор я чуть ниже напишу.

Codenamed bebop
3) интеграция изменений от нескольких разработчиков, правящих одну и ту же форму- постоянная головная боль, при изменениях затрагивающих клиентское приложение, с серверным кодом проблема практически отсуствует или решается механическим "мержем".
Хм... А вот это ерунда полная. Не должны одну форму править несколько разработчиков. Либо она принадлежит к одному функциональному модулю и ее "ведет" один разработчик, либо... Это даже трудно представить, по крайней мере пример не смог придумать. Кажется, надуманная сложность. Разработчик "ведёт" форму? Это пройденный этап. При существенной частоте изменений и 8 разработчиках это означает кошмар при планировании. Кроме того это означает отсутствие взаимозаменяемости разработчиков. Геморой с правкой одной формы разными разработчиками, выглядит предпочтительнее.

Codenamed bebop
4) цикл выкладки для изменений затрагивающих клиентское приложение получается достаточно тяжёлым (интеграция изменений от нескольких разработчиков, сборка, ручное регрессионное тестирование, выкладка на нескольких промежуточных серверах, взаимодействие с пользователями ("ой, а мы не можем обновляться - у нас сейчас интенсив")
5) при проблемах откат изменений затрагивающих клиентское приложение также получается существенно более трудоёмким. А в таких ситуациях время особенно ценно.
Если отбросить проблему интеграции изменений и сборки (откуда такая проблема??)...
Неужели вы не проводите тестирование при изменении серверной части?
У вас не автоматизировано размещение на каком-то "сервере приложений" новых версий с сохранением текущих?
Вы не можете отложить момент обновления клиентской части на произвольное время после того, как она выложена на сервер? Попробую разобраться, почему у нас этот цикл такой тяжёлый получается.
Возьмём процесс по небольшому изменению - исправили ошибку или поле добавили\убрали.
a) Сборка\интеграция - здесь играет проблема 3 (правка визуальных объектов несколькими людьми одновременно) + у нас слабовато организован процесс сборки. Перед боевой сборкой нужно согласовать "голосом", что в релиз не попадёт то что не должно попасть и не пропадёт то что пропасть пока не должно. Это согласование во многом страховка от накладок по проблеме 3.

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

в) Внедрение - Здесь два фактора - это общение с пользователями и взаимодействие с группой техподдержки, которая осуществляет внедрение (у нас такая практика).

Перерыв в работе кол-центра - очень нежелателен. Обновление клиента в середине рабочего дня, нужно согласовывать с ними "голосом". Просто уведомить по почте - сделайте обновление - нельзя. Это всё трудозатраты. Соответственно, чем незаметнее для пользователей пройдёт внедрение\откат, тем дешевле. При изменении серверных процедур мы можем вообще никому ничего не говорить. Если меняешь клиента, то придётся тратиться.

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

Codenamed bebop
6) клиентское приложение - вечный источник проблем. У одного пользователя офис не той версии, у другого права на реестр кривые, у третьего Windows XP, у четвёртого рантайм грида забыли развернуть итп. Соответственно каждый раз когда что-то меняешь в клиенте рискуешь собрать эти грабли.
Источник всех перечисленных проблем - это не клиентское приложение, а неудовлетворительная работа системного администратора. И эти проблемы должны решаться независимо от того, обновляете ли вы клиентскую часть, или только серверную. Когда клиентских машин 200 в нескольких офисах, трудно добиться от них идентичности конфигурации. Можно, конечно, застраивать админов. Но до того момента когда они застроятся, проектов что-ли не делать?
Потом по каждому факту админу ещё нужно доказать, что проблема именно в конфигурации машины. Или вы думаете, что админы автоматически берут вину на себя при ошибке вылетевшей из клиентского приложения?

grexhide bebop
a) Сборка\интеграция - здесь играет проблема 3 (правка визуальных объектов несколькими людьми одновременно) + у нас слабовато организован процесс сборки. Перед боевой сборкой нужно согласовать "голосом", что в релиз не попадёт то что не должно попасть и не пропадёт то что пропасть пока не должно. Это согласование во многом страховка от накладок по проблеме 3.

Чет вообще не понятно. На кой визуальные правки делать тремя людьми одновременно?
Вы чай инвалидов каких набираете, с нарушением двигательных каких фукнций
(один на клавиатуре чет там, другой мышой, третий командует и линейкой отступы меряет)?
Чего непонятного? Выполняются 3 параллельных разных проекта. Все они затрагивают контролы на экранной форме "Счёт". Возможно одни и те же. Автоматическое слияние изменений в этом случае затруднено. Есть достаточно большая вероятность неожиданных эффектов.
Кроме того нужно голосом договариваться кто после кого будет форму править.

grexhideЭталонная конфигурация, автоматически обновляемая с сервера. Все пользовательские параметры (читай профили) - только в БД. Алилуя. Мы работали с переносимыми профилями - не понравилось (не мне, я не админ). Сейчас постепенно отказываемся от них.

grexhideЭэ.... обновление делается или в окна (как правило в ночные или вечерние), либо, в случае 24x7...впрочем, у вас же не 24x7, чего распинацца то?
Можно конечно автоматизировать выкладку обновлений, так чтобы они делались ночью, но тогда несколько человек должно выйти в 8-30 утра, на случай если будут проблемы. А лучше в 7-30.

Опять же тема откатов. При откате обновлений обычно нет возможности ждать "окна".

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

grexhide
И чо? Забейте на реестр, забейте на конченный компонент грида, забейте даже на MS Office. Ориентируйтесь вон на открытые форматы и нативную запись. Делов то. Хорошее приложение -
должно работать везде и всегда (где вообще работает что либо).

Как то вы криво системы строите. По большому счету, нормальному приложению должно быть глубоко фиолетово, как оно и на чем оно. Все необходимое прикладное имеет право доинсталлироваться с сервера, трижды верифицироваться, и только потом запуститься пред ясны
очи счастливого пользователя.
И - никак иначе. (Т.е. в иделе - это должно быть вообще одно приложение, просто .EXE).

На Вашем бы месте - я бы, если честно, задумался - а стоит ли делать их вообще....
Пойду задумаюсь а стоит ли делать проекты вообще ;)

Давайте опустимся на землю.
Изменение процессов в отделе - вещь несопоставимая с проектом котоый мы обсуждаем.
Переписывание клиента(ов) - вещь из области научной фантастики.
Увольнение всех разработчиков\администраторов и набор "правильных"- вещь из области научной фантастики.

Кажется я понял. Большая часть дискуссии- свелась к вопросам процессов разработки

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

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

2й процесс считается формально "правильным" и объективно снижает риск проблем.
1й процесс хорошо себя показывает, если знать его границы.

Управляемый данными функционал (УДФ) позволяет расширить границы применимости 1го процесса.
Мне это нравится. Заказчику тоже. Если не выходить за границы - то никаких ощутимых проблем с ним нет.

В принципе для 2го процесса УДФ тоже хорошо работает. Только там будет несколько другая аргументация и другие акценты.

Codenamed bebopВыполняются 3 параллельных разных проекта. Все они затрагивают контролы на экранной форме "Счёт".Так вот в чем проблема! Попробуйте для 3 разных проектов сделать, соответственно, три разные формы для счета! Это, естественно, если я вас правильно понял: что вы имели в виду три проекта для трех разных заказчиков. И если это действительно так, то представляю, с какими трудностями вы сталкиваетесь!
У нас один заказчик. Большой поток мелких заявок на доработку функционала (до сотни в месяц). Это наряду с несколькими относительно большими проектами.
В такой ситуации по одной и той же форме часто параллельно ведётся несколько проектов и проектиков.

Codenamed Если же вы стараетесь не впадать в зависимость от конкретных сотрудников, то это уже плохо пахнет. А если человек уволится, заболеет итд итп? Это нормальная практика, если не доводить её до фанатизма.

CodenamedКстати, обновление клиентской части - это в подавляющем большинстве ситуаций не есть проблема. ... Достаточно интересная схема. А если сервер с клиентскими приложениями терминальный - (т.е. много пользователей использует один и тот же, грубо говоря, екзешник) ?

Даже если отвлечься от темы - "аргументы за и против УДФ", то в целом, мне НЕ кажется, что автоматизация выгладки клиента кардинально снизит трудозатраты по статье "внедрение". Мне кажется большинство трудозатрат там организационные - позвонить, договориться, приготовиться к откату.

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

Codenamed Почему бы не сделать свою копию формы для каждого проекта? Тогда в каждом проекте ее смогут подогнать под собственные нужды, но все изменения будут изолированными внутри отдельного проекта или проектика, а это дорогого стоит. Ведь это колоссально снизит объемы регрессионного тестирования. Заказчик один и форма Счёт соответственно одна. Механически - не разделишь. Но в целом согласен, что в перспективе формы надо разгружать и разделять (скажем выносить отдельный по смыслу функционал в отдельные формы).

CodenamedКстати, интересно было бы узнать: у вас есть выделенные специалисты-тестировщики (как бы их не называли), то есть люди, у которых это - основная работа. Есть 2 человека. И ещё их начальник, правда сам он редко тестирует.