Как капитализм может помочь техническому отделу большой компании

В мою коллекцию материалов о разработке фронтенда в реальных компаниях недавно прислали пулреквест с рекомендацией статьи Free-market software development Мэтта Чедбёрна из Financial Times (ранее The Guardian и BBC). Я проникся этой статьёй, потому что она совпадает с моими наблюдениями за время работы в Avito.

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

Навязывание внутренних решений может повлечь за собой демотивацию продуктовых разработчиков и потерю ориентиров у инфраструктурных команд. Продуктовым разработчикам не во всех случаях может подходить внутреннее решение, а отсутствие выбора снижает мотивацию. Инфраструктурные команды выступают в роли монополистов, а без конкуренции развиваться сложнее.

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

Во второй части статьи Мэтт рассказывает о том, что инфраструктурные команды в таких условиях должны стремиться к уровню SaaS: не просто разрабатывать внутренний продукт, но и продвигать его, документировать, помогать пользователям с проблемами. Отличным примером служит сервис полифилов Financial Times, изначально разработанный для внутренних нужд. Он настолько классно оформлен как продукт, что его сделали доступным снаружи компании и выложили в опенсорс.

В одной из статей Яндекса наткнулся на иллюстрацию к одному из их заданий на собеседованиях: сверстать такую иконку, используя минимальное количество HTML-элементов

Саму сову верстать не нужно, если что. Основные сложности в выносном счётчике и в поддержке произвольного цвета заливки

О пользе (или её отсутствии) тестирования Реакт-компонентов

Наткнулся на очередную статью о юнит-тестировании Реакт-компонентов. К сожалению, в таких статьях часто призывают бросать всё и начинать тестировать компоненты, но редко объясняют, зачем и кому это нужно. Попробую восполнить этот пробел.

Можно разделить тестирование компонентов на два вида: снепшотное тестирование разметки компонентов и тестирование логики компонентов.

Снепшотное тестирование комопнентов

Снепшотное тестирование разметки компонентов — довольно бесполезная вещь в подавляющем большинстве случаев. Оно полезно, если вы разрабатываете общую библиотеку компонентов в крупной компании вроде Яндекса или Авито. А если вы продуктовый разработчик, такие тесты себя не окупят — они слишком низкоуровневые. Они отслеживают только изменения разметки компонентов, а по одному только диффу разметки скорее всего будет сложно сказать, поломается ли компонент в браузере пользователя.

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

Тестирование логики компонентов

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

TL; DR: юнит-тесты компонентов слишком низкоуровневые, поэтому лучше пишите автотесты на логику, а интерфейс тестируйте скриншотами.

Концепция дейтпикера для быстрого выбора даты в очень большом диапазоне (да, там перепутаны октябрь и ноябрь) — http://review.dev64.net/dp/

— Давайте добавим в JavaScript Array.prototype.flatten?
— Давайте! Ой, не получится... Это сломает сайты, сделанные на библиотеке MooTools восьмилетней давности, которая патчила прототипы нативных объектов. Нужно переименовать flatten в smoosh!

https://github.com/tc39/proposal-flatMap/pull/56

Prettier

Prettier — инструмент форматирования кода c поддержкой множества языков, минимумом конфигурации и максимумом навязанных правил.

Изначально я к нему отнёсся очень скептически, считая, что мне достаточно eslint-конфига от Airbnb. Я считал, что всё, что с ним не совпадает — ересь. Несколько недель назад я всё же решился попробовать Prettier, и не зря.

Prettier отлично сочетается с любым конфигом eslint, разделяя ответственность: за форматирование отвечает Prettier, за умными штуками вроде неиспользуемых переменных следит eslint.

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

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

Не нужно читать технические книги, потому что они быстро устаревают (нет)

Если вы считаете, что техническая литература быстро устаревает, значит вы читаете не ту литературу.

Это касается не только литературы. Если какая-то технология быстро устаревает, значит она недостойна внимания. Вы же не хотите прожить жизнь в погоне за хайпом, упуская действительно важные вещи?

Я не призываю прекращать следить за новыми технологиями, просто этому не нужно уделять много внимания. Вышел новый фреймворк? Да и фиг с ним, скорее всего через полгода никто о нём не вспомнит. А если он действительно чего-то стоит, о нём продолжат говорить и вы это заметите.

Что касается книг: конечно, они быстро устаревают, если они об инструментах (библиотеках, фреймворках, etc). Читайте проверенные временем книги, посвящённые подходам и концепциям, а не инструментам. Например, «Алгоритмы» Томаса Кормена впервые изданы в 1990 (28 лет назад), а СИКП в 1985 (33 года назад). Несмотря на это, новые издания этих книг до сих пор можно найти в книжных, их читают и советуют.

Кстати, слежение за обычными новостями (не о программировании, а о жизни) только добавляет тревожности и не даёт ничего взамен. Необязательно быть в курсе всех новостей; если произойдёт что-то важное, вы и так об этом узнаете от родственников/друзей/коллег/прохожих.

Не спешите обновлять библиотеки

Пару часов назад вышел mobx 4, я прочитал ченджлог и радостно решил обновиться. И сразу же обнаружил, что в релизе поломаны аннотации типов для flow.

Та же история у меня была с обновлением Реакта с 15.5.x до 15.6.0: я в день релиза обновился в рамках одной из рабочих задач, и вечером тестировщица вернула мне задачу с комментарием «на ios не работает». Проблема оказалась в коде Реакта, её пофиксили через два дня в версии 15.6.1.

Мораль проста — в любом крупном (и даже не очень) релизе есть баги. Так что если в вас нет духа авантюризма, перед обновлением мажорной версии любой библиотеки ждите пару недель, пока не исправят упущенные проблемы.

Учебник по основам теории музыки с классными интерактивными визуализациями — https://www.lightnote.co/

Тесты — отличная возможность на практике попробовать async/await, не трогая клиентский код и не заморачиваясь с подключением полифилов

javascript:void(0)

Очень распространённая ошибка доступности, которая встречается даже в популярных библиотеках — использование ссылок с href="javascript:void(0)". С точки зрения семантики и доступности такие ссылки не имеют никакого смысла. Вместо них нужно использовать обычные кнопки.

Запомните простое правило: если при нажатии должен меняться URL, это <a>. Во всех остальных случаях используйте <button>.

Напоминание от Николая: кнопка без явно заданного type="button", оказавшаяся внутри формы, при нажатии отправит эту форму

важное замечание, у button всегда надо указывать type="button" иначе кнопка будет вести себя как type="submit"

​​Менеджер продукта по мнению Яндекса:
1. Постоянно пользуется своим продуктом и продуктами конкурентов.
2. Тестирует свой и чужие продукты на других людях.
3. Рассказывает участникам команды и заказчикам, что и зачем они делают.
4. Болеет за качество и умеет убеждать участников команды держать нужную планку.
5. Оценивает и приоритизирует задачи по соотношению «цена/польза».

Программистам ничего не мешает разделить с продактами как минимум 1, 4 и 5 компетенции ;–)

​​Наткнулся на генетический тест «Атлас». Сдаёте образец слюны, ждёте 8 недель и получаете подробные и понятно оформленные результаты анализа вашей ДНК: от происхождения и предрасположенности к каким-либо заболеваниям до рекомендаций по питанию и спорту. Выглядит очень круто — https://atlas.ru/gentest/

Наконец дошло дело до предложения по добавлению опциональной статической типизации в JavaScript.

Пока предлагают добавить только enum и примитивные типы, от которых будет не очень много пользы, но это хороший первый шаг — https://github.com/sirisian/ecmascript-types

​​Нейромаркетологи добрались и до технологий: Фейсбук, Инстаграм и другие продукты захватывают наше внимание всеми правдами и неправдами. Хороший обзор эксплуатируемых биологических механизмов и способов защиты — https://knife.media/dopamine-loop/