Pull to refresh

Обратная совместимость для неудачников

Reading time 3 min
Views 12K
Original author: Anthony Ferrara
Вы верно прочли. Если целью вашего проекта является сохранение обратной совместимости — вы неудачник. Множество популярных проектов от PHP до Microsoft Windows заявляют об обратной совместимости между версиями. И да, я хочу сказать, что это не правильно.

Реальные перспективы


Что же, я не пытаюсь сказать, что поддержка обратной совместимости плохая цель. Во многих случаях от этого всем легче. Хм, возможно не всегда. В короткой перспективе в обратной совместимости нет ничего сложного, а выигрывают от этого все. Ментейнеру легче потому, каждое изменение невелико и сравнивать меньше. Пользователям легче, потому что обновление происходит менее болезненно.

Изъян в рассуждениях


Проблема в поддержке обратной совместимости в том, что каждый релиз добавляет большое количество хлама. Со временем это создаст остановку в развитии проекта и станет сложнее поддерживать чистоту кода при реализации новых идей. Это создает якорь, который удерживает проект в каменном веке.
Это вопрос нарастающего технического долга. Подумайте об этом. Если вы сделаете ошибку в дизайне API в первой версии проекта, то это ошибка будет преследовать вас на протяжении МНОГИХ версий. Вы не можете просто так взят и погасить этот долг. И это не сферический конь в вакууме*. Посмотрите на функции для строк и массивов в PHP. Почему параметры для них указываются именно в таком порядке? Потому что если их изменить — это обрушит обратную совместимость!

Дальновидность


Основная проблема обратной совместимости состоит в ее идеологии — считается, что все написанное будет корректно изначально. Если все идеально изначально, то и поддержка совместимости проста. В теории. Но на практике все не так. Как и другие вещи, мы никогда не сделаем все правильно с первого раза.
Вот почему я хочу представить новую концепцию. Почему бы вместо заботы об обратной совместимости не предусмотреть «поступательную совместимость»(Forward Compatibility).

Поступательная совместимость


Основы концепции:
Стараемся предвидеть будущие потребности кода, который мы пишем сейчас, и написать его достаточно гибко, для того чтобы не беспокоиться об обратной совместимости потом.

Вот это благородная цель… Нецелесообразно?
Ну, не совсем. Нам не нужно, чтобы код работал идеально — нам нужно, чтобы он выполнял свою задачу. Лучше мы ошибемся и сделаем неправильно сначала, но нам будет проще в будущем, чем изначально вообразим, что этот код решит все необходимые задачи и удовлетворит потребности в будущем.

В действии


Я придерживаюсь этой идеологии на протяжении года. Когда я разрабатывал API для пароля, использовался именно этот подход. Вот почему там есть параметр $options, вместо $cost и $salt. Я постарался предусмотреть будущие изменения и адаптировал под это API. Хорошо ли я это сделал? На этот вопрос мы сможем ответить в будущем. Но я думаю, что получилось намного лучше, чем если бы я следовал идеологии обратной совместимости(в соответствии с которой я мог делать все что хочу и как считаю нужным).
function password_hash($password, $algo, array $options = array())


TL/DR


В следующий раз, предлагая изменения, подумайте о том, как это можно реализовать под будущие потребности, а не оглядываясь на обратную совместимость. Лучший способ предотвратить отказы от обратной совместимости — планировать их изначально. Я не говорю игнорировать обратную совместимость, но лучше сфокусироваться на будущем и позволить прошлому стать на свое место.
Будущее — то на что мы можем влиять. Ошибки уже сделаны, они в прошлом. Давайте не будем тянуть их за собой вечно…

*Оригинал: And this isn't even a theoretical problem

Этот перевод явно содержит множество недочетов, я только учу язык, буду благодарен за указание на ошибки в личке, спасибо.
Only registered users can participate in poll. Log in, please.
А как считаете вы?
30.62% Нужно сохранять обратную совместимость как можно дольше, без костылей в виде options-массивов 128
15.07% Интересная идеология, опробую/практикую у себя в проектах 63
54.31% Да, сохранять, но не слишком долго 227
418 users voted. 116 users abstained.
Tags:
Hubs:
-14
Comments 33
Comments Comments 33

Articles