Сегодня международный день числа Пи!
Отмечается вот прямо сейчас — 3/14 в 1:59:26
Нужно печь пи-роги и пить напитки, начинающиеся на "пи".
Удачно совпало с Масленицей, блины же тоже круглые!
В разработке ПО нет таких известных констант, но есть множество законов разной степени доказанности — от формальных теорем до эмпирических наблюдений. И все очень полезные! В основном они относятся к управлению, архитектуре или UX. Вот небольшой список:
Закон Брукса:
Добавление людей в запаздывающий проект вызывает ещё большее отставание.
(Это из книги "Мифический человеко-месяц", принципиальные вещи оттуда не изменились за почти 50 лет. Там много интересного, например формула, по которой "просто программа" обходится в 9 раз дешевле, чем протестированный, документированный и интегрированный программный продукт).
Закон Хофштадтера (того самого, который автор книги "Гёдель, Эшер, Бах: бесконечная гирлянда"):
Любое дело занимает больше времени, чем вы ожидали, даже если учесть Закон Хофштадтера.
Закон Конвея (это не тот Конвей, который изобрел игру "Жизнь" и сюрреальные числа. А сам закон очень важен для организации команд — отсюда растет DDD и микросервисы):
Организации, проектирующие системы, создают архитектуры, повторяющие структуру коммуникации этих организаций.
Принцип Постела (важен для интеграций):
Система должна быть консервативна в том, что она отправляет, и либеральна в том, что она принимает на вход.
Принцип Парето (применительно к ПО):
80% пользы получается от 20% функций системы.
Закон Линуса (Торвальдса, создателя Linux):
Под множеством взглядов все дефекты всплывают на поверхность.
(очень важно для нагруженных систем: мне рассказывали, что на главной странице Яндекса, к которой обращаются больше 1,5 млрд раз в день, сбои, вероятность которых 0,0000001%, происходят 10 раз в день! То есть, для нормальной работы вероятности сбоев должны быть сильно меньше.)
Закон Вирта:
ПО становится медленнее быстрее чем железо становится быстрее.
Фундаментальная теорема программной инженерии:
Любая проблема может быть решена добавлением ещё одного уровня абстракции.
Эти законы шуточные, но есть и формально доказанные теоремы. На удивление, их не очень много.
Одна из них — Теорема Кодда (создателя реляционной алгебры), которая доказывает эквивалентность операций реляционной алгебры и языка SQL. Несмотря на критику, реляционные базы до сих пор актуальны, т.к. под ними лежит формальная математическая теория со строгими доказательствами.
Другая, очень часто поминаемая в архитектуре распределенных систем: CAP-теорема (или теорема Брюера). Она утверждает, что в распределенной системе можно обеспечить не более двух свойств из триады:
🔸согласованность данных (Consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
🔹доступность (Availability) — любой запрос к распределённой системе завершается откликом, однако без гарантии, что ответы всех узлов системы совпадают;
🔻устойчивость к разделению (Partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
Сформулированная как эмпирическое утверждение, CAP-теорема была впоследствии формализована и доказана, а также показана важность синхронизации часов в распределенных системах. Почему-то редко слышу про это в разговорах о микросервисах, но служба точного времени становится критически важной для синхронизации последовательных операций, там, где это важно (и для журналирования при интеграциях).
CAP-теорему часто критикуют за то, что под согласованностью и доступностью в своем формальном виде она имеет в виду не совсем то, что обычно под этим подразумевают. Но знать её всё равно нужно, чтобы осмысленно разговаривать с архитекторами и принимать обоснованные решения.
Расширение CAP — теорема PACELC (добавляет выбор между задержками — Latency — и согласованностью, даже если система не разделена, т.к. информация по сети не передается мгновенно).
Эти законы и теоремы стоит знать и учитывать (а про CAP-теорему бывает и на собеседованиях спрашивают!)
Отмечается вот прямо сейчас — 3/14 в 1:59:26
Нужно печь пи-роги и пить напитки, начинающиеся на "пи".
Удачно совпало с Масленицей, блины же тоже круглые!
В разработке ПО нет таких известных констант, но есть множество законов разной степени доказанности — от формальных теорем до эмпирических наблюдений. И все очень полезные! В основном они относятся к управлению, архитектуре или UX. Вот небольшой список:
Закон Брукса:
Добавление людей в запаздывающий проект вызывает ещё большее отставание.
(Это из книги "Мифический человеко-месяц", принципиальные вещи оттуда не изменились за почти 50 лет. Там много интересного, например формула, по которой "просто программа" обходится в 9 раз дешевле, чем протестированный, документированный и интегрированный программный продукт).
Закон Хофштадтера (того самого, который автор книги "Гёдель, Эшер, Бах: бесконечная гирлянда"):
Любое дело занимает больше времени, чем вы ожидали, даже если учесть Закон Хофштадтера.
Закон Конвея (это не тот Конвей, который изобрел игру "Жизнь" и сюрреальные числа. А сам закон очень важен для организации команд — отсюда растет DDD и микросервисы):
Организации, проектирующие системы, создают архитектуры, повторяющие структуру коммуникации этих организаций.
Принцип Постела (важен для интеграций):
Система должна быть консервативна в том, что она отправляет, и либеральна в том, что она принимает на вход.
Принцип Парето (применительно к ПО):
80% пользы получается от 20% функций системы.
Закон Линуса (Торвальдса, создателя Linux):
Под множеством взглядов все дефекты всплывают на поверхность.
(очень важно для нагруженных систем: мне рассказывали, что на главной странице Яндекса, к которой обращаются больше 1,5 млрд раз в день, сбои, вероятность которых 0,0000001%, происходят 10 раз в день! То есть, для нормальной работы вероятности сбоев должны быть сильно меньше.)
Закон Вирта:
ПО становится медленнее быстрее чем железо становится быстрее.
Фундаментальная теорема программной инженерии:
Любая проблема может быть решена добавлением ещё одного уровня абстракции.
Эти законы шуточные, но есть и формально доказанные теоремы. На удивление, их не очень много.
Одна из них — Теорема Кодда (создателя реляционной алгебры), которая доказывает эквивалентность операций реляционной алгебры и языка SQL. Несмотря на критику, реляционные базы до сих пор актуальны, т.к. под ними лежит формальная математическая теория со строгими доказательствами.
Другая, очень часто поминаемая в архитектуре распределенных систем: CAP-теорема (или теорема Брюера). Она утверждает, что в распределенной системе можно обеспечить не более двух свойств из триады:
🔸согласованность данных (Consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
🔹доступность (Availability) — любой запрос к распределённой системе завершается откликом, однако без гарантии, что ответы всех узлов системы совпадают;
🔻устойчивость к разделению (Partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
Сформулированная как эмпирическое утверждение, CAP-теорема была впоследствии формализована и доказана, а также показана важность синхронизации часов в распределенных системах. Почему-то редко слышу про это в разговорах о микросервисах, но служба точного времени становится критически важной для синхронизации последовательных операций, там, где это важно (и для журналирования при интеграциях).
CAP-теорему часто критикуют за то, что под согласованностью и доступностью в своем формальном виде она имеет в виду не совсем то, что обычно под этим подразумевают. Но знать её всё равно нужно, чтобы осмысленно разговаривать с архитекторами и принимать обоснованные решения.
Расширение CAP — теорема PACELC (добавляет выбор между задержками — Latency — и согласованностью, даже если система не разделена, т.к. информация по сети не передается мгновенно).
Эти законы и теоремы стоит знать и учитывать (а про CAP-теорему бывает и на собеседованиях спрашивают!)