Универсальные инструменты

yesno

Общеизвестна склонность разработчиков любого ранга стремиться вместо решения конкретных проблем, мастерить инструмент, решающий класс подобных проблем. Ловушка заключается в том, что любой класс проблем является подклассом другого, более общего класса проблем. Давайте разберём на несколько утрированном примере.

Бизнес-проблема:
Нам периодически нужно складывать 2 и 7, примерно с той же частотой складывать 9 и 4 и очень-очень редко вычитать 4 из 11.

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

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

Третья итерация:
Графический калькулятор. Позволяет выполнять любые арифметические действия с любыми числами.
Минуточку, но ведь этот подход не слишком универсален. Вдруг заказчику понадобится возведение в степень, извлечение корня, взятие производной/первообразной? Кроме того, может быть полезным набор статистических и финансовых функций.

Четвёртая итерация:
Весьма мощное приложение со сложным интерфейсом и различными режимами — простой калькулятор, инженерный, финансовый, статистический.

Death-Star

Через десяток-другой итераций на выходе получается гигантский программный пакет, умеющий выполнять всё, что угодно. Но почему-то в техподдержку обращаются пользователи клиента, не понимающие, как им сложить 2 и 7, 9 и 4, а также, как вычесть 4 из 11.

Ловушка называется «Трясина Тьюринга». Самые яркие продукты, попавшие в эту трясину: «Nero Burning Rom», «ACDSee», «Qip».

Формальное определение:

Тьюринговская трясина — жаргонное общее название для языков программирования, которые Тьюринг-полны, но обладают крайне примитивными синтаксисом и семантикой. Они неудобны для практического программирования (из-за трудности написания программ и низкой производительности), зато хорошо подходят для некоторых других задач (доказательство невычислимости некоторых функций, иллюстрация базовых принципов программирования и т. д.). Поэтому они интересны для информатики. Многие эзотерические языки программирования также являются «трясинами Тьюринга».
Однако ввиду простоты построения и реализации удобны для автоматической генерации кода.

Другие возможные переводы: яма Тьюринга, смоляной колодец Тьюринга. Дословно: смоляная яма Тьюринга (Turing tar-pit).
Originally: «54. Остерегайтесь трясин Тьюринга, в которых можно сделать всё, но ничего интересного нельзя сделать просто.»

Википедия

 
 
С хабра:

Что такое Тьюринговская трясина? Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.

Я частенько страдаю от желания пойти поплавать в этой трясине. Начинается всё с необходимости решить какую-то конкретную проблему. Я смотрю на существующие инструменты и вижу в каждом из них своих недостатки. И вот, забыв о первоначальной задаче, я уже набрасываю архитектуру универсального инструмента, который будет решать общий класс подобных задач, будет невероятно гибким, универсальными и… Особенно опасна эта трясина для создателей языков программирования. Есть огромный соблазн урезать язык до супер-элегантного и общего функционала, способного (в теории) решить любую задачу.

Тьюринговская трясина на самом деле встречается чаще, чем кажется. И ладно бы в неё затягивало лишь великие академические умы, решающие задачи вселенского масштаба. Но нет — универсальные инструменты стараются создавать все! Каждая программа по записи DVD зачем-то обзаводится своими аудио\видео\фото-редакторами, средствами создания обложек, плеерами и конверторами. Каждый мессенджер считаем своим долгом поддерживать все возможные протоколы связи, вплоть до электронной почты, социальных сетей, СМС, бумажных писем и отправки сообщений внеземным цивилизациям. Все операционки лезут на все типы устройств, каждый кодек-пак включает в себя тонну хлама, документация на некоторые консольные программы имеет по 150 страниц формата А4 и пару тысяч ключей командной строки. Каждый второй сайт в интернете обрастает мхом из погоды\гороскопов\знакомств\работы\чатов\форумов. Стараясь привлечь лишнего пользователя новой фичей, программы и сайты теряют десяток других, которые заколебались выискивать в образовавшейся куче хлама то рациональное зерно, ради которого когда-то эта программа или сайт были выбраны.

Серебряных пуль нет. Лично мне единственным способом не скатится из полезного узконаправленного средства в разрозненный набор малофункциональной чуши кажется система плагинов. Хорошими примерами являются современные браузеры, некоторые онлайн-игры, IDE и другие модульные программы (я уверен — вы сможете дополнить список), которые, оставаясь весьма аскетичными в своей основе, дают тем не менее возможность сотворить боевой комбайн любого уровня сложности.
Перед тем как добавить в свою программу новую фичу — подумайте, а нужна ли она хотя бы четверти пользователей? Если нет — может быть стоит просто вывести наружу API и дать возможность желающим написать и подключить плагин?

Хабр

 
 
В продуктовой разработке программных продуктов широкого потребления, отличный результат выглядит просто и лаконично. Вот так:
gmail

Кнопка создания нового письма, список почтовых папок, окошко мессенджера, поле с заголовками писем. Если есть необходимость расширить функционал, можно подключить модуль из «Лаборатории» или поставить какое-нибудь браузерное расширение.
 
 
Или вот так:
telegram

Тоже ничего лишнего. Разительный контраст с раздувшимся Qip, в контакт-листе которого может быть всё, что угодно, от робота википедии до видео с котиками, плюс 100500 различных протоколов с метаконтактами, которые всё время норовят рассыпаться и требуют периодического причёсывания.
 
 
Также можно сделать такое:
nero
А как болванку-то записать?
 
 
С бизнес-приложениями или специализированным софтом примерно та же история. Не так давно наблюдал автоматизацию крупного производителя. Абсолютно неуниверсальное решение. «Прибитая гвоздями» в процедурах и шарповых сервисах бизнес-логика. Минус — там ничего нельзя перенастроить, покликав мышью. Плюс — скорость работы, устойчивость, нетребовательность к ресурсам и весьма короткие сроки разработки. А если что-либо нужно перенастроить, разработчик может сделать это достаточно быстро.

До сих пор нахожусь под впечатлением от этого проекта, разительно отличающегося от других, проведённых по традиционным универсальным схемам. Он, чёрт возьми, эффективен.

Вывод: Главное при разработке инструмента — вовремя остановиться на необходимом и достаточном варианте реализации, не плодя лишнюю универсальность в ущерб ясности способа решения изначальной задачи.


Опубликовано

в

от