Как написать живучий стандарт

Опубликовано:
Комментарии:Telegram

Все USB-разъемы одинаковые, поэтому в них можно воткнуть разные устройства, от флешек до видеокамер. USB — это хороший стандарт. Он определяет как системы соединяются, а не из чего они сделаны. Польза от стандартизации разъёмов очевидна, но попытка стандартизировать микросхемы внутри флешек выглядела бы абсурдно. Однако в разработке такой абсурд встречается часто, люди пытаются стандартизировать внутреннее содержание, а не интерфейс.

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

Типичный результат запроса «architecture diagram» в Google.

Гораздо важнее то, что остаётся между прямоугольниками — стрелки взаимодействий. Доходит до смешного, в большинстве примеров архитектурных диаграмм в Интернете нет ни одной подписи к стрелочкам, как на картинке выше. Тем временем стрелочки переживают переписывание систем с нуля, в отличие от прямоугольников. Короче, стандарты должны быть про стрелочки, а не про прямоугольники. Это гарантирует половину успеха стандарта.

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

Хорошо, когда стандарт полезный и написан про интерфейс.

  1. Записываемся на стандартизацию
  2. Как написать живучий стандарт