От Редакса к хукам

В Реакте в версии 16.7.0 появились Hooks (дальше по тексту — хуки). Это API, которое позволяет использовать локальный стейт без использования классов. И среди них есть один, который, как мне кажется, может заменить собой Редакс.

В этой статье я предполагаю, что вы знаете разницу между функциональными компонентами и классами, в курсе о локальном стейте и жизненном цикле компонентов и о том, как работает Редакс. Без этого вникнуть будет трудно, но всё в одну статью я бы не уместил, так что вот ¯\_(ツ)_/¯

Что за хуки?

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

Например, здесь мы используем хук useState, чтобы создать и использовать переменную counter:

import React, {useState} from 'react'
const SimpleComponent = () => {
  const [counter, setCounter] = useState(0)
  // в первый раз значение counter будет равно тому, что мы передаём в useState
  // затем — тому, что мы установим через setCounter
  return <div>{counter}</div>
}

useState возвращает кортеж из значения и функции, которая будет это значение обновлять.

Из‑за того, что в одном компоненте можно использовать несколько хуков по несколько раз, у них есть ограничения и правила. Подробнее об этом написано в документации и рассказано в докладе на Реакт‑конфе.

useReducer

useReducer — это хук, который по принципу работы схож с редьюсерами из Редакса.

const App = () => {
  const [state, dispatch] = useReducer(reducer, initialState)
  // initialState — начальное состояние
  // reducer — функция, которая принимает state и action 
  //           и обрабатывает изменение состояния
  //
  // state — текущее состояние
  // dispatch — функция, которая будет дёргать экшены, 
  //            чтобы обновить состояние

  return <div>Hello world</div>
}

По принципу работы это и есть Редакс. Проблема только в том, что переменные state и dispatch находятся внутри области видимости функции App, а значит использовать этот редьюсер в других компонентах у нас не получится.

…Если только мы не используем контекст.

Context API

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

Это работает, но если дерево большое, то и пробрасывать пропсы приходится через каждый уровень вложенности. Возникает так называемый prop drilling. Схематично это выглядит, как на картинке слева:

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

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

import {createContext} from 'react'
// создаём контекст
const StoreContext = createContext()

const App = () => (
  // через провайдер в свойстве value указываем значение,
  // которое нам надо хранить и как-то использовать в других компонентах
  <StoreContext.Provider value={{meaningOfLife: 42}}>
    <OtherComponent />
  </StoreContext.Provider>
)

const OtherComponent = () => {
  <StoreContext.Consumer>
    // через консьюмер получаем доступ к значению
    {({meaningOfLife}) => (
      <div>{meaningOfLife}</div>
    )}
  </StoreContext.Consumer>
}

Вызывать консьюмер можно где угодно, и это позволяет делить состояние между компонентами. И тут возникает мысль, нельзя ли заменить Редакс на смесь хуков и контекста. Ну и эт, вроде, можно.

Пример

Я написал простенькое приложение с использованием Редакса и с использованием контекста и хуков. Это счётчик, значение которого можно менять кнопками, либо меняя значение в инпуте, а также обнулять его нажатием на кнопку из другого компонента.

По структуре оно будет состоять из корневого компонента App, компонента формы Form и ещё одного компонента с кнопкой внизу Display. Схематично можно изобразить так:

Компоненты Form и Display зависят от хранилища, в котором содержится состояние приложения. Все события кнопок и инпута вызывают экшены, которые будут обновлять хранилище.

С использованием Редакса

Вначале создадим хранилище и редьюсер, который будет заниматься его обновлением:

// reducers.js
import {combineReducers} from 'redux'

const app = (state, action) => {
  switch(action.type) {
    case 'PLUS':
      return {...state, counter: state.counter + 1}

    case 'MINUS':
      return {...state, counter: state.counter - 1}

    case 'MAGIC':
      return {...state, counter: Math.floor(Math.random() * 100)}

    case 'CHANGE':
      return {...state, counter: +action.value}

    case 'RESET':
      return {...initialState}

    default:
      return state
  }
}

export default combineReducers({ app })

// index.js
import {createStore} from 'redux'
import rootReducer from './reducers'
import App from './App'

// создаём хранилище
const store = createStore(rootReducer)

// используем через провайдер
render(
  <Provider store={store}><App /></Provider>,
  document.getElementById('app'))

Дальше создадим экшены, которые будут вызываться событиями кнопок и инпута:

// actions.js
export const plus = () => ({ type: 'PLUS' })
export const minus = () => ({ type: 'MINUS' })
export const magic = () => ({ type: 'MAGIC' })
export const reset = () => ({ type: 'RESET' })
export const change = e => ({ 
  value: e.target.value,
  type: 'CHANGE', 
})

Чтобы привязать какой‑то компонент к хранилищу, используем connect:

import {connect} from 'react-redux'
import {reset} from './actions'

// app — часть хранилища;
// reset — экшен;
// всё это мы привязали через connect перед экспортом ниже
const Display = ({app, reset}) => {
  const {counter} = app

  return <footer>
    <p>Another component knows that counter equals to {counter} as well!</p>
    <p>
      It even can 
      <button onClick={reset}>reset the coutner</button>
    </p>
  </footer>
}

// мапим свойства из хранилища и экшены
// на пропсы компонента
export default connect(
  state => ({ app: state.app }),
  {reset}
)(Display)

В результате приложение будет работать так.

Контекст + хуки

Теперь напишем то же самое без использования Редакса. Используем useReducer:

// store.js
export const initialState = {counter: 0}

// редьюсер точно такой же, как в прошлый раз 
export const reducer = (state, action) => {
  switch(action.type) {
    // ...
  }
}

// index.js
import {reducer, initialState} from './store'

const App = () => {
  // создаём в корневом компоненте хранилище
  // и функцию для его обновления
  const [state, dispatch] = useReducer(reducer, initialState)
  return <div></div>
}

Чтобы пробросить значения из хранилища компонентам, воспользуемся контекстом:

// context.js
import {createContext} from 'react'
export const StoreContext = createContext()

// index.js
import {reducer, initialState} from './store'
// импортируем созданный контекст
import {StoreContext} from './context'

const App = () => {
  const [state, dispatch] = useReducer(reducer, initialState)

  // используем провайдер, чтобы передать в контекст 
  // хранилище и функцию для обновления
  return (
    <StoreContext.Provider value={{dispatch, state}}>
      <Form />
      <Display />
    </StoreContext.Provider>
  )
}

export default App

Чтобы привязать какой‑то компонент, используем консьюмер:

import React from 'react'
// импортируем контекст 
import {StoreContext} from './context'
// экшены точно такие же, как в прошлый раз
import {reset} from './actions'

const Display = () => (
  // получаем доступ к тому, что хранится в контексте
  <StoreContext.Consumer>
    // в нашем случае — state и dispatch
    {({state, dispatch}) => (
      <footer>
        // используем state, чтобы вывести значение счётчика
        <p>{state.counter}</p>
        // используем dispatch, чтобы дёрнуть экшен
        <button onClick={() => dispatch(reset())}>reset</button>
      </footer>
    )}
  </StoreContext.Consumer>
)

export default Display

А ещё можно сделать код чище, заменив консьюмер на useContext:

import React, {useContext} from 'react'
import {StoreContext} from './context'
import {reset} from './actions'

const Display = () => {
  // вызываем useContext, передавая аргументом нужный контекст
  const {state, dispatch} = useContext(StoreContext)

  return (
    // убираем консьюмер
    <footer>
      <p>{state.counter}</p>
      <button onClick={() => dispatch(reset())}>reset</button>
    </footer>
  )
}

export default Display

И работает оно точно так же.

А чо по весу и перформансу?

Я не удивился, когда бандл ужался на 12 кБ: с Редаксом — 166, без него — 154. Это логично, меньше зависимостей — меньше вес.

А вот прирост в скорости обработки экшенов и отрисовки меня слегка удивил. Я проводил измерения с помощью console.time и performance.measure. Средние значения за 100 итераций вышли такими:

 console.timeperformance.measure
Redux12 мс13 мс
Context + hooks9 мс8 мс

Минусы

Вызов экшенов стал чуть более многословным из‑за прямого использования dispatch. И если работать с контекстом без useContext, придётся использовать паттерн render‑prop, из‑за чего может подняться щит‑сторм ¯\_(ツ)_/¯

Но если серьёзно, хуки — пока что в стадии RFC, и возможно многое поменяется. Поэтому переписывать свои приложения на них не советует даже Дэн Абрамов. То есть это экспериментальная фигня.

Хотя выглядит всё равно заманчиво :–)

Ссылки

Документация

Доклады

Статьи со сравнениями

Измерения перформанса

Исходники и примеры

Новые правила деловой переписки. М. Ильяхов, Л. Сарычева

Эта книга не о словах и правилах, а об отношениях между людьми.

Да, в ней есть список фраз, которые в 2018 году режут людям слух, но нет рецептов типа «используй вот этот шаблон, и все клиенты твои». Ну ладно, по порядку.

Основная мысль

Если относиться к адресату уважительно, то и в ответ к вам будут относиться так же.

Книга не про слова, а про правильное отношение к людям

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

У нас есть цель: получить совет, назначить встречу, договориться о сотрудничестве. Добиться этой цели проще, если получателю будет приятно читать письмо

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

Об уважении к чужому времени

Целая глава посвящена письмам о срочных задачах, и том как о них пишут: «АСАП», «срочно», «нужно вчера» и вот это всё. Людям не нравится получать письма с такими пометками. Но дело не в самих словах, а в скрытом в них отношении к чужому времени.

Раздражает не слово «срочно», раздражает неуважение. …когда к твоему времени относятся как к расходному материалу. Раздражает, что менеджер может подгонять не из‑за срочности, а просто ради забавы… Всё это — неуважение, и всё это раздражает

Чтобы читателю было легче читать письмо, нам нужно проделать некоторую работу перед тем, как отправить письмо. Доступно назвать тему, указать срок задачи, выложить кратко суть в первом абзаце и прочее.

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

Чем больше работы мы проделаем за адресата, тем легче ему ответить, тем приятнее с нами сотрудничать

Не надо рассчитывать на почту, как на экстренный способ связи.

Всё, что в почте, по умолчанию не «горит». Если что‑то и правда «горит», оно не должно быть в почте

Об эмоциях и агрессии в переписке

Письма на эмоциях писать можно, нельзя — отправлять. Эмоциональное письмо может привести к необоснованному конфликту. Если вы сильно переживаете из‑за какой‑то проблемы, позвоните человеку или напишите в чат.

Как определить, что вы сейчас на эмоциях: если вам хочется показать, что вы спокойны и рассудительны — вы не спокойны и не рассудительны. Отправлять письмо в таком состоянии нельзя

В книге схемы «Когда писать письмо» нет, но её можно найти в лекции на ютубе: Когда писать и когда не писать письмо

В работе редко кто‑то вредит специально. Если кажется, что кто‑то ведет себя нехорошо, скорее всего…

Он не козёл, он просто не знает, как правильно

О праве на отказ

Да‑да, пошла песня про Кэмпа, но камон. Люди любят делать добрые дела и помогать другим людям. Мы социальны, и ощущение, что я помог кому‑то приносит удовольствие, а…

Когда мы даём человеку право на отказ, у него появляется больше поводов нам помочь

Особенно важно право на отказ в холодных письмах, где читатель ничего не должен. Он может даже не открывать письма. Задача таких писем — наладить контакт и выйти на связь, а не продать что‑то.

Об удобстве читателя

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

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

Про конфликт ваших принципов письма и удобства читателя.

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

О внимательности, границах, переходе на «ты»

О небрежном отношении к имени знаю из опыта — меня постоянно называют Алексеем, не надо так.

Если бы мы могли оставить в этой книге только одно правило, мы бы оставили вот это: внимательно с именем

Переходить на «ты» лучше при личной встрече. Главное, чтобы в переходе не было напряжения, иначе переход не нужен.

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

Гораздо безопаснее писать о том, что мы сами думаем и чувствуем, — а не лезть со своими оценками в душу другому

О манипуляциях и ситуациях «из ряда вон»

Самые неприятные письма — лицемерные и манипулятивные. Люди всегда видят, когда их пытаются обмануть или пытаются ими манипулировать. Им это не нравится. Если ситуация нестандартная, то надо это признать. Свои косяки тоже надо уметь признавать.

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

Лучше прямо сказать: «Я понимаю, что ситуация дурная». И дальше строить аргументацию, исходя из этого

Манипуляция — это когда человек втайне хочет чего‑то одного, а давит на оппонента в другом месте, чтобы тот сам сделал нужное

Об этике переписки

Не писать ничего, что нельзя переслать. В претензиях не переходить на личности и оценивать не человека, а работу и результат.

Не писать ничего, что нельзя переслать. Рабочая переписка не подходит для обсуждений за глаза. Всегда есть риск, что письмо получит не тот, кому оно предназначалось

Все претензии должны быть сделаны без переходов на личности, а оценить можно только работу, а не человека или его профессиональные качества

Об откликах на вакансии

Здесь всё снова упирается в человеческие отношения. Если письмо шаблонное и пытается просто закрыть вакансию, то работодатель скорее всего в нём пользы не увидит и не ответит.

У сопроводительного письма нет обязательной формы. Нет требований по формату и объему; необязательно пересказывать биографию… говорить о своей стрессоустойчивости, коммуникабельности, самообучаемости. Относитесь к этому письму не как к священному ритуалу, а как к общению человека с человеком. У одного проблема, у другого — решение. Они хотят договориться

Об ответах на хамские письма

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

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

Иногда принципы вашей компании могут не подходить кому‑то, это нормально. Это нужно объяснить, но не учить жизни или пытаться переубедить кого‑то. Это гиблое дело, ни к чему хорошему не приведёт.

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

О шаге навстречу

Книга предлагает в любой ситуации делать шаг навстречу человеку, с которым вы переписываетесь. По‑моему, это вообще универсальный принцип.

Вы наверняка заметили: почти в любом конфликте побеждает тот, кто первым делает шаг навстречу. Если человек на нас сердит, мы должны быть первыми, кто скажет ему: «Дружище, мы тебе не враги, а друзья. Чем тебе помочь? Как сделать тебе хорошо?» Это работает везде, во всех отношениях — хоть в семье, хоть на работе, хоть с боссом, хоть с клиентом. Побеждает тот, кто делает первый шаг навстречу

Ссылки

К этой книге:

Мимо пролетало:

Время для чтения есть всегда — 2

Это ремейк моего старого поста о чтении. В тот раз я почти не рассказал, что именно делаю, чтобы успевать много читать. Исправляюсь.

Большую часть приёмов я взял из лекции Людвига Быстроновского «Дизайн дизайнера». Советую её посмотреть, Людвиг там объясняет причины своих выводов и как к ним пришёл.

Я лишь пробегусь по тому, какие приёмы использую.

Читаю сразу несколько книг

Я не читаю одну книгу за раз, у меня всегда открыто несколько книг. На ноутбуке книги по программированию, на телефоне всё остальное.

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

Так я не устаю от одной и той же книги, и пропадает основная причина лениться: что якобы за книгой нужно куда‑то идти. Не нужно, всё всегда под рукой.

Не читаю неинтересные книги

Это уже баян, но неинтересные книги можно не читать. Как только я понимаю, что книга неинтересная, я её закрываю и откладываю на будущее.

Для меня есть разница между трудной книгой и неинтересной. Например, недавно я читал «Как понимать архитектуру» — в ней много терминов, которые по мнению авторов я уже должен знать. Мне пришлось читать её с открытым гуглом, потому что иначе я б ничего не понял.

Или «Урбанистика» Глазычева — похожа учебник для вузов, написанный академическим языком с предложениями по 3 страницы. Продираться сквозь язык было тяжело, но польза от книги перевешивала.

Эти книги трудные, но интересные, потому что хочется узнать, что в них дальше. Неинтересная же книга не захватывает вообще, и меня не тянет её снова открыть.

Не парюсь о количестве страниц

Раньше я выставлял себе суточный минимум в страницах. В какой‑то момент я заметил, что он превратился в суточный максимум: прочёл 50 страниц и с чувством выполненного долга закрыл книгу.

Сейчас не слежу за количеством, а просто читаю для удовольствия.

Читаю в перерыве между подходами в работе

В перерывах, если чувствую, что не сильно устал, читаю.

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

Читаю на досуге

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

Делаю перерывы в чтении

Читать постоянно напряжно, поэтому иногда я делаю перерывы на пару дней и не читаю вообще никаких книг.

Я понимаю, что пора делать перерыв, когда перестаю воспринимать то, что написано.

Например, у меня открыто 3 книги. Я начинаю читать первую, глаза по строкам бегут, а смысл ускользает. Останавливаюсь, открываю другую. Если с ней то же самое, открываю третью. Если не получается сосредоточиться и на третьей, то всё — пора делать перерыв.

Не читаю, если совсем не прёт

Бывает, что система даёт сбой, и мне не помогают даже перерывы. Когда‑то давно я парился над этим, но сейчас отношусь проще.

Если чувствую, что совсем ни на чём не получается сосредоточиться, то забиваю на книги полностью. Обычно желание читать возвращается само через неделю‑две, тогда и начинаю снова.

Что я понял за полтора года преподавания

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

Будьте аккуратнее с новыми терминами

Если вы объясняете новичкам незнакомые термины, то это стоит делать понятиями, которые им уже известны. Следовать этому правилу труднее, чем кажется.

При переходе из разработки в преподавание, многое кажется очевидным. Маржины схлопываются, флоты надо сбрасывать, у боди есть отступы по умолчанию. Разработчики к этому настолько привыкают, что перестают замечать.

Но как только вы начнёте объяснять это другим людям, у них вполне оправданно появится куча вопросов. Что за маржины, что значит «схлопываются», как сбрасывать флоты, зачем они нужны, откуда отступы, зачем они там?

Чтобы объяснить эти тонкости, надо использовать уже знакомые понятия. Потому что иначе вы не только не объясните, что хотели, но и отобьёте интерес к теме. Никому не хочется разбираться в непонятной фигне, по крайней мере — в чересчур непонятной.

Поэтому объяснение нового термина должно:

  • состоять из уже известных понятий;
  • быть последовательным, строиться от целого к частному либо наоборот.

Избегайте путаницы

Если у термина есть синонимы (флот ⇔ плавающий элемент), надо это пояснить на старте.

Можно также объяснить, почему эти термины взаимозаменяемы. (Флот переводится, как плавающий, а используется такой элемент, чтобы его «обтекал» текст. Поэтому он как бы плавающий, это такой грубый перевод.)

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

Автоматизируйте всё, что можно

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

Часть ошибок — заблуждения, которые возникают при погружении в тему. На такие ошибки стоит заранее приготовить развёрнутое объяснение, почему заблуждение — это именно заблуждение, и как решить задачу было бы правильнее.

Нетипичные ошибки более редкие. Они особенно важны, потому что как бы ставят под вопрос рациональность технологии. На них отвечать надо ещё более полно.

Грамотно объяснить сложные вещи, будучи уставшим, трудно. Именно чтобы не уставать от ответов на типичные ошибки, лучше на них заранее готовить развёрнутый ответ.

Объясняйте на примерах

Объяснение с примерами понятнее. Я пробовал объяснять и абстрактно, и на примерах — на примерах лучше.

Абстракция — ресурсозатратная штука. Даже чтобы представить что‑то уже знакомое, требуется внимание и сосредоточенность. Чтобы представить какое‑то новое понятие, ресурсов потребуется больше.

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

Делайте перерывы во время занятия

Во время объяснений стоит делать небольшие перерывы.

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

Ученикам перерыв даёт время передохнуть и восстановить внимание. Вам — перевести дыхание.

Стимулируйте обратную связь

Задавать вопросы страшно и неловко. Но вопросы надо поощрять и стимулировать. Часто перед ответом на вопрос я говорю, что вопрос хороший, логичный или правильный. Не знаю, насколько это снижает страх задавать вопросы, надеюсь, помогает.

Если вопрос задан расплывчато, и вам непонятно, как ответить, просто уточните, что имелось в виду. И, если в чём‑то сомневаетесь, не стесняйтесь гуглить прямо во время занятия. Я так и говорю: «не уверен, давайте прямо сейчас и загуглим».

Пейте воду во время занятия

Мне трудно долго говорить, особенно если приходится следить за таймингом и проговаривать слова быстро и громко. Поэтому я во время лекции иногда отвлекаюсь на глоток воды. Голос не садится к концу, а ещё это помогает сделать вынужденный перерыв.

Пить воду ещё можно, если чувствуете, что плывёте или сильно волнуетесь. Это работает как микротаймаут: пока пьёте воду, можно перевести дух, сформулировать мысль и продолжить.

Дозируйте время на ревью

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

Дело в монотонности, от неё надо избавляться. Чередовать темы, тасовать задачи, менять вид деятельности. Короче, делать всё, чтобы ревью не приедалось. Иначе отвечать свежо не получится и просто пропустить вопрос, на который стоит дать более развёрнутый ответ, или ошибку в решении.

Получайте пользу

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

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

Как мы делали «Фронтенд — это не больно!»

«Фронтенд — это не больно!» — длинная статья, цель которой помочь разработчикам научиться справляться с рутиной и получать удовольствие от работы. В этой заметке я расскажу, как появилась идея и почему этот проект для меня был важен.

Предпосылки

Когда‑то описанные в нём проблемы были у меня. Мне тоже казалось, что найти с дизайнерами общий язык очень трудно, объяснять что‑то менеджерам бесполезно, и проще переписать фронтенд, чем говорить с бекендом. Но со временем я стал умнее и понял, что дело не в команде, а в моём отношении к ситуации и проблемам.

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

Этого казалось мало, потому что теперь я очутился на другой стороне: видел других фронтендеров с теми же проблемами. У меня был опыт того, как начать работать без напряга. Я хотел им поделиться, но не знал как.

Идея

В феврале 2017 мне написал Вадим с идеей сделать доклад или лекцию для разработчиков о понимании дизайнеров. Мы хотели показать, что разработчики часто упарываются по технологиям, не замечают важного и злятся на дизайнеров. А было бы круто, если все работали сообща и понимали друг друга.

Вначале мы думали в сторону лекции или доклада, чтобы нам можно быть задать вопросы напрямую. Мы начали работать над этим, я набросал первые варианты текста и слайды, но что‑то было не то.

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

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

Тогда я написал Андрею и предложил вместе сделать серию статей. Андрей же предложил сделать нечто вроде пособия. Получилось — вот это.

Запуск, результаты и планы

Статья разлетелась по соцсетям, о ней написали Форвеб и Вебстандарты, обсудили в паре подскастов. Судя по всему, разработчикам она тоже понравилась. Мы даже получили несколько писем с благодарностями, надеемся кому‑то действительно помогло.

А недавно мы запустили шутливый аддон с вредными советами для разработчиков. Это пародия на детские книжки Остера только про разработку. Советы там действительно вредные, не следуйте им, пожалуйста :–)

Раньше ↓