Post #331

Сегодня международный день числа Пи! Отмечается вот прямо сейчас — 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-теорему бывает и на собеседованиях спрашивают!)