Тут перечислены не законы, последние слово всегда за здравым смыслом. Тут перечислены лишь направление, куда надо стремиться. Принципы, которые должны помочь, когда не знаешь, что выбрать.
- Пользователь. Если что-то сильно мешает UX или есть критическая ошибка, то в первую очередь мы спасаем пользователей. Для этого иногда надо взять ответственность на себя, переубедить толпу, написать плохой код.
- Деньги. Если есть задача, которая напрямую и скоро может повлиять на доход (и вы понимаете как) — можно допустить снижения качества кода.
- Технический долг. С плохим качеством кода функции пишутся медленно, а баги множатся. Заботиться о качестве кода — это важно для бизнеса.
- Субординация. Все таски начальства, от которых не видно прямого дохода. Улучшения для пользователей, которые их не спасают прямо сейчас.
Важные следствия этих ценностей:
- Дизайн важен для команды в фронтенда. Мы изучаем принципы дизайна, спрашиваем у дизайнера про логику UI. Не боимся думать сами и создавать дизайн, когда дизайнер не может помочь. Страхуем его от ошибок.
- Мы ведём политические игры, продвигая свои решения как в UX, так и приоритетах разработки.
На что мы смотрим, при выборе:
- Насколько решение подходит именно для этой задачи.
- Количество открытых issue и как быстро их закрывают.
- Размер решения, особенно JS-кода.
- Количество расширений.
На что мы не смотрим:
- Количество загрузок, пользователей или звёзд на GitHub.
- Популярность решения в руководствах.
- Мнение профессионалов.
Мы не боимся писать свои решения. Своё решение пишем, если:
- Нет нужного решения. Например, не было UI kit с поддержкой медиа-выражений.
- Если старое решение заброшено. Например, Автопрефиксер был начат, из-за заброшенности Compass.
- Если решение простое для нашего случая, но создание универсального решения требует слишком сложной архитектуры. Например, у нас свой роутер.
- Если подходящее решение слишком большое. Например, Nano ID был написан, так как другие были большие.
Важные принципы работы с опенсорсом:
- Если при обновлении произошла ошибка, то надо минимум 30 минут попытаться разобраться в причинах.
- Если в зависимости есть ошибка, то надо открыть issue. Даже если не понятна причина.
- Смотрим мелочи UI — ховеры, нажатие, семантика.
- Смотрим размер JS и картинок. Если ли способы (которые делать быстрее пару дней), чтобы сделать загрузку быстрее.
- Смотрим производительность. Как много перерисовок Реакта? Насколько большие области перерисовки Реакта и браузера? Как часто Логакс вызывает редьюссер? Как много экшенов и подписок создаётся в Логаксе?
- Быстро кликаем, запускаем и останавливаем анимацию, делаем странные поступки в интерфейсе, смотрим правильно ли ведёт себя интерфейс в разных условиях.
- Пытаемся взглянуть на интерфейс глазами нового пользователя. Пытаемся пройти весь путь от регистрации в проекте и до активации функции. Есть ли сложные моменты, если, например, не будет соц. аккаунтов.
- Проверяем работу на реальном соединении. Что будет если с сервера придёт ошибка? Что если нет интернета? Везде ли есть «крутилки»? Что будет если будет конфликт редактирования?
- Проверяем UI на шум. Можно ли анимации сделать быстрее? Не скачит ли контент при изменении состояния, что его надо искать? Если операция частая, то можно ли её сделать очень быстро.
- Проверяем покрытие тестами и состояниями в UIBook. Тесты не должны сильно привязаны в реализации.
- Хорошие практики UI для Логакса. Что будет, если не будет связи. Можно ли сделать оптимистичный UI? Будет ли автоматическое обновление состояния во вкладках и на разных клиентах? В случае любых вопросов, пишем Ситнику.
- Смотрим на доступность. Но не фанатично — это мы делаем для себя (на свою старость).
Если при код-ревью постоянно появляются однотипные ошибки — надо создать линтер для них.
Хорошо, что понимаете политику в разработке!
По моему опыту, большинство проблем не в технологиях, а в людях (договориться, приоритизировать).