Решение, дилемма, риск

Авторы: Аруп Саркар, Манодж Сарва, Мрунал Лохия, Набарун Мондал, Вивек Вишванатан.

Решения и дилемма

Каждый принимает решения. Некоторые решения являются сдержанными, с низким уровнем риска, некоторые - с высоким уровнем риска. По мере увеличения риска увеличивается и вознаграждение - естественно, и возникает дилемма «идти / нет» при принятии решений.

Представьте себе мир, в котором можно заранее представить себе риск с точки зрения результата, вытекающего из принятого сейчас решения. Каждый мечтает обрести ясновидение в отношении решений и результатов!

На программное обеспечение

Софт дешевый. Фундаментальное различие между аппаратным и программным проектированием состоит в том, что изменение программного обеспечения, конечно, намного дешевле, чем изменение физического оборудования. Это означает, что лица, принимающие решения (бизнес-менеджеры, менеджеры по продуктам, разработчики) полагают, что изменение должно быть менее затратным, но это не всегда верно.

Git, коммиты, PR

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

Говоря языком Git, атомарное изменение - это фиксация, а набор изменений можно назвать «запросом на перенос».

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

Это, конечно, должно основываться на оценке рисков.

Риски и их измерения

Что такое риск? Риск - это то, о чем знают все, но очень немногие хотят думать о его формализации. Риск формально обсуждается в финансовой математике, происходящей от классического предмета теории игр. Учитывая, что фильм «Красивый ум» смотрели практически все, о «теории игр» слышали практически все.

Но математики и финансовые теоретики работали с ним долгое время. Но строгость пришла только после основополагающей работы фон Неймана и Моргенштерна по формализации полезности, которая определяет основу современной экономики и теории портфеля.

Утилита, использование и удобство использования

Какая польза от всего? Что-то? Оказывается, это аксиома. Некоторые записи на старой бумаге могут стоить миллионы долларов - например, Дневник да Винчи, такой же, как последняя модель спорткара.

В инженерии, однако, это не так уж много аксиоматики - не так уж и много вариаций полезности. Потому что инженерия в конечном итоге служит бизнесу, а бизнес-цели совпадают с техническими целями.

Каковы же тогда бизнес-цели? Речь идет о доставке заказчику:

Быстрее - чтобы получить преимущество быстрых ходов и преимущество первопроходцев
Высокое качество - чтобы клиенты оставались в бизнесе, ключевым моментом является удержание - регресс будет проблемой с точки зрения клиента, а значит, и бизнеса.

Эти двое, что неудивительно, вечно враждуют друг с другом.

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

Измерение риска

Как же тогда измерять риск? Рациональные люди воображают, что что-то должно быть пропорционально другому - на красочном языке это называется линейностью. Проблема в том, что линейной системы почти нет.

То же самое применимо к программному обеспечению и коду, потому что один компонент системы принимает входные данные от другого компонента системы.

Следовательно, один модифицированный компонент может и будет иметь каскадное воздействие на систему!

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

В этом нет ничего нового - практикующие врачи делают то же самое под видом «побочных эффектов» лечебных процедур, удивительно, что почти никто в Dispora программного обеспечения не подумал об этом и не формализовал это.

Решение

Зависимости, Графики

Данный код написан по модульному принципу - то есть они разделены на файлы, которые внутренне зависят друг от друга, по определению эти взаимосвязи создают то, что математики и компьютерные ученые называют «направленным графом».

Естественно, что в графе зависимостей можно делать что-то очень похожее.

Хотя на приведенном выше изображении показаны довольно простые зависимости, реальный мир слишком сложен. Например, это то же изображение с добавлением большего количества деталей - нечто, уже известное как «ад зависимостей».

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

Воздействие на направленный график

Файлы, на которые повлияло прямое воздействие (файлы в фиксации), являются начальной зоной воздействия. И поскольку каждый файл может влиять на другие, влияние распространяется на всю кодовую базу.

Здесь все становится немного техническим, но не намного.

Представьте себе астероид, уничтоживший большинство динозавров. Ущерб был максимальным в точке удара, а затем по мере увеличения расстояния удар замедлялся.

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

Мы можем утверждать аксиоматически, поскольку узел находится далеко от зоны воздействия, «шанс» чего-то плохого уменьшается обратно пропорционально расстоянию. Конечно, это один из способов думать об этом.

Есть другой, более научный взгляд на это. Так мы думаем о потоке воды и трубах. Если кран подключен к двум разным трубам, то выходящая вода будет суммироваться над водой, выходящей из труб.

Как оказалось, это гораздо лучшая идея.

Окончательный алгоритм

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

Первым наивным показателем воздействия изменения PR является отношение всех этих потенциально затронутых файлов к общему количеству файлов. Естественно, мы здесь не учитываем расстояние до места удара.
Более точный, более научный подход - присвоить вес каждому из файлов, на которые изначально повлияли изменения, и распределить вес и сумму в потоке на каждом узле. Если вес превышает критический порог на каком-либо узле, этот файл является потенциальным подозреваемым.
Мы можем попробовать решить эту же проблему и стохастически! Эти веса, которые мы ищем - их можно найти по истории этих файлов - какова вероятность того, что при изменении файла возникнет проблема в системе.

[3] обобщает портфельный подход к рискам на PR-коммиты.

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

Эта система присутствует в Compass, и мы называем ее RAC - Risk Assessment of Commits.

Построен всеми новыми студентами колледжей, нанятыми как IC1 - это то, что наш технический директор сказал, что это - «фундаментальная инженерия», происходящая на практике. В Приложении список всех людей, которые работали в RAC. Вот схема компонентов системы RAC:

Применение, использование, результаты

Лишь очень немногие компании-разработчики программного обеспечения пытались создать такую систему. Одним из них был Microsoft, где эта система называется CRANE и играет ключевую роль в выпуске сборок Windows. Другой, конечно же, Compass.

Здесь мы показываем интеграцию системы RAC с конвейером GitHub и CI-CD.

Он интегрирован с несколькими нашими репозиториями git и, таким образом, дает заинтересованным сторонам возможность узнать о риске изменения. Более того, направленный подход к тестированию позволяет сэкономить много времени на то, чтобы быстро определить, регрессирует система уже или нет. RAC запускается всего за 2 минуты.

В конце концов, RAC - это портал для управления рисками - наряду со снижением рисков наиболее научным способом - фундаментального принципа инженерии.

Особое упоминание

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

Оливия Йонас - старший менеджер программы - Compass | LinkedIn
Исключительно целеустремленный, уверенный и зарекомендовавший себя начинающий, обладающий более чем 10-летним опытом работы на высшем уровне… www.linkedin.com