Заметки с тегом «Технологии»

Будучи разработчиком, я не любил GraphQL с самого его появления — из-за ноды, привязки к Apollo, отсутствия APM (если не покупать подписку у Apollo) и сложного, вложенного языка запросов. В принципе до сих пор ничего изменилось, но в этом посте я хочу отдельно поговорить о своей любимой теме – тестировании.

GraphQL замечательно умеет делать одну вещь: вытаскивать данные с сервера в произвольном формате, удобном в каждый конкретный момент. «Выгрузи мне все книги — название, количество страниц, пару интересных цитат и автора, а у каждого автора покажи ФИО, фотографию и список популярных произведений» — это типичный запрос для GraphQL, с которым он справляется идеально. В REST для такой специфичной выборки пришлось бы писать отдельный эндпоинт, следить за ним и поддерживать. А тут даже кода писать не надо — один раз описал схему данных, и всё работает из коробки.

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

Сложно тестировать не только контракты, но и прозводительность. Раньше мы для каждого эндпоинта могли предсказать количество тяжёлых запросов с джоинами, и даже ограничить их количество в тестах или в рантайме (по ссылкам питон, в вашем стеке будут другие инструменты). Теперь мы каждый раз не знаем, что у нас запросят, а значит можно выгрузить хоть всю базу за один запрос.

Конечно, есть бизнесы, которые выигрывают от умения отдавать по 20 сущностей на один запрос, и делают это своей core-ценностью — к примеру облачные BaaS или высокоуровневые headless CMS вроде Sanity. Но если вам надо просто отдавать на фронт десяток известных сущностей, даже если вы планируете добавить в будущем ещё пару десятков — скорее всего GraphQL обойдётся вам намного дороже чем обычный REST, потому что с самого старта вам придётся тратить намного больше сил на тесты.

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

С одной стороны ребят можно понять — хочется больше практиковаться в новых технологиях: когда пришёл на проект, где всё уже работает, самый хороший способ изучить его технологии— воспроизвести с нуля на соседнем проекте. Да и индустрия давит — парочка хайповых технологий в резюме привлечёт больше сорсеров, чем умение решать задачи за 300 строк вместо 30 000, которое, к тому же, никак не проверишь без собеседования.

Если планируете развиваться в кого-то кроме деда, годами не вылезающего из своего единственного проекта, такой оверижиниринг для вас — стратегическая ошибка. Технологии — это хард-скиллы. Сегодня RabbitMQ, завтра BunnyPQ или RussMessageOchered: всё это учится за 1–2 недели при желании. А вот умение писать мало кода — это целый сложный софт-скилл: тут и в бизнес-задаче надо разобраться, и изобретать уметь, и заказчику продать свои изобретения. За пару недель не освоишь.

Софт-скиллы качать всегда выгоднее, чем хардскиллы — технологии меняются, а ваша голова и опыт остаются. Так что если на работе достался небольшой проект без ограничений — постарайтесь на нём написать меньше кода, а не больше.

С 2018 года я публично ругаю привычку многих админов тащить с собой ИТ-инфраструктуру: поднимать локальные GitLab и Sentry, использовать собственные сервисы вместо PaaS, DBaaS и прочих -aaS. Вот пост об анализаторах логов и огородиках, с которого всё началось.

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

В использовании заёмной инфраструктуры всегда есть риски. Текущие события — всего лишь один из большого количества рисков: подводные лодки рвут морские кабели, бандиты вламываются в датацентры, а ваш поставщик услуг просто молча отваливается на две недели. Вообще, все наши ИТ-шные риски — это тоже только часть угроз, которые нависают на бизнесом: есть ещё финансовые, правовые и репутационные риски.

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

По мере роста владельцы защищаются от рисков — нанимают больше профессионалов, забирают себе больше инфраструктуры, выходят на другие рынки, чтобы диверсифицировать бизнес. Точно такая же картина и с SaaS-ами. Если вы стартап — у вас по прежнему нет ресурсов на операционную поддержку собственных огородиков. По мере роста вы становитесь всё более и более независимы. Когда дорастаете до Амазона — строите собственные датацентры.

После 24 февраля поменялся только набор SaaS — больше нет Mailchimp, Slack или продуктов Atlassian. Но у всех этих сервисов есть менее крупные аналоги, которые продолжают работать с русскими. Да и отечественный производитель не отстаёт — у большинства сервисов уже есть замены. И пусть эти замены обычно выглядят как жигули, и от езды на них болит спина — они всё равно снимают с бизнеса огромное количество нагрузки: вам не нужно мониторить серверы, обновлять версии ПО, разбираться в протоколах взаимодействия сервисов друг с другом.

Так что огородики — это норм, если вы можете себе позволить не есть огурцы с рынка. А если не можете — для вас картина сильно не поменялась.

Это — заметка для программистов. Если вы менеджер — почитайте версию для менеджеров.

Многие ребята, выбирая инструменты для нового проекта, начинают строить длинные таблицы, сравнивая фичи. Серьёзно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.

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

А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта сейчас. Подумайте лучше о том, каким будет ваш фреймворк потом. Удержит ли он комьюнити в ближайшую пару лет? Успеет ли за быстроизменяющейся средой? Будет ли адекватным предложение на рынке труда?

Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends. И да, если вы выбираете фреймворк для фронтенда, то берите любой — всё равно протухнет через год.

Знаний всегда больше, чем можно выучить. А то, что выучивают айтишники, становится неактуальным в 10 раз быстрее, чем в других областях.

Посмотрите на историю серверной инфраструктуры: 20 лет назад были большие железные серверы. Сисадмины с важным видом настраивали RAID, патчили FreeBSD и выдавали программистам права доступа. Потом появились виртуальные машины — теперь, чтобы выкатить софт, стало не нужно думать про RAID-массивы и FreeBSD: нажал кнопочку и получил работающую машину.

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

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

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