Лучшие практики для унаследованной совместимости [закрыто]

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

Используйте XML в качестве основы для формата вашего файла и добавляйте только в спецификацию DTD, не удаляйте. Таким образом, ваши файлы должны быть обратно совместимы с более ранними версиями, что является плюсом.

Answer 3

Вот хороший пример: использование мостов SLF4J для простой миграции из одного модуля ведения журнала. другому в Java.