[Moscow.pm] гребаные тестовые задания

[Ivan Petrov]

>>> В этом сообществе, может, и не нужно.
>>> Но тогда у меня для его участников есть печальная новость.

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

> Обе вещи важны, должен быть баланс.

при наличии второй, первая ВСЕГДА достижима.

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

>> таких примеров масса.
>> вот взять скажем ICQ. Могли в ICQ добавить аудио/видео разговоры,
>> вменяемые никнеймы итп? могли. Что бы произошло в этом случае? ICQ бы
>> выжил. однако он сдох[нет].

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

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


>> профайлинг показывает узкие места.
>> как правило решение лежит не в области переписывания узких мест, а в
>> области смены чего-то в архитектуре

> Никогда не лежит в архитектуре.
> Архитектура всегда очень проста.
> Ну - есть сервер очередей, консьюмеры, есть сервер приложений, который динамику
> рисует.
> Что тут можно изменить?

архитектуру.
вот возьмем сервер очередей. ОЧЕНЬ ЧАСТО я вижу что интерфейс
консьюмера и сервера очередей делают так: консьюмер опрашивает с
некоторым периодом: "есть ли для меня задачи?"
например по такому принципу реализован pgq и многие другие очереди.

Очевидно, что данный путь реализации консюмера наиболее прост, ложится
в ИМЕЮЩИЕСЯ алгоритмы работы, но при этом имеет АРХИТЕКТУРНО
заложенные геморрои как:

 - низкая масштабируемость консьюмеров
 - заранее заданное время лага на исполнение таска

причем если не меняем архитектуру, но боремся например с лагом -
налетаем на проблему масштабируемости. боремся за масштабируемость -
приходится мириться с лагами.

решить эту проблему можно только архитектурным изменением.