Skip to content

Instantly share code, notes, and snippets.

@ai
Last active June 19, 2023 16:47
Show Gist options
  • Save ai/473dd603baa92d5c8590f3573514c7a1 to your computer and use it in GitHub Desktop.
Save ai/473dd603baa92d5c8590f3573514c7a1 to your computer and use it in GitHub Desktop.

Принципы разработки Амплифера

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

Ценности

  1. Пользователь. Если что-то сильно мешает UX или есть критическая ошибка, то в первую очередь мы спасаем пользователей. Для этого иногда надо взять ответственность на себя, переубедить толпу, написать плохой код.
  2. Деньги. Если есть задача, которая напрямую и скоро может повлиять на доход (и вы понимаете как) — можно допустить снижения качества кода.
  3. Технический долг. С плохим качеством кода функции пишутся медленно, а баги множатся. Заботиться о качестве кода — это важно для бизнеса.
  4. Субординация. Все таски начальства, от которых не видно прямого дохода. Улучшения для пользователей, которые их не спасают прямо сейчас.

Важные следствия этих ценностей:

  • Дизайн важен для команды в фронтенда. Мы изучаем принципы дизайна, спрашиваем у дизайнера про логику UI. Не боимся думать сами и создавать дизайн, когда дизайнер не может помочь. Страхуем его от ошибок.
  • Мы ведём политические игры, продвигая свои решения как в UX, так и приоритетах разработки.

Технологии и зависимости

На что мы смотрим, при выборе:

  1. Насколько решение подходит именно для этой задачи.
  2. Количество открытых issue и как быстро их закрывают.
  3. Размер решения, особенно JS-кода.
  4. Количество расширений.

На что мы не смотрим:

  1. Количество загрузок, пользователей или звёзд на GitHub.
  2. Популярность решения в руководствах.
  3. Мнение профессионалов.

Мы не боимся писать свои решения. Своё решение пишем, если:

  1. Нет нужного решения. Например, не было UI kit с поддержкой медиа-выражений.
  2. Если старое решение заброшено. Например, Автопрефиксер был начат, из-за заброшенности Compass.
  3. Если решение простое для нашего случая, но создание универсального решения требует слишком сложной архитектуры. Например, у нас свой роутер.
  4. Если подходящее решение слишком большое. Например, Nano ID был написан, так как другие были большие.

Важные принципы работы с опенсорсом:

  1. Если при обновлении произошла ошибка, то надо минимум 30 минут попытаться разобраться в причинах.
  2. Если в зависимости есть ошибка, то надо открыть issue. Даже если не понятна причина.

Что проверяем после создания большой фичи

  1. Смотрим мелочи UI — ховеры, нажатие, семантика.
  2. Смотрим размер JS и картинок. Если ли способы (которые делать быстрее пару дней), чтобы сделать загрузку быстрее.
  3. Смотрим производительность. Как много перерисовок Реакта? Насколько большие области перерисовки Реакта и браузера? Как часто Логакс вызывает редьюссер? Как много экшенов и подписок создаётся в Логаксе?
  4. Быстро кликаем, запускаем и останавливаем анимацию, делаем странные поступки в интерфейсе, смотрим правильно ли ведёт себя интерфейс в разных условиях.
  5. Пытаемся взглянуть на интерфейс глазами нового пользователя. Пытаемся пройти весь путь от регистрации в проекте и до активации функции. Есть ли сложные моменты, если, например, не будет соц. аккаунтов.
  6. Проверяем работу на реальном соединении. Что будет если с сервера придёт ошибка? Что если нет интернета? Везде ли есть «крутилки»? Что будет если будет конфликт редактирования?
  7. Проверяем UI на шум. Можно ли анимации сделать быстрее? Не скачит ли контент при изменении состояния, что его надо искать? Если операция частая, то можно ли её сделать очень быстро.
  8. Проверяем покрытие тестами и состояниями в UIBook. Тесты не должны сильно привязаны в реализации.
  9. Хорошие практики UI для Логакса. Что будет, если не будет связи. Можно ли сделать оптимистичный UI? Будет ли автоматическое обновление состояния во вкладках и на разных клиентах? В случае любых вопросов, пишем Ситнику.
  10. Смотрим на доступность. Но не фанатично — это мы делаем для себя (на свою старость).

Если при код-ревью постоянно появляются однотипные ошибки — надо создать линтер для них.

@artemjackson
Copy link

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

Поясните, пожалуйста, этот пункт. Что вы делаете, если приходит такая задача, преимущества которой не ясно?

меняете компанию :)

@ai
Copy link
Author

ai commented Sep 20, 2019

Поясните, пожалуйста, этот пункт. Что вы делаете, если приходит такая задача, преимущества которой не ясно?

Говорим с начальством. Спрашиваем почему они считают, что она важна для бизнеса. Разбираемся в бизнесе. Если уверены, что они не правы, переубеждаем.

@boytsovevg
Copy link

Поясните, пожалуйста, этот пункт. Что вы делаете, если приходит такая задача, преимущества которой не ясно?

Говорим с начальством. Спрашиваем почему они считают, что она важна для бизнеса. Разбираемся в бизнесе. Если уверены, что они не правы, переубеждаем.

Спасибо. Сначала не ясно было, какую ценность это представляет.
Имеется в виду, что все требования руководства ценно? (потому что не всегда известно стратегическое мышление руководства)

@rkhaslarov
Copy link

rkhaslarov commented Sep 20, 2019

Смотрим размер JS и картинок.

Думаю, не только на размер, но и на необходимость загрузки того или иного chunk-а, может можно его загрузить позже и т.д.

@ai
Copy link
Author

ai commented Sep 20, 2019

Имеется в виду, что все требования руководства ценно? (потому что не всегда известно стратегическое мышление руководства)

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment