Рубрика «большие коллективы»

Когда продукт большой, разработчики скатываются в крайности:

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

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

Сбалансированная разработка в очень больших командах. Доклад Яндекса - 1

— Хочется поговорить про то, как жить в больших командах. Большая команда — это когда людей даже больше, чем в этом зале.Читать полностью »

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

Закон Амдала

В 1967 году Джин Амдал представил довод против параллельных вычислений. Он утверждал, что рост производительности ограничен, поскольку только часть задачи поддаётся распараллеливанию. Размер остальной «последовательной части» отличается в разных задачах, но она есть всегда. Этот довод стал известен как закон Амдала.

Если построить график «ускорения» выполнения задачи в зависимости от количества выделенных ей параллельных процессоров, вы увидите следующее:

Издержки согласования в коллективах - 1
Это асимптотический график для фрагмента, который не поддаётся распараллеливанию («последовательная часть»), поэтому существует верхний предел максимального ускорения
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js