Если совсем коротко, то задачу из заголовка решают при помощи Tampermonkey.
Если кто вдруг не сталкивался, то Tampermonkey – это браузерное расширение, позволяющее модифицировать страницу произвольным образом при помощи самописных скриптов на джаваскрипте. Такие скрипты имеют доступ к коду страницы вне зависимости от ограничений безопасности, задаваемых сервером (CSP и другие).
Это, на первый взгляд, предельно убогое решение («неужели в Амазоне не найти разработчиков допилить сервис нормально»), удивительно хорошо решает задачу, и имеет несколько приятных плюсов, которыми я хочу с вами поделиться.
Но сначала пару слов обо мне. Меня зовут Андрей Столбовский, я пять лет проработал в Яндексе над различными инфраструктурными сервисами, а теперь работаю в AWS примерно над тем же. Так что к теме, о которой идёт речь, имея самое непосредственное отношение.
Основная проблема любого внутреннего сервиса в большой айти-компании – задач и хотелок дофига, ресурсов страшно не хватает и приоритет всегда у внешних продуктов. Несмотря на то, что нередко пользователи сервиса те же разработчики, только со стороны, даже если кто-то из них захочет самостоятельно запилить фичу, стоимость погружения в конкретную кодовую базу и инструменты обычно сильно выше стоимости разработки самой фичи. При этом команда сервиса хочет, чтобы сделано было «качественно», не хуже, чем весь остальной код, а это нередко требует более значительных изменений или исследований, и не всегда сторонний разработчик может сделать это без участия кого-то из команды.
В итоге команды сидят на огромном бэклоге и страдают, что не могут сделать всем хорошо, а пользователи ноют, что их любимую фичу не делают и команда на них забила.
В Яндексе в моей эпсилон эту проблему не было принято как-то дополнительно решать. Ожидалось, что команда сама предпримет все необходимые усилия по должно приоритизации бэклога, и выбивание ресурсов из начальстсва, чтобы выполнить все важные для пользователей задачи. А если что-то никак не успевает, то качественно коммуницирует это пользователю.
В Амазоне же первым делом после выхода на работу меня послали ставить Tampermonkey и пачку скриптов, в основном для страницы профиля сотрудников, чтобы показывать грейд человека (в Амазоне они открыты для всех), календарь сразу же на странице и статистику коммитов.
Первая мысль была «чего?…». После Яндекса с его симпатичными, пусть и местами подустаревшими, а главное – очень функциональными интерфейсами внутренних инструментов я не мог представить, что в компании на пару порядков больше те же внутренние инструменты – личный профиль сотрудника, вики, поиск – могут быть на не те же пару порядков круче, и что у них нет таких фич из коробки.
В итоге, как выяснилось, тут это очень стандартная практика – когда кому-то не хватает какой-то фичи, он не гундит в бэклоге, не обличает во внутренном блоге и не вопит «доколе!» на общей встрече. Он открывает Tampermoney, и фигачит скрипт, вот как наши прадеды до революции писали – простыня jQuery, window.setTimeout и так далее. Дальше он это выкладывает куда-нибудь к себе на Вики, пользуется сам и рекомендует другим.
Если штука востребованные, то у неё находится и контрибьюторов, и мейнтейнеры, если человек уволиться, и начинают создавать каталоги подобных инструментов в каких-то случайных местах. Какого-то официального централизованного каталога всех скриптов в Амазоне я не видел.
Помимо уже упомянутой страницы профиля, каким-то доработкам подвергается практически любая система:
в системе выкладки раскрашивают этапы по возрасту выкаченных на них релизов
мониторинговый tampermonkey позволяет из встроенного на wiki-страничку графика сделать скриншот
даже внутренняя консоль Redshift, над которой работает моя команда, тоже подвергся значительным доработка со стороны энтузиастов: люди напили всякие полезняшки типа отправки коммента в тикет прямо со странички
самый эпичный скрипт в моем личном рейтинге – это выгрузка Quip-документа на страничку. Quip – это сторонний сервис документов типа гуглодоков или Notion. Сделано максимально похоже на функциональность самого Quip, вообще не ощущается как сторонний скрипт, но при этом подобной функции, конечно же, там никогда не будет.
Но это же трэш и угар, скажете вы. А как же дублирование усилий? А как же безопасность? А как же поломка скриптов при изменении кода сервиса? А как же концептуальная целостность сервиса?
Я тоже так сначала подумал. Но, имея возможность сравнить два мира – Яндекс и Амазон – пришёл к выводу, что гораздо лучше иметь пусть кривенький и косонький скрипт, который решает реальную задачу уже сейчас, чем тикет в бэклоге у команды с парой сотней +1 и списком подписавшихся в десятки экранов. Done is better than perfect.
Ложка дёгтя заключается в том, что далеко не всегда даже после того, как скрипт приобретает огромную популярность, команда реализует эту фичу нативно. Работает же? Ну и зачем тратить силы переимплементировать.
В остальном всё работает нормально, энтузиасты подтюнивают скрипты при поломке, значительного дублирования усилий нет, хороший скрипт обычно известен всем. То, что в сервисе появляются какие-то странные «костыли сбоку», не так страшно, внутренние сервисы далеко не всегда обладают хорошей информационной архитектурой, выверенным дизайном и комфортным UX. Даже если в это инвестируют на старте, не всегда эти инвестиции сохраняются по ходу развития и продукт всё равно расползается в стороны. Инвестиции во внутренний продукт всегда сложнее оправдать, защитить и сохранить.
Ещё у этого метода есть артефакты, когда человека спрашивают, где он узнал ту или иную информацию, а он говорит «так на странице профиля же», а это скрипт. Или когда он заводит в сервис тикет, что у вас вчера была фича, а сегодня сломалась. И команда недоумевает, что за фича, никто не видел. А это тоже скрипт. Но происходит это редко, я такое видел всего 2 раза за год.
Не всё в принципе можно реализовать изнутри. Тот же Quip – сторонняя разработка, туда при всём желании не покоммитишь. Можно пытаться вообще все инструменты реализовать внутри, конечно, но у этого пути есть свои очевидные недостатки.
Для того, чтобы это всё работало, сервисы со своей стороны поддерживают нормальные CORS, позволяющие делать к ним запросы.
За безопасность такого подхода не скажу – не знаю деталей, но в Амазоне вообще безопасность реально на первом месте, так что думаю, что это поревьюено и благословлено безопасниками, а значит, не несёт слишком больших рисков.
Резюмируя, как бы странно это не выглядело со стороны, это прагматичный и на удивление очень неплохо работающий способ допиливать напильником сервисы. Рекомендую придушить внутреннего перфекциониста и попробовать, если у вас в компании тоже есть такие проблемы.
(Я ещё веду телеграм-канал, где потихоньку пишу всякое разное о работе – приглашаю подписаться.)
