Об обратной совместимости
Где проходит граница, когда её обеспечение становится нецелесообразным
Одна страница
Распечатать
. Редактировалось 1 раз, последний — #1
Недавно обсуждали с 10geekом в личке проблемы обратной совместимости, и по итогу я задался вопросом: а до какой степени имеет смысл её обеспечивать. (В первую очередь, речь идёт о Web-разработке, но интересны мнения и для общего случая). С одной стороны, очевидно, что поддерживать IE 4.0 или PHP 3.0 не имеет никакого смысла: сейчас даже найти компьютер/хостинг с ними будет весьма нетривиальной задачей. С другой — видел на Хабре точку зрения «поддерживаем только два последних релиза», но на мой взгляд, это другая крайность, которая приведёт к потере пользователей. Например, в те времена, когда я сидел на Ubuntu 18, в дистрибутиве была версия 7.2, из-за чего я так и не попробовал CMS Grav, которая уже тогда требовала минимум 8.0 и ещё пару менее известных CMS.
Принимать решение «вот эту версию поддерживать будем, а вот эту — уже нет» можно на основе двух подходов: либо по доле пользователей (как при разработке под Android, когда для каждой версии SDK пишется, какую примерно долю имеющихся в мире устройств она покроет), либо на основе трудозатрат и усложнения жизни разработчикам. Например, использование тех же flexов в вёрстке значительно упрощает и ускоряет процесс, но приводит к развалу вёрстки в IE9 и более ранних. Или использование тега detail?
Но и тут возникает вопрос: а какое соотношение трудозатраты/доля является оптимальным? Имеет ли смысл тратить пару-тройку дополнительных часов ради 0.1% пользователей (вернее даже не пользователей, а устройств, так как это могут быть боты)? А 1%?
Сам я ориентируюсь больше по времени и тому, насколько критично важна та или иная возможность. Обычно для критически важных (типа тех же flexов) я занимаю такую позицию: если с момента всеобщей поддержки этой функции прошло больше 4 лет, то тратить дополнительные силы на обртаную совместимость уже нет смысла. Если функция вспомогательная и направлена только на некоторое улучшение того, что сейчас называют UX (хороший пример — выпадающая подсказка при поиске), но в целом можно пользоваться сайтом без неё, то срок меньше, где-то около двух лет.
Но, возможно, есть и какие-то другие соображения?
Принимать решение «вот эту версию поддерживать будем, а вот эту — уже нет» можно на основе двух подходов: либо по доле пользователей (как при разработке под Android, когда для каждой версии SDK пишется, какую примерно долю имеющихся в мире устройств она покроет), либо на основе трудозатрат и усложнения жизни разработчикам. Например, использование тех же flexов в вёрстке значительно упрощает и ускоряет процесс, но приводит к развалу вёрстки в IE9 и более ранних. Или использование тега detail?
Но и тут возникает вопрос: а какое соотношение трудозатраты/доля является оптимальным? Имеет ли смысл тратить пару-тройку дополнительных часов ради 0.1% пользователей (вернее даже не пользователей, а устройств, так как это могут быть боты)? А 1%?
Сам я ориентируюсь больше по времени и тому, насколько критично важна та или иная возможность. Обычно для критически важных (типа тех же flexов) я занимаю такую позицию: если с момента всеобщей поддержки этой функции прошло больше 4 лет, то тратить дополнительные силы на обртаную совместимость уже нет смысла. Если функция вспомогательная и направлена только на некоторое улучшение того, что сейчас называют UX (хороший пример — выпадающая подсказка при поиске), но в целом можно пользоваться сайтом без неё, то срок меньше, где-то около двух лет.
Но, возможно, есть и какие-то другие соображения?
Ребята, давайте жить спокойно!
Одна страница
Распечатать У вас нет прав для отправки сообщений в эту тему.