Data Oriented Design на практике
Что такое DOD?
Данная статья была задумана как попытка сравнить разные подходы без попытки объяснить их суть. На Хабре есть несколько статей по теме, например эта. Стоит также посмотреть видео с конференции CppCon. Но в двух словах, DOD — это способ оперировать данными в cache friendly манере. Звучит непонятно, пример объяснит лучше.
Второй тест выполняется быстрее на 30% (в VS2017 и gcc7.0.1). Но почему?
Как дела обстоят на практике?
Чтобы понять реальность применения подхода я решил написать более-менее комплексный код, используя обе техники и сравнить результаты. Пускай это будет 2d симуляция твердых тел — мы создадим N выпуклых многоугольников, зададим параметры — массу, скорость и т.п. и посмотрим, сколько объектов мы сможем симулировать оставаясь на отметке 30 fps.
1. Array of Structures
1.1. Первая версия программы
Исходный код для первой версии программы можно взять из этого коммита. Сейчас мы кратко пробежимся по коду.
На моем стареньком ноутбуке эта программа рассчитывает 500 фигур максимум, перед тем, как fps начинает падать ниже 30. Фуууу, всего 500. Согласен, немного, но не забывайте, что каждый кадр мы повторяем расчеты 20 раз.
Думаю, что стоит разбавить статью скриншотами, поэтому вот:
1.2. Оптимизация номер 1. Spatial Grid
Коммит второй версии программы можно посмотреть здесь. Появился новый класс Grid и немного изменился метод ShapesApp::update() — теперь он вызывает методы сетки для проверки пересечений.
Эта версия держит уже 8000 фигур при 30 fps (не забываем про 20 итераций в каждом кадре)! Пришлось уменьшить фигуры в 10 раз, чтобы они поместились в окне.
1.3. Оптимизация номер 2. Multithreading.
Разделение основных задач добавило немного головной боли. Так например, если фигура пересекает границу ячейки в сетке, то она будет находится одновременно в нескольких ячейках:
Запустив эту версию я могу наблюдать 13000 фигур при 30 fps. Для такого количества объектов пришлось увеличить окно! И снова — в каждом кадре мы повторяем симуляцию 20 раз.
2. Structure of Arrays
2.1. Первая версия программы
То, что мы писали выше я называю традиционным подходом — я пишу такой код много лет и читаю, в основном, похожий код. Но теперь мы убьем структуру Shape и посмотрим — сможет ли эта небольшая модификация повлиять на производительность. Ко всеобщей радости рефакторинг оказался не сложным, даже тривиальным. Вместо Shape мы будем использовать структуру с векторами:
И передаем мы эту структуру так:
Т.е. вместо конкретных фигур передаются их индексы и в методе из нужных векторов берутся нужные данные.
Эта версия программы выдает 500 фигур при 30 fps, т.е. не отличается от самой первой версии. Связано это с тем, что измерения проводятся на малом количестве данных и к тому же самый тяжелый метод использует почти все поля структуры.
Далее без картинок, т.к. они точно такие же, как были ранее.
2.2. Оптимизация номер 1. Spatial Grid
Все как и раньше, меняем только AoS на SoA. Код здесь. Результат лучше, чем был ранее — 9500 фигур (было 8000), т.е. разница в производительности около 15%.
2.3. Оптимизация номер 2. Multithreading
Снова берем старый код, меняем структуры и получаем 15000 фигур при 30 fps. Т.е. прирост производительности около 15%. Исходный код финальной версии лежит здесь.
3. Заключение
Изначально код писался для себя с целью проверить различные подходы, их производительность и удобство. Как показали результаты, небольшое изменение в коде может дать довольно ощутимый прирост. А может и не дать, может быть даже наоборот — производительность будет хуже. Так например, если нам нужна всего один экземпляр, то используя стандартный подход мы прочитаем его из памяти только один раз и будем иметь доступ ко всем полям. Используя же структуру векторов, мы вынуждены будем запрашивать каждое поле индивидуально, имея cache-miss при каждом запросе. Плюс ко всему немного ухудшается читабельность и усложняется код.
Поэтому однозначно ответить — стоит ли переходить на новую парадигму всем и каждому — невозможно. Когда я работал в геймдеве над игровым движком, 10% прироста производительности — внушительная цифра. Когда я писал пользовательские утилиты типа лаунчера, то применение DOD подхода вызвало бы только недоумение коллег. В общем, профилируйте, измеряйте и делайте выводы сами :).
DoD |Definition of Done| Критерии готовности
Definition Of Done (DoD) — критерии, определяющие степень готовности задачи.
Часто у членов команды нет общего понимания о том, что такое «готово». Это может приводить к постоянным конфликтам внутри команды и багам на продуктивной среде. Также довольно распространена ситуация, когда Владелец Продукта просит команду закончить работу быстрее. Например, ему нужно раньше конкурентов вывести продукт на рынок. Часто в такой ситуации урезается скоуп тестирования или функционал реализуется путем приделывания костылей. Такой подход ведет к накоплению технического долга.
DoD — это чек-лист, c помощью которого можно понять, что задача готова. Каждая команда имеет свои критерии готовности. Они определяются в зависимости от контекста и состава команды. Очень важно, чтобы каждый член команды полностью понимал и принимал каждый пункт в этом списке. Другими словами DoD это разновидность командного соглашения по конкретному вопросу.
Критерии готовности, которые выбрала команда, это открытая информация, доступная всем заинтересованным лицам. Их наличие обеспечивает прозрачность, как внутри команды, так и во вне по отношению ко всей организации. Со временем команда улучшает критерии готовности путем ретроспективных изменений. Уровень DoD является показателем зрелости команды.
DoD в LeSS
Если продукт развивают несколько команд, использующих LeSS-фреймворк, то критерии готовности должны быть общими. Другими словами, нужен единый Definition of Done.
Пример DoD Scrum команды
Пример DoD Kanban команды
Аналитика
Разработка
Тестирование
Definition of Ready
Кроме критериев готовности хорошей практикой считается использовать Definition of Ready или DoR. Это критерии, которые должен соблюсти заказчик, чтобы его задачу взяли в работу. Например, «к задаче должны быть написаны критерии приемки».
Словарик айтишника или Что? Где? Куда? Часть 2
Scrum-терминология
От англ. Definition of Done (дословно — критерии готовности) — список требований, по которым можно считать, что цель выполнена. Например, набор задач, которые должны быть завершены к определенной дате.
Майлстоун
От англ. milestone (дословно — веха) — запланированная дата окончания работ по выборочным задачам. Проставление таких «дат» позволяет не сбиваться с графика и отслеживать процесс работы и понимания выполнения целей.
Сторя
От англ. story (дословно — история) — корневая задача с описанием требований для разработки, она содержит в себе подзадачи, назначенные на разработчиков разных должностей. Это точка входа при разработке какого-либо функционала.
Фасилитатор
От англ. facilitator (дословно — координатор) — человек, берущий на себя обязанности ведущего. Он обеспечивает успешную коммуникацию внутри команды, пытается упростить общение и создает понимание между всеми участниками команды. Термин может использоваться и как существительное, и как прилагательное, и как глагол.
Разработка
Ассайнить
От англ. assign (дословно — поручать) — назначать задачу на человека в качестве исполнителя.
От англ. bug (дословно — жук) — ошибка в коде, проблема, недоработка. Слово уже давно в лексиконе разработчиков, но интересно то, как меняется форма термина. Калька «баг» превратилось в слово женского рода — «бага». В такой форме согласование в предложениях проще. А если ошибка или проблема совсем маленькая, то это багуля.
Грумить
От англ. groom (дословно — чистить) — приводить в порядок. Относится к коду, бэклогу, организации работы. В том же значении используется и русский аналог — «причесать».
Деплой
От англ. deploy (дословно — разворачивать) — процесс интеграции кода из разработческих веток в продуктовую (мастер) ветку. Термин также употребляется и как существительное, и как глагол, и как прилагательное.
Компилить
От англ. compile (дословно — составлять) — собирать написанный код воедино, конвертировать его из одного формата в другой, преобразовывать в требуемый вид для работы в браузере.
Костыль
Временная «подпорка» в коде, которая приводит к нужному результату, но само решение является идеологически неверным.
Лагать
От англ. lag (дословно — отставание) — плохая производительность, притормаживание, работа с ошибками.
Легаси
От англ. legacy (дословно — наследие) — код, написанный определенное время назад и считающийся морально устаревшим. Он всё ещё работает, но вызывает неприятие у разработчиков.
Мерджить
От англ. merge (дословно — слияние) — соединять свою часть работы с частями работы других разработчиков в рамках одной ветки. Сливать всё воедино.
Нативный
От англ. native (дословно — родной) — первоначально заложенное поведение или внешний вид элемента или кода.
Стоимость задачи
Пришедшее из скрама выражение, означающее суммарное количество затрат разработчика на задачу. Вопрос про стоимость задачи буквально означает оценку времени и усилий на неё. Соответственно дорого — долго и сложно, дешево — быстро и легко.
Фейлить
От англ. fail (дословно — неудача) — терпеть поражение, проваливать планы, заваливать что-либо. Чаще используется в разговорной, не технической речи.
От англ. fix (дословно — чинить) — решение проблемы, устранение бага. Термин употребляется и как существительное, и как глагол, и как прилагательное.
Должности
От англ. junior (дословно — новичок) — специалист любой должности, которая предусматривает градацию по уровню знаний. Джун находится на первой (нижней) ступеньке. Человек, знаний, которого хватает для выполнения рабочих обязанностей и разработки в целом, но не обладающий глубиной и широтой знаний.
От англ. lead, сокращенно от TeamLead (дословно — глава команды) — специалист высшей градации, обладающий широтой и глубиной знаний, является лидером команды. Он руководит процессами и помогает решать спорные технические вопросы.
Секопс
От англ. SecOps, сокращенно от Security Operations (дословно — интеграция безопасности) — специалист, занимающийся обеспечением безопасности при имплементации новых решений и безопасностью в целом.
Организационное
Апрув
От англ. approve (дословно — одобрять) — еще одна вариация для одобрения, утверждения или подтверждения чего-либо.
Валидный
От англ. valid (дословно — правильный) — в разговорной речи вариации слова означают согласие с оппонентом, одобрение его результата. Означает правильность решения. Часто заменяет слово «идет» в значении «подходит».
Инпут
От англ. input (дословно — вклад) — в разговорной речи используется в значении внимание, отклик.
Капиай
От англ. KPI, сокращенно от Key Performance Indicator (дословно — ключевой показатель результативности) — единица измерения, которая требуется для того, чтобы понять эффективность какой-либо деятельности.
Пинговать
От англ. ping (дословно — ударяться со стуком) — напоминать кому-либо о чем-либо, давать знать.
Эскалировать
От англ. escalate (дословно — обострять) — поднимать вопрос или проблему на обсуждение, привлекать внешние ресурсы, принимать меры.
И напоследок.
Райкер
От англ. wrike-er — человек, который работает в Wrike и является частью команды компании.
Как считаете, проще ли бы было новичкам, если при выходе на работу им давали расшифровку незнакомых терминов, которые обрушиваются уже в первый день работы? Дают ли ясность подобные расшифровки или только больше запутывают? Поделитесь своим мнением в комментариях.
Dod что это значит
Смотреть что такое «DOD» в других словарях:
DOD — DoD, DOD DOD(d[o^]d or d[=e] [=o]*d[=e] ), prop. n. [from Department of Defense.] the United States Department of Defense, the federal department responsible for safeguarding national security; created in 1947. It includes within its jurisdiction … The Collaborative International Dictionary of English
DoD — DoD, DOD DOD(d[o^]d or d[=e] [=o]*d[=e] ), prop. n. [from Department of Defense.] the United States Department of Defense, the federal department responsible for safeguarding national security; created in 1947. It includes within its jurisdiction … The Collaborative International Dictionary of English
DoD — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. <<
DOD — abbrDepartment of Defense see also the important agencies section Merriam Webster’s Dictionary of Law. Merriam Webster. 1996. DOD … Law dictionary
dod|dy — «DOD ee», noun, plural dies. 1. a cow or bull without horns. 2. Aberdeen Angus. ╂[< dialectal dod to make hornless] … Useful english dictionary
død- — ; dødgod; dødirriterende; dødkedelig; dødlækker … Dansk ordbog
Dod — Dod, Charles, geb. 1789, war lange Mitarbeiter an verschiedenen politischen Zeitschriften in London u. seit 1832 Mitredacteur an der Times u. st. 22. Febr. 1855. Er gab heraus: The parliamentary companion (bibliographische Übersicht sämmtlicher… … Pierer’s Universal-Lexikon
DOD — См. δOD. Diccionario Mosby Medicina, Enfermería y Ciencias de la Salud, Ediciones Hancourt, S.A. 1999 … Diccionario médico
DOD — the written abbreviation of the US Department of Defense … Dictionary of contemporary English
DOD — (Department of Defense) American government office that maintains military forces and ensures that the military can handle threats to national security … English contemporary dictionary
dod — eləmək: (Mingəçevir) qoçaqlıq eləmək … Azərbaycan dilinin dialektoloji lüğəti
Definition of Ready VS Definition of Done VS Acceptance Criteria
Периодически в сети натыкаюсь на холивары на тему, что же такое Definition of Done, совпадает ли Definition of Done и Acceptance Criteria и т.д. А уж если в ветке кто-то вспомнит, что еще существует Definition of Ready – все, тушите свет. В общем, я, как всегда, решила не проходить мимо и вставить свои 5 копеек.
Тем более как раз свои старые записи листала, и хорошая картинка с тренинга попалась:
В чем же нюансы и почему это вызывает столько недопонимания?
Давайте по пунктам:
В общем, как вы поняли из трех пунктов выше, основной смысл всего этого добра – чтобы вся команда понимала:
…и не тратила ценное время и энергию.
Примеры Definition of Done, Definition of Ready и Acceptance Criteria
Все примеры из англоязычных интернетов, в русском, как обычно, то ли все только об этом говорят, и никто в реальности не делает, то ли никто не хочет делиться (это скорее).
Пример Definition of Ready
Пример Definition of Done
ПримерAcceptance Criteria
Кто отвечает за Definition of Done, Definition of Ready и Acceptance Criteria
Очень хочется сказать “ну конечно, Заказчик!”, но не совсем. Заказчик отвечает только за Acceptance Criteria (за то, чтобы определить, КАК должна работать реализуемая задача). А за Definition of Done (за то, ЧТО будет сделано, чтобы она точно работала так, как и было задумано) отвечает команда. Как и за Definition of Ready, впрочем.
Ну и минутка реальной жизни напоследок
В реальности внятных применений полного комплекта из всех трех артефактов я видела очень мало. Лично у меня обычно не доходит до формализации Definition of Ready, тут я полагаюсь на свой адекват и на адекват владельца продукта, а кейсы с кривыми задачами исправляются на ручном приводе.
А вот Definition of Done я обязательно в начале проекта с командой согласую. Даже если в проекте не аджайл – это отличная перестраховка от появившихся внезапно хотелок архитектуры или информационной безопасности.
Ну и Acceptance Criteria – наше все, конечно. Опять же, для пользовательских задач – must have, а вот на технических могу и пропустить, если в команде высокий уровень взаимопонимания.
P.S. Для тех, кто знает толк – при прямо аджайле-аджайле в компании у команды могут быть (и должны быть) Definiiton of Ready и Definiiton of Done не только для задач, но и для отдельных пользовательских историй, спринтов и релизов.
Не совсем по теме поста, но очень уж хорошая картинка про Definiiton of Done при поиске примеров попалась, не могу не поделиться:
И вот еще про Definiiton of Ready:
Используете описанные артефакты у себя? Расскажите в комментариях!
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
