Костыли*: инструмент или преступление?
*Костыль / обходной приём / workaround / паллиатив — относительно быстрое и простое решение проблемы, применяемое для срочного устранения её последствий, но не влияющее на причины её возникновения.

Многие разработчики ПО стыдятся своих «костылей», но, наверное, нет ни одного программиста, который хоть изредка их не использует. А если говорить о корпоративном e-learning, то в сложных проектах иногда без них вообще не обойтись.

Хотя костыли обычно считаются плохой практикой, иногда они бывают оправданы. Давайте разберёмся, в каких случаях их можно использовать в e-learning, а когда стоит избегать.

Когда костыли допустимы:

1. Сжатые сроки / временное решение
(А сроки практически всегда такие.)

Проект нужен «вчера», на разработку есть максимум 1,5–2 дня. Работы, если делать всё по-человечески, минимум на неделю. Что делать? Либо не сдавать проект в срок, либо собирать «на коленке» то, что как-то работает, а потом, при необходимости, переделывать «начисто».

Например: чуть больше чем за день (ну, так получилось) нужно было собрать лендинг с нестандартной механикой. Взяли два проекта, в каждом из которых была половинка нужной механики, и «поженили» их в один проект побольше. Стоит отметить, что и в тех двух проектах костыли присутствовали, а после «женитьбы» вообще получился франкенштейн. Но всё работало, и проект был сдан в срок.

2. Ограничения технологий
Не получается выполнить задачу теми инструментами, процессами и требованиями ИБ, которые есть, без костылей.

Например: конструкторы курсов очень удобны для стандартных задач, коих процентов 95 (а то и больше), но в остальных 5% требуются доработки, которые иначе как костылями реализовать невозможно. Или заказчику необходимо изменить элемент, который нельзя редактировать стандартными средствами конструктора.

.button { 
    color: red !important; // Костыль, чтобы перебить другие стили
}

3. Прототипирование
Нужно быстро проверить идею. Не факт, что она удачная, или, как минимум, высока вероятность, что потребуются существенные доработки. Так зачем тратить много времени? Чем раньше и дешевле проверили — тем лучше.

Например: два года назад я собирал диалоговый тренажёр с ИИ в Articulate Storyline. Основная задача — проверить гипотезы: насколько полезен такой тренажёр, как лучше реализовать механики, найти как можно больше подводных камней. Весь проект — склад костылей (добавление ИИ в Storyline само по себе тот ещё костыль, но и без этого их там достаточно).

Результат: быстро проверили гипотезы, получили опыт и полезные выводы для реализации будущих проектов.

Когда костыли недопустимы:

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

Например: проект-«франкенштейн». После 5–6 итераций изменений в лендинг (которые проходили с болью, потому что в проекте вообще ничего не понятно) переписали механики по-человечески. Теперь мелкие правки занимают не полчаса, а пару минут.

2. Если над проектом работает несколько человек / вносить изменения будет другой сотрудник или команда
В своём «кривом» коде бывает очень непросто разобраться, а в чужом — зачастую практически невозможно. Делу могут немного помочь комментарии, но лучше не портить жизнь другим людям и сделать всё хорошо и понятно.

Вывод
Конечно, если бы мы жили в идеальном мире, для таких решений не было бы места. Но в реальной жизни костыли — как молоток: ими можно и гвоздь забить, и стекло разбить. Главное — понимать, где они уместны, а где приведут к серьёзным негативным последствиям. В обучении (и другой быстрой разработке) они часто оправданы, но в серьёзных проектах лучше ими не злоупотреблять.

Алексей Миляев и команда сообщества Digital Learning