Здравствуйте, уважаемые знатоки! У нас в компании сложилась нехорошая ситуация, с которой надо что-то делать... Хотелось бы услышать мнения людей, сталкивающихся с подобным. Но обо всем по порядку...
Я работаю программистом в маленькой компании по разработке ПО. Мы пишем различные программные модули (финансовый, складской и т.д.) для организации и планирования бизнеса (что-то типа 1С, Галактика). Клиентов немного - всего 4. 2 из них крупные, которым нужно постоянно дорабатывать софт, а 2 других - мелкие (ну или можно сказать средние), для которых апгрейд софта требуется, но ЗНАЧИТЕЛЬНО реже.
Так вот, суть проблемы заключается в следующем (реальный пример из жизни)... Для одного из маленьких клиентов мы сделали складской модуль. Установили, работает. Затем складской модуль также понадобился и одному из наших крупных клиентов. Но там все не так просто, и его пришлось дорабатывать, чтобы заточить под нужды заказчика (он до сих пор в разработке). Изначально предполагалось, что складской модуль (как впрочем и все остальные) будет один на всех. Соответственно БД тоже должны быть спроектированы по одной схеме. НО! Через пару месяцев звонит маленький клиент (у которого мы склад поставили первым) и просит добавить в один из отчетов доп. поле. Делов-то, как говориться, на копейку, НО! Разработка склада ушла уже далеко вперед! Т.е. изменился не только сам модуль, но и БД (ведь все эти пару месяцев мы вели доработку модуля под нужды другого заказчика). Т.о. нам приходилось каждый раз, когда один клиент хочет изменения в модуле, накатывать ему все изменения БД, которые были сделаны для других, и обновлять exe. И все для того чтобы добавить какое-то поле в отчет (например)! При таком подходе есть ОЧЕНЬ серьезные недостатки:
1. Клиенты боялись обновлений как огня, т.к. накаты базы и обновление exe влекли за собой неотловленные баги. Плюс к этому мог запросто где-то поменяться интерфейс и т.п. Вобщем был просто кошмар!
2. Почему собственно клиент должен получать бесплатно (вместе с новым exe) те же самые дополнительные фишки, которые мы делали для другого клиента, который за них платит? Как-то это неправильно. Он ведь за них платить не будет. И правильно - он ведь их не заказывал. Он хотел только доп. поле в отчете, за которое и заплатит 100р (условно). А у нас порой на накат и связанные с ним проблемы могло уйти пара дней! А кто за них заплатит???
Вобщем, чтобы решить данные проблемы мы решили разделить исходники и БД, которые были бы индивидуальны для каждого заказчика. Это решает проблему пунктов 1 и 2, НО! Появляется новая головная боль! Опять по пунктам:
1. Исправлять найденные ошибки (например, в справочнике товаров) нужно теперь в нескольких местах (сколько копий исходников).
2. Внешний вид одних и тех же модулей может ОЧЕНЬ отличаться для разных заказчиков. Тогда новому заказчику какой демострировать? Непонятно...
Вобщем и в том и в том подходах есть минусы. Хотелось услышать ваше мнение по этому вопросу. Как же все-таки более правильно организовывать апгрейд и поддержку софта для нескольких клиентов?
P.S.: Интерфейс мы пишем на Delphi, а БД - Oracle. Правда смотрим уже в сторону .NET. Может она чем поможет...

Заплатит за них клиент, кто же ещё. Когда вы берёте деньги с заказчика, то сумма, в которую ему это обойдётся, должна быть прямо пропорциональна усилиям на разработку/доставку. То есть даже если это всего лишь одно поле в базе, это может стоить дорого. Альтернатива - продумывание и реализация более простого механизма "патчевания".


Архитектурный недостаток. Если есть возможность - лучше переделать архитектуру так, чтобы она использовала общие компоненты. Тогда изменение в этом компоненте затронет обе кастомизации.


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

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

Ясное дело, что достижимо это далеко не всегда. Потому можно подумать ещё над таким вариантом, как версионность за счёт организации кода. Под этим я имею в виду следующее.

Существует некий "эталонный" код (reference implementation). Это может быть код проекта вашего первого (или основного) заказчика. Он хранится в CVS (ClearCase, или еще-там-где). Для всех остальных проектов код организован в такую же файловую структуру, но хранятся там только те файлы, которые имеют отличия от основной ветки. При сборке билда ветка конкретного проекта накладывается на основную, и общие файлы перезаписываются. Тогда изменения основной ветки (например, фиксы общих багов) затронут и нижестоящие.

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

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


Я так понимаю, что по вашему мнению вариант с разделением кода неприемлим и лучше писать общий модуль, разделенный на компоненты (dll), со сложной системой настроек? А без сложной системы настроек там точно не обойтись, т.к. различия в одном только складском модуле у разных заказчиков потрясают вооброжение   


Да уж... Подход конечно - не фонтан.

А вообще я так понимаю что платформа .NET + C# как раз и позволяет реализовать нормальный компонентый подход к разработке приложений?

В общем-то, да. Если клиент хочет новый функционал, он должен за него платить. Либо следует просто перенести лишь этот небольшой кусочек в его проект.


Почему бы и нет? Лучше править конфиги в XML, чем код на плюсах (или что у вас там).
А о том, что второй вариант неприемлем, я не говорил. У нас используется как раз он. Нужно только четко понимать, какие трудности он за собой влечет.


Да это, в принципе, не вопрос конкретного языка. Но, в общем-то, Java и С# имеют некоторые языковые удобства для организации более структурированного с точки зрения ООП кода, что дает большую гибкость при внедрении компонентной модели.

mlitkin, +1 за совет о плагинообразной организации, плюс посмотрите в сторону smart client (если еще не смотрели). причем, вполне реальна ситуация, когда у разных клиентов разные реализации одного и того же плагина склада. соответственно, когда клиент просит какую-то фишку, которая есть в другой ветке, вы ее мерджите с его веткой. 

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

Пишите, будем разбираться.

У нас Delphi  Можно конечно и с конфигами сделать... Правда в таком подходе я сразу вижу ряд недостатков (первое, что приходит в голову):
1. Эта система будет ооочень сложна в разработке, настройке и поддержке, т.к. я уже писал, что различия в одном только складском модуле у разных заказчиков потрясают вооброжение.
2. exe-файл будет довольно-таки тяжеловесным, т.к. там будет вся функциональность всех заказчиков зашита. А т.к. обновления происходят по нету, то это может быть критично. Хотя, если реализовать грамотную компонентную модель, то может и не так это будет важно...


Уже начал изучать C#. Похоже в переходе на .NET действительно есть смысл...


Я - программист. Общаюсь с заказчиками, разрабатываю софт и затем его сопровождаю. Могу сказать, что мое мнение у нас далеко не последнее 



У нас в компании всего-то 6 человек  Так что инерция принятия решения не должна быть большой. Мы периодически переписываем наш софт с нулю, где-то раз в 2-3 года - очень помогает  И сейчас как раз уже похоже наступает такой момент когда, надо сделать это в очередной раз. Так почему бы не перейти на .NET?

А вообще, я считаю, что будущее таких вот как мы маленьки компаний как раз за оказанием ИНДИВИДУАЛЬНЫХ услуг клиентам. Т.е. если пишется софт для клиента, так уж только для него и с теми примочками, которые нужно только ему. Ну и естественно, что при разработке модулей для каждого последующего клиента нужно просто учитывать/использовать те наработки, которые были ранее. 
Подход должен быть не столько прибыль-ориентированым , сколько клиент-ориентированым! Тогда и прибыль будет ;) Проблема только в том, что у нас в России пока не понимают, что за штучный (индивидуальный) товар нужно платить соответствующие деньги. А у нас все хотят супер софт, заточеный под них, но по цене 1С! Но так ведь не бывает...

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

Хм... а я так понял, что batigoal всё же на модульную систему тебя агитировал. 
Лишний раз перечитав его слова, я так и не нашёл, где он тебе советовал делать именно "свалку всего в одном месте".

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

Ну, ежели так... тогда переход на дотнэт вам не страшен. Особенно, если со времени последней переписки проекта прошло хотя бы полтора года. 
А вообще это далеко не самая умная практика. Явно указывает на то, что "что-то не так".

Работал я на одной фирме, где у босса была такая же мысль. И знаете что? Команда программистов просто не успевала работать на всех. На фирме было две команды - одна (3-4 человека) занималась разработкой инструмента автоматизации, а другая (ещё человек 5) писала на этом инструменте софт для клиентов. И обе команды не очень-то успевали. Потому что перед тем, как  соглашаться на требования клиента, надо хорошенько их выяснить и разобраться в предметной области, чтобы можно было спроектировать такое, что с меньшими доработками можно будет адаптировать под других клиентов. Тот же подход, который был на фирме (и до сих пор есть, кстати), как и подход у вас - имхо, тупиковая ветвь, т.к. фирма распыляет свои ресурсы и ей остаётся только бороться за выживание, а не подниматься выше и выше.

Вот именно поэтому у "штучного" подхода меньше шансы на выживание. Согласитесь, 1С имеет куда более стабильное положение. У клиента нет страха, что через год фирма закроется и купленный продукт будет некому не то что развивать, но и просто поддерживать. Да даже если 1С закроется, что с того? Налетит куча других контор, наперебой предлагающих свои продукты. В этом случае у клиента будет отличная возможность познакомиться со всеми продуктами и выбрать то, что ему больше понравится. Неспеша. Да ещё и скидку получить - многие предложат скидки, чтобы только "взять" клиента - не забываем, что немалая часть дохода идёт от сопровождения продукта.
Вот и получается, что покупая 1С, клиент получает не совсем то, что ему надо, но дёшево (относительно). Если 1С закрылась - покупает ещё что-то примерно за ту же стоимость. Итого: клиент платит 2Х+поддержка. Если же он заказывает разработку под себя, то платит он раз в пять больше, т.е. 5Х. Плюс поддержка. Причём, если вы закрылись, то он остался с носом, т.к. через некоторое время потребуется новая "фишка", а делать её некому. (хорошо, если он найдёт тех, кто сможет что-то добавить, но ведь далеко не всегда такое возможно)
Итог - клиенту дешевле (не лучше, а именно дешевле) купить 1С. Многие это понимают и потому не идут заказывать "штучный" товар.

Кроме того, что C# изначально спроектирован так, что там просто необходимо писать модульно, у нас есть необходимость в доступе к данным по интернету, в чем может помочь ASP.NET. Плюс нужно еще писать софт для Windows CE. Так что я думаю, что .NET здесь самое то. Один язык на все задачи - это удобно 


Возможно вы и правы. Так как у нас сейчас именно такая ситуация :(

Хорошо. Допустим мы решим делать общий софт с системой dll-плагинов (или что-то типа того). Как тогда быть в такой ситуации: один из заказчиков захотел новое инф. поле на форме редакции товара, другим естественно это не надо... Что мы делаем? 
Отделяем всю форму редакции в отдельную dll для конкретного заказчика? В таком варианте, если изменится например какой-то запрос на этой форме, то его придется менять во всех ответвленных dll. 
Или делаем спец. настройку для отображения/скрытия данного поля? В этом случае нужно будет делать сложную обработку нормальной отрисовки интерфейса с этим полем и без него. Кроме того нужно будет накатить это поле в БД у всех клиентов.

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

Тут надо смотреть, может ли оно понадобиться другим. Если это поле объективно полезное, вставляйте в основной модуль. Если вдруг паре клиентов придётся не по вкусу нововведение, сделайте настройку для сокрытия этого поля.
Если же оно другим не надо, то можно сделать плагин в плагине, например. Или так же - в основной модуль и прятать настройкой (но это, имхо, будет хуже, т.к. такие поля будут со временем множиться и проект станет явно хуже).

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

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

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

В том-то все и дело, что обязательно намазолит. Т.к. там не 1 и не 2 таких полей, а гораздо больше :(


А можно чуть подробней про плагины? Может я это себе не так представляю, как оно есть на самом деле? В моем понимании плагины - это dll-файлы с доп. функциями/интерфейсами, которые вызываются из основного приложения. Так? Или там что-то еще?

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

Добавлено через 1 минуту и 15 секунд

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

М-да, плагины конечно штука хорошая, но и они решают лишь часть проблемы - интерфейсную. А есть ведь еще БД, в триггерах и ХП которой также реализована определнная бизнес-логика... Мы же все-таки не 1С, чтобы всю бизнес логику в интерфейс переносить 
Как быть там (в БД)? У нас была практика (да и сейчас тоже кое-где осталась), когда в базе в качестве константы хранился тип базы, зависящий от заказчика (т.е. признак заказчика), и мы по нему разделяли код в ХП и треггерах. Но этот подход ИМХО все же какой-то левый...