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

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

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

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

Проблема в поддержке обратной совместимости в том, что каждый релиз добавляет большое количество хлама. Со временем это создаст остановку в развитии проекта и станет сложнее поддерживать чистоту кода при реализации новых идей. Это создает якорь, который удерживает проект в каменном веке.
Это вопрос нарастающего технического долга. Подумайте об этом. Если вы сделаете ошибку в дизайне 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

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