Коли можна відмовитися від зворотної сумісності на користь нової та вдосконаленої реалізації інтерфейсу? [зачинено]

Я працюю в одній і тій же програмній компанії більше десяти років. Як результат, я реалізував велику базу коду, використовуючи різні об'єктно-орієнтовані мови програмування. Я був початківцем програмістом, коли вперше розпочав свою кар’єру, і не знав багато про хороший інтерфейс та принципи дизайну класів. Мені хотілося б подумати, що мої дизайнерські навички з часом удосконалювалися, але зараз я стикаюся з все більшими труднощами в покращенні свого попереднього коду через проблеми з сумісністю назад. Мій код використовується великою кількістю клієнтів як частина продукції, яку продає моя компанія.

Моє запитання: коли слід припинити намагатися зберегти відсталу сумісність старих інтерфейсів і перекусити кулю на користь реалізації абсолютно нового дизайну?

Я думаю, що настає момент, коли збереження відсталої сумісності стає настільки великим тягарем, що корисні зміни інтерфейсів стають неможливими. Хто-небудь відчував подібні проблеми, хто може надати відгуки?

Хоча "коли" - це гарне питання, я думаю, що "як" є ще більш актуальним. Зробити перехідний перехід таким чином, що не робить користувачів розчарованими чи нещасними, може бути важко. Деякі елементи для розгляду:

• Спілкуйтеся зі своїми клієнтами / замовниками набагато перед будь-яким переходом. Поясніть, чому і як це буде реалізовано. Посилаючись на безпеку, працездатність, стабільність та гнучкість у майбутньому, все це справедливо.
• Якщо ви все-таки робите чисту перерву, вимагайте відгуків.
• Якщо є сторонні розробники, переконайтеся, що ви також включили їх внесок настільки, наскільки це має сенс.
• Якщо це можливо, надайте шар сумісності.
• Надайте повний посібник з оновлення.
• Зробіть оновлення максимально легким і безболісним. Мінімізуйте біль своїх користувачів, навіть якщо це означає трохи більше роботи для вас.
• Якщо ви стягуєте плату, запропонуйте знижку на оновлення до нової версії.
• Додайте принаймні кілька нових і корисних функцій у новій версії, щоб стимулювати оновлення. Це особливо важливо, щоб зробити оновлення більш привабливим для менеджерів.
• Якщо ви робите перерву, зробіть її в останній раз, коли вона вам потрібна. Це означає заздалегідь всебічне планування та переконання, що все налаштовано належним чином.
• Якщо у вас є інтерфейс користувача, легко змініть його. Думайте оновити, а не переробляти. Для нетехнічних користувачів різкі зміни інтерфейсу з однієї версії на іншу можуть стати великою причиною розладу.
• Ваша нова версія повинна бути помітно стабільнішою та ефективнішою, ніж стара. Не давайте своїм користувачам причин обурюватися оновленням. Не випускайте нову версію без попереднього обширного тестування (блок, інтеграція та бета-тестування).
• Зберігайте стару версію одночасно протягом тривалого періоду часу. Якщо ви все-таки вирішите припинити його і припинити підтримку, повідомте принаймні за 6-12 місяців, якщо більше зможете.
• Чи можете ви дозволити собі підтримувати дві версії одразу з точки зору фінансів та робочої сили? (Крім того, з точки зору бізнесу, ви не повинні припиняти підтримку старої версії, поки ви не зможете дозволити собі втратити решти клієнтів, які чіпляються за стару версію і не хочуть оновити. Такий момент повинен бути, коли ваші витрати на його підтримка переважає ваш прибуток від цього.)
• Зобов’язатися робити оновлення безпеки протягом періоду часу після відміни старої версії, якщо це необхідно.
• Знову ж таки, спілкування величезне протягом усього процесу. Не залишайте своїх користувачів / клієнтів / клієнтів відчути себе покинутими в будь-який момент. Їх вірність та пристрасть - основа вашого бізнесу. Переконайтесь, що ви відповідаєте на їхні запитання у своєму блозі чи на ваших форумах. Соціальний фактор не варто недооцінювати.

Що стосується "коли", ви, мабуть, матимете кращу ідею для своєї заявки, ніж хто-небудь інший. В цілому, однак, може бути час чистої перерви, коли ваш технічний борг та архітектура повністю перешкоджають стабільності, запобігають розумній роботі та роблять розробку нових функцій непосильними або непотрібними.

Все, що сказано, не робіть цього кроку легковажно. Навіть зроблено правильно, порушення сумісної сумісності - це велика справа. Слід роздумати над тим, щоб спочатку розширити покриття тестом та рефакторинг, а якщо це можливо, перш ніж розглянути перерву.

Загалом я згоден з Джеймсом Андерсоном. На моєму досвіді, однак, є додаткові аспекти, які можуть бути підставою для розгляду, і це може вказувати на варіант, який дійсно дозволяє змінювати інтерфейси.

Цей приклад з однієї з команд, з якими я працюю. Вони постачають товар регулярно, принаймні раз на місяць, іноді навіть щотижня. Клієнтам рекомендується оновити, оскільки нові функції та нові платформи підтримуються лише в нових версіях. Оновлення просте, і клієнти можуть навіть пропускати версії між ними. Пониження рівня не підтримується. Крім того, версії підтримуються лише 3 роки. Після цього настає пільговий період у один рік, коли плата за технічне обслуговування подвоюється.

В результаті переважна більшість - близько 95% клієнтів - регулярно проходять модернізацію, принаймні один раз на рік. Це також означає, що ви можете поступово вводити нові інтерфейси.

Як щодо старих інтерфейсів? Ця методика використовує команду - оголошує старі інтерфейси як "кінець життя". Потім настає 12-місячний період, коли новий інтерфейс доступний, а старий інтерфейс ще не вийшов з пенсії. Нові інтерфейси пропонують кращі функції, ніж старий інтерфейс, тому є два стимули: Старий термін закінчення терміну служби та новий інтерфейс значно кращі.

Старий конкретний інтерфейс у даному випадку був певною платформою, технологією, яка поступово замінюється сервісним інтерфейсом, заснованим на стандартній мейнстрімі.

Звичайно, ця зміна не відбувається протягом ночі, і до її завершення потрібно багато років. Але це дозволило зупинити інвестиції в стару технологію і замість цього інвестувати в нову технологію. Клієнт отримує допомогу і має шлях вперед. Більшість із них вітає також рух до новіших технологій.

Майте на увазі, що саме цей підхід може не працювати у вашому сценарії. Це, безумовно, працює для команди, з якою я працюю.

Ви вже отримали кілька хороших відповідей, тому я просто хотів би додати вказівник на дуже приємну статтю Джоела Спольського щодо цієї теми. Він обговорює плани відмови від зворотної сумісності в IE 8, що по суті те саме, що і ваша проблема:

http://www.joelonsoftware.com/items/2008/03/17.html

Коротка відповідь - Ніколи!

Досвід показує, що відмова від зворотної сумісності принаймні дратує клієнтів та користувачів, а в гіршому - втрачає їх повністю.

Якщо ви попросите своїх користувачів переписати код, після того, як вони закінчать звичне прокляття вас і всіх ваших нащадків, вони подумають "Якщо мені доведеться все-таки переписати, можливо, я повинен просто перейти до тієї чудової бібліотеки ACME, яку я читав" стільки про? ».

Трюк полягає в тому, щоб або покращити поточний інтерфейс таким чином, щоб він не порушував зворотну сумісність, або запропонувати абсолютно новий блискучий і очевидно покращений інтерфейс при збереженні старого інтерфейсу. В якийсь момент у новому інтерфейсі з’являться функції, які просто не будуть можливі в старому інтерфейсі, але це просто дає людям стимул рухатися, не змушуючи проблему.

Змініть, щоб уточнити це далі.

Те, що ви як програміст думаєте, -

"Я вдосконалю цей API і зроблю систему якомога кращою, і всі будуть захоплюватися мною".

Що думають користувачі вашого API -

"A * * * e він вважає, що мій час і графік не важливі. Я повинен припинити те, що я роблю, і переробляти весь мій код не з іншої причини, ніж щоб задовольнити його его". до іншого API просто, щоб приклеїти його теж ".

Це дійсно більше бізнес-рішення, ніж технічне. Зазвичай це робиться як частина основного випуску (наприклад, перехід від версії 3.5 до версії 4.0), і часто обидві версії на деякий час підтримуються паралельно. Це означає, що ви будете обслуговувати стару версію, але всі нові функції з’являться лише в новій версії. Стара версія підтримується до тих пір, поки компанія заробляє з неї гроші або хоча б достатньо, щоб компенсувати витрати на обслуговування. Будьте готові поставити це керівництву.

Я був на стороні замовника цього, тому я б сказав, що це дійсно залежить від того, що ви плануєте зробити щодо переходу.

Зараз ми оновлюємо нашу систему рахунків. Компанія, яка здійснює оновлення, також підтримує попередню несумісну версію. Вони планують взяти дані та перенести їх у нову систему, щоб (теоретично) усі старі дані були там. Ми заплатимо пару сотень фунтів за перетворення даних. Нема проблем.

Порівняйте з попередньою ситуацією в іншій компанії, в якій я працював. Постачальник не мав можливості перейти від старої до нової систем. Це поставило їх у ту саму ситуацію, що і будь-який інший постачальник. Насправді їх ситуація була гіршою, тому що ми знали, що вони не зобов’язані допомагати нам у модернізації. Вони не отримали новий контракт.

Ви доклали важкої роботи із залучення та утримання клієнтів, як можна полегшити перехід?