Слишком часто я вижу людей, уклоняющихся от новейших технологий в духе обратной совместимости. «Мы не можем перенести минимальное требование PHP до 5,5, потому что у нас еще 50% наших пользователей на 5,4!», — говорят они. «Мы не можем перейти на Guzzle 4+, наш бэкэнд основан на версии 3, и это займет слишком много времени и денег». Мне больше всего нравится общий аргумент из WordPress: «Мы не можем выполнить полную ООП и развязку логики / представления, потому что большинство наших пользователей используют общие хосты с PHP 5.1 или не знают ООП и / или MVC».
Бред какой то.
Legacy Code — большое НЕТ
Это может показаться спорным, но я твердо верю, что в современных системах нет места устаревшему коду. Позвольте мне уточнить, прежде чем заточить вилы и зажечь факел. Под этим я подразумеваю: должна быть абсолютно нулевая причина для того, чтобы продолжать добавлять функции, которые вы добавляете в новую версию, задним числом в старую версию, просто потому, что некоторые люди все еще используют ее, даже если люди, использующие ее, огромны большинство.
Чтобы уточнить: исправление ошибок в унаследованных версиях, пока не истечет срок действия их долгосрочного контракта на поддержку или вам не понравится, если вы отвечаете, да Добавляя новые функции, вы придумываете версию X в версию X-1, чтобы совсем не рассердить пользователей X-1, а на 100% — нет. Аналогично, добавление кода X-1 в версию X только потому, что он может «служить цели», должно быть незаконным. Если вы все еще платите людям за X-1 и основываете свои обновления на этом, ваш бизнес-план плохой, и вы должны чувствовать себя плохо.
Кто я такой, чтобы извергать такую чушь, правда? Мне никогда не приходилось поддерживать большой проект с заинтересованными сторонами и советами директоров, который движется очень медленно и делает всех счастливыми, пока он работает, несмотря на то, что он потенциально может работать в 100 раз безопаснее и в 1000 раз. быстрее, верно? Не совсем. Моим самым большим ребенком был большой издательский сайт со сложным бэкэндом, построенным на ZF1. Если вы когда-нибудь что-то делали в ZF1, вы знаете, что это за вихрь болезненных антипаттернов. Когда приложение начало демонстрировать признаки ухудшения из-за увеличения трафика, я полностью перестроил интерфейс сервера (наиболее интенсивно используемую часть приложения) на интерфейс ajax и вызовы API, значительно снизив нагрузку и купив достаточно время перестраивать весь набор приложений, которые у нас были, на единственном, что позволяли более высокие взлеты — Zend Framework 2. Если вы что-то сделали для этого , вы знаете, что это немного менее плотный вихрь антипаттернов, но все же вихрь антипаттернов и раздувать — но то, что я пытаюсь здесь сказать, — огромные обновления и полное переписывание могут произойти, если за ними стоят способные люди. Если все, что вы делаете, — это гибкие встречи и мозговой штурм, то нет никаких контрактов с LTS, которые могут помешать вам выглядеть глупо через пять лет.
Даже если вы выполняете бесплатную работу и / или работу с открытым исходным кодом, вам не следует отказываться от поддержки пользователей X-1, потому что вы делаете им одолжение только путем увеличения основной версии, а вместе с этим и серьезного обновления с потенциальным разрывом БК. Они должны либо адаптироваться, либо отмирать.
Так почему мы должны изгонять устаревший код из современных систем?
Бесконечное проклятие LTS
Применяя подход «поддержи все так долго, как сможем», ты закапываешь себя в бездонную яму и смотришь на то, чтобы растянуть себя несколько лет назад, когда тебе придется поддерживать четыре разные версии, ты будешь биться головой об стену, задаваясь вопросом, почему вы не освободили пользователей V1 и V2, когда все еще могли это сделать. В попытке сохранить большую аудиторию разработчики часто изо всех сил стараются помочь пользователям прошлых версий, с единственной целью удержать их. По этой же причине WordPress в своем текущем состоянии является таким необратимым беспорядком любительского кода. Не позволяйте себе быть прикованным к старым версиям.
Эти пользователи имеют мертвый вес и должны быть сброшены, независимо от того, сколько денег они вам принесут. Дайте им методы перехода и двигайтесь дальше — если они каким-либо образом способны, они наверстают упущенное в кратчайшие сроки. Если нет, они того не стоят.
Слишком долго поддерживая старые версии, вы вводите проклятие WP, в котором более старые версии, настолько плохие, что они безупречны, требуют все больше рабочей силы и усилий для исправления. Эту рабочую силу лучше потратить на создание новых версий и наем защитников разработчиков, чтобы помочь пользователям переходить.
Вы отталкиваете и отрицательно влияете на продвинутых пользователей
Последний раз, когда этот отчаянный захват наследия затронул меня напрямую, был при установке CMS, которую оказалось особенно трудно установить в среде Vagrant — не только из-за проблем с символическими ссылками, которые к настоящему времени широко известны (даже создателю Vagrant), но и из-за того, что они включают в себя унаследованную версию CMS внутри основной CMS, потому что они имеют некоторые свойства установки, а серверная часть еще не полностью переписана в новую версию. Зачем вообще переходить на новую версию? Зачем торопиться, если вы явно так далеко от готовности?
Спеша с новой версией, они получили своего рода гибрид, которого нет ни здесь, ни там — чудовище франкенштейновского унаследованного кода, которое все еще работает, но плохо, и новый код, который имеет потенциал, но не может достичь его без беспорядка, который старый код Хотя такой подход облегчает работу девелоперских компаний, которые все еще застряли в 1990-х годах, он значительно усложняет работу продвинутых пользователей. Удовлетворяя толпу, которая, по всей логике, должна исчезнуть, вы отталкиваете и еще больше отрицательно воздействует на продвинутых пользователей.
Вы знаете, как это происходит: не тратьте слишком много времени, пытаясь сделать мелкие детали в старых браузерах. Никто, использующий эти браузеры, не заметит. То же самое относится и к пользователям библиотек или систем управления контентом — те, кто заботится о прежней системе, не будут заботиться о том, что вы вводите в новую систему, поэтому вам не следует потеть над ними больше, чем необходимо.
Неудача иногда открывает успех
Конечно, иногда это просто невозможно, и эти исключения являются редкими и ценными учебными материалами. Один любопытный случай версий и разрывов BC — это Python. Python — это потрясающий язык. Вы можете построить почти все в нем. Это не будет работать так же хорошо, как могло бы быть в языке, построенном для этой цели, но это характер типов мастеров на все руки — они могут делать все очень хорошо, просто безупречно. Когда появился Python 3, он представил некоторые разрывы BC, не позволяющие пользователям Python 2 выполнять простой переход.
Большинство оправданий было: «На данный момент нет достаточного количества пакетов Py3» и «У нас слишком много кода в Py2, чтобы переписать все» — на что я говорю «Создайте то, что вам нужно» и «Бедные программисты, вынужденные программировать» и все »соответственно. Конечно, были некоторые веские аргументы , и они, как правило, появляются в проектах, которые настолько абсурдны, но проблема Py2 против Py3 фактически привела к чему-то другому — «Python Rift». К тому времени, как появится Python 4, люди, которые так яростно отказались от перехода на версию 3+, все еще будут застревать в Python 2, и сдвиг BC станет для них еще более значительным. В этот момент они могут также попытаться выучить новый язык. С другой стороны, тем, кто «выдержал разрыв» и обновился до уровня 3+ без особых колебаний, переписав важнейшие модули и адаптировав язык под свои нужды, а не наоборот, будет намного легче переходить на более новые версии.
Этот перерыв до нашей эры фактически отрезал ленивых и подготовил ландшафт Python для нового поколения разработчиков. На мой взгляд, это успех, ознаменованный неудачей версии. Программирование, как и во многих других сферах жизни, по-прежнему основано на выживании наиболее приспособленных — и если вы не можете адекватно потреблять новые технологии, уйдите с пути для тех, кто может.
Приложения против библиотек / пакетов
Там также вопросы о приложениях против библиотек. Другими словами, должно ли правило «без наследства» применяться к обоим приложениям в зависимости, например, от платформ, которые получают новый выпуск, или это должно применяться только к библиотекам, поскольку они должны прервать связь с предыдущими версиями, когда появятся новые?
И то и другое.
Библиотеки с версией X + 1 должны следовать четким путем к прогрессу — с момента, когда у вас есть общедоступная новая версия, поддерживайте подход только для исправления ошибок в последней.
Приложения, которые используют такие библиотеки, находятся в более сложной ситуации из-за их логики в зависимости от API, которые могли измениться. Разумный подход заключается в том, чтобы дождаться отчетов о стабильности от сообщества и, после проверки, начать переход. В течение переходного периода старая и новая версии библиотеки / инфраструктуры могут оставаться в использовании, и после обновления всех необходимых компонентов старую версию следует удалить. Разве это не займет много времени?
Нет достаточно большого веб-приложения
«Но, Бруно, некоторые приложения огромны, и на их переписывание уйдут месяцы», — скажете вы. «Переход с ZF1 на ZF2 — это год работы!», На что я говорю: глупость. Не существует веб-приложения, достаточно большого, чтобы гарантировать этот срок. На самом деле, я сделаю еще один шаг и скажу, что нет такого веб-приложения, которое было бы достаточно большим, чтобы оправдать использование такой большой платформы, как Symfony или Zend.
Не обращая внимания ни на одну из этих платформ, они являются сверхсложными чудовищами, состоящими в основном из профессионального кода, но если вы будете следовать передовым методикам, уважать разделение проблем, инкапсулировать ваши сервисы и API-интерфейсы для своего приложения, чтобы вы могли писать внешние интерфейсы, полностью отделенные от внутренних частей абсолютно ничто не мешает вам полностью переписать менее чем за месяц, независимо от размера и / или популярности приложения — при условии, что ваши товарищи по команде являются программистами, а не теоретиками. Неважно, сколько шаблонов и алгоритмов вы знаете — вам нужно знать, как их использовать, чтобы быть достаточно эффективными для выполнения переходов.
Схема обновления
Какую схему обновления следует использовать тогда? Существует только одна приемлемая схема обновления, которую разработчик программного обеспечения должен когда-либо использовать, независимо от популярности app / lib:
- Введите новую ветку для новой версии
- Пометить старую версию / ветку как устаревшую
- Публично заявить, сколько жизни осталось старой версии
- Выдать предупреждение всем пользователям старой версии
- Внедрите новые функции ТОЛЬКО в новую ветку, исправьте старую ветку / версию
- Когда EOL для старой версии, обрезать все связи. Не исправляйте ошибки, не консультируйтесь, даже не упоминайте об этом в документах. Убей это.
Вот и все — после этой процедуры вы никогда не попадете в неприятности.
Один проект, который принял этот подход в некотором роде, — это Guzzle . У них есть версия 3+, версия 4+ для тех, кто может получить быстрое развитие 21-го века, и новейшая версия для смельчаков, которые хотят самые последние и самые большие обновления во все времена.
Вывод
Как веб-разработчик, я твердо верю, что от устаревшего кода следует отказаться в отношении новых функций при смене основных версий. Если у вас большой проект в зависимости от программного обеспечения, которое было переведено в версию более двух месяцев назад, вам следует прекратить все операции и переписать все, чтобы соответствовать новой версии, особенно если программное обеспечение, которое вы используете, критично для бизнеса. В мире нет такого приложения, которое было бы достаточно большим, чтобы на полный переход потребовалось более двух месяцев, и, если оно есть, его следует удалить и написать с нуля — веб гораздо проще, чем все мы допускаем.
Как вы думаете? Должен ли устаревший код храниться бесконечно? Конкретное количество версий? Не за что? Как вы относитесь к унаследованному коду в сторонних проектах, используемом крупным проектом, по сравнению с унаследованным кодом этих сторонних проектов? Считаете ли вы, что должна быть разница в том, как любой из этих кодов обрабатывает устаревший код? Я совершенно неправ здесь во всех аккаунтах? Я хотел бы провести хорошую дискуссию по этому поводу — в конце концов, мои взгляды и опыт, очевидно, мои собственные. Дайте нам знать в комментариях ниже.