2008-10-02 1 views
11

Я работаю над приложением, которое имеет интерфейс графического интерфейса (GUI) и API (скриптинг). Наш продукт имеет очень большую установленную базу. Многие клиенты вложили много времени и усилий в написание сценариев, которые используют наш продукт.Как вы балансируете противоречивые потребности обратной совместимости и инноваций?

Во всех наших проектах и ​​реализации мы (понятно) имеем очень строгие требования по поддержанию 100% обратной совместимости. Сценарий, который запускался раньше, должен продолжать работать точно так же, без каких-либо изменений, когда мы вводим новую версию программного обеспечения.

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

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

Я знаю, что Windows Vista раздражала многих людей, когда они впервые появились, из-за всего программного обеспечения и периферийных устройств, которые на нем не работали, даже когда они работали над XP. Из-за этого он получил довольно плохой прием. Но вы можете видеть, что Microsoft также преуспела в создании замечательных инноваций в Vista, за счет обратной совместимости для многих пользователей. Они рисковали. Это окупилось? Приняли ли они правильное решение? Думаю только время покажет.

Вы находите, что балансируете противоречивые потребности инноваций и обратной совместимости? Как вы справляетесь с актом жонглирования?

ответ

5

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

В основном я устанавливаю «улучшенный» способ по умолчанию и удостоверяюсь, что через конвертер он может читать данные старого формата, но сохранять или хранить данные в качестве нового формата.

Я думаю, что большая вещь здесь - тест, тест, тест. Обратная совместимость не должна препятствовать продвижению вперед.

Это только мое 2с

1

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

+2

Для этого потребуется поддерживать 2 потока кода, поскольку не все клиенты будут мигрировать в новую систему, если это означает нарушение их скриптов. Это не похоже на самый эффективный способ работы в будущем. – LeopardSkinPillBoxHat 2008-10-02 06:25:14

1

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

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

0

Вы можете alawys искать инновационные способы поддержания обратной совместимости.

Смежные вопросы