Всем привет! Меня зовут Анна Мозер, я работаю тимлидом системных аналитиков в X5 Tech. Мне удалось поработать и в корпорации, и в стартапе, и в качестве фриланс Delivery Manager на этапе запуска стартап команды. 

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

Периодически мои друзья, знакомые, коллеги в кулуарах делятся тем, что процессы в их командах напоминают хаос. Они говорят: "Мы только и занимаемся тем, что тушим пожары" или "Я не знаю, чем буду заниматься на следующей неделе". И моё самое любимое: "Мы начали делать задачу, а на полпути потребности поменялись, и теперь нужно совсем другое. Но это же Agile…".

Хотя многие менеджеры объясняют это стремлением к гибкости и следованием Agile-философии, чаще всего такие признаки указывают на неправильное понимание и применение гибких методологий. Цель моей статьи – подсветить типичные ошибки менеджмента команды и рассказать об индикаторах того самого "недопонятого" Agile (я насчитала таких 10 штук). 

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

Память, медленная-медленная память

В начале 1980-х время, необходимое для получения данных из ОЗУ и время, необходимое для произведения вычислений с этими данными, были примерно одинаковым. Можно было использовать алгоритм, который случайно двигался по динамической памяти, собирая и обрабатывая данные. С тех пор процессоры стали производить вычисления в разы быстрее, от 100 до 1000 раз, чем получать данные из ОЗУ. Это значит, что пока процессор ждет данных из памяти, он простаивает сотни циклов, ничего не делая. Конечно, это было бы совсем глупо, поэтому современные процессоры содержат несколько уровней встроенного кэша. Каждый раз когда вы запрашиваете один фрагмент данных из памяти, дополнительные прилегающие фрагменты памяти будут записаны в кэш процессора. В итоге, при последовательном проходе по памяти можно получать к ней доступ почти настолько же быстро, насколько процессор может обрабатывать информацию, потому что куски памяти будут постоянно записываться в кэш L1. Если же двигаться по случайным адресам памяти, то зачастую кэш использовать не получится, и производительность может сильно пострадать. Если хотите узнать больше, то доклад Майка Актона на CppCon — это отличная отправная точка (и отлично проведенное время).