Shameless plug: проект code-review-checklists/java-concurrency на Гитхабе содержит много советов из JCIP упакованных в форму применимую во время ревью кода с многопоточностью.

Спасибо за отличное интервью.

Олег: Интересно. Если взять, к примеру, какое-нибудь сообщество питонистов, то у них куда меньше культ производительности. Как получилось, что именно в нашем сообществе так происходит? Может, это вы спровоцировали культ перформанса своими докладами? Ты, Шипилев, Паньгин, Иванов и так далее.

Мне кажется, это очень интересный вопрос.

Во-первых, культ производительности определенно есть не только в Джаве: посмотрите доклады на конференциях по Go, С++, JavaScript — там тоже очень много докладов про производительность, и зачастую это самые посещаемые доклады.

Думаю, культ во многом связан с эго: "если я написал код быстрее, чем коллега, значит я круче/умнее". Посмотрите на заголовки проектов на Гитхабе: многие имеют вид "Fast(est) [Thing] for [Language]". Вдобавок, производительность относительно легко сравнивать.

Было бы интересно видеть в индустрии больше проектов с заголовками типа:

• "Very robust [Thing] for [Language]"
• "[Thing] for [Language] with minimum configuration parameters/completely automatic tuning"
• "[Thing] for [Language] with minimum resource (disk/memory/network) usage". Такое, кстати, иногда встречается, хотя реже, чем "fastest". Например, люди любят писать очень компактные реализации libc, см. musl и друзей.
• "[Thing] for [Language] with > 90% mutation testing coverage"

См. Deep Work & Digital Minimalism

https://shipilev.net/blog/2014/exceptional-performance/

Изначально был выбран неправильный тип метрики для решения задачи. Стандартный джентльменский набор для веб-сервисов:

1. cumulative counter для числа обработанных запросов, отображать как rate
2. cumulative counter для числа ошибок (с разбивкой по типу ошибки), отображать как rate
3. histogram для времени обработки запросов, отображать как процентили
4. gauge для requests in flight, отображать, как есть

Сочетание 3 и 4 дало бы вам совершенно четкую картину вашей аварии: рост latency и рост числа запросов in flight.

Мой личный список вопросов работодателю (если не было освещено на собеседовании).

Чем я буду заниматься? Только узкими обязанностями или еще и смежными?
Какой стек на моём проекте? Есть ли легаси?
Что с тестированием
Есть ли CI/CD и девопс инженер?
Будет ли единый ПМ и четко заданный жизненный цикл таска?
Есть ли БА?
Системы мониторинга, сборщик логов?
Переработки бывают? Оплата?
Системы трекинга времени и руткиты на рабочем компе?
Отпуска: дробление отпуска, включены или нет выходные, за сколько нужно предупреждать, отказы
За что и как часто получаются премии? Кто определяет их размер?
Есть ли СБ? Какие требования у СБ?
Почему открыта вакансия? Если не новая, то куда ушел предыдущий разработчик?
Аналогично про гибкий график, карьерный рост. Что это значит и в чем выражается.
Ретроспектива.
Код ревью в компании: кто, как долго, что если пожар.

В случае с опционами обычно контракт предполагает 4 года на весь пакет акций, с возможностью забирать частями после первого года ("one year cliff"). Т.е. всегда есть возможность выйти с 3/4, если после трех лет. Рассматривали такой вариант? Ведь всех денег не заработаешь, а опцион, даже реализованый, еще не дает гарантий, что компания будет успешной и эту инвестицию можно будет реализовать.

Я работал около трех в стартапе, контрактором. Опцион на момент моего ухода из компании стоил около $27k (поскольку стартап все время своего существования был прибыльным, нет возможности ставить цену акции в опционе нулевой). В этом случае даже опцион рассматривается как инвестиция — мне необходимо вложить $27k чтобы превратить опцион в акции, затем со временем, если компания выйдет на IPO или будет куплена (событие "exit"), я смогу продать эти акции, заплатить налоги и получить прибыль. Т.е. даже в случае рабочего, прибыльного стартапа с продающимся продуктом для опционов остается много "если", прежде чем этот вид "компенсации" превращается из ваших часов на роботе и денег в прибыль.

Для тех, кому интересна тема опционов, вот пара хороших ссылок:

• The Open Guide to Equity Compensation — открытый общий гайд на Гитхабе, часто обновляется сообществом
• An Engineer’s guide to Stock Options — классическая, на мой взгляд "статья-погружение"

IEnumerable<FileResult> ReadFiles(string[] fileNames)
{
  foreach(var name in fileNames)
  {
    yield return ReadFile(name);
  }
}

async IAsyncEnumerable<FileResult> ReadFilesAsync(string[] fileNames)
{
  foreach(var name in fileNames)
  {
    yield return await ReadFileAsync(name);
  }
}

let b = f => g => h => x => f(g(x))(h(x))

Я спустя 3-4 года возни с redux пришёл к таким выводам:

• Action types не только не нужно хранить отдельно от action creators. Их вообще не нужно делать. Для чего они могут пригодится? Для того чтобы иметь в рамках одного типа несколько фабрик action-ов. На моей практике такой случай не наступил ни разу. Могу смело сказать, что в 99% это просто бойлерплейт. Мусор. Мусору нечего делать в кодовой базе. Хотите глоссарий экшнов — автоматизируйте это. Как связывать reducer-ы с action-ами? Очень просто импортировать actionCreator-ы там где у вас reducer-ы и цепляться к ранее установленным (автоматически) actionCreator.type. Эти не сильно простые шаги уменьшат боль при написании redux приложений раза в 2.

  
  

• Держите в простых случаев reducer-ы там же где и actionCreator-ы. А сложных случаев избегайте (дробите). Может показаться странным, но это радикально уменьшает количество бойлерплейта и упрощает поддержку кода. При этом различные слои не путаются, просто лежат ближе. Недостатков пока не выявил. А вот разного рода селекторы бывает полезным вынести отдельно, т.к. их иногда может 3\4 от кода набраться и они не привязаны ни к каким экшн-тайпам.

  
  

• Используйте proxy в reducer-ах. Это невероятным образом улучшает как кодовую базу, так и экономит ваше время. Мутабельный код с преимуществами иммутабельного. Лучшее что я видел для redux. Реализация довольно простая, да и есть готовые решения. После внедрения бизнес-логика перестаёт выглядеть как тихий ужас.

  
  

• Забудте про switch-case. Ден привёл в качестве примера и понеслась. Преимуществ у них похоже никаких, но все их пишут и пишут. Куда удобнее держать привязку action-type -> handler(state, action, rootState)

  
  

• 1 action = 1 handler. Не прогонять каждый action через все reducer-ы. Принудительно привязывать обработку задачи к одному handler-у. Делает код куда более предсказуемым. Это одна из важнейших вещей в redux-е. Как это обеспечить? Ну например держать путь к reducer-у в action.type. Хотя тут много вариаций.

  
  

• Поменяйте сигнатуру каждого редьюсера с (state, action) на (state, action, rootState). Это позволит избежать тех хаков, когда вам для изменения под-части стора не хватает данных из другой ветви стора, и вы жутко извращаясь пихали эту логику прямо в actionCreator или выше. Это бессмысленный бред. При этом разумеется из одной ветки стора на другую повлиять нельзя. Цепляться не обязательно к rootState, тут надо смотреть на ваш IoC

  
  

• Используйте нормализацию. Ну тут много про это писали. Это архиважно

  
  

• Используйте memo, useAutoCallback, useAutoMemo, PureComponent и прочие примитивы с shallowComparison. Это азбука производительности вашего приложения. Очень помогут weakMemoize-ы разного рода. Селекторы, линзы и прочее. Обычно в серьёзном приложении таких утилит\помощников скапливается много.