Об иерархии принципов и вопрос по идеологической археологии

В качестве предварительного замечания напомню универсальную тенденцию: Онтогенез […] повторяет филогенез.

После чего можно переходить к предмету статьи в виде проповеди во славу принципа KISS (если кто-то вдруг не в теме — смотрите комментарий) в обсуждении статьи, посвящённой особенностям реализации системы SWIFT. С бесплатным приложением атавистической (аргументацию внушаемых тезисов поищите, накрайняк придумайте сами) критики распространённых стандартов (например XML, что самое пикантное, без разворачивания до первоисточника в виде срача дискуссии о WYSIWYG).

Но самое интересное в набрасывании постулировании догмата об эгрессивности принципа KISS. С демонстративным игнорированием других принципов. Например монизма бытия.

Первым делом тут необходимо напомнить о Сокровенном и ныне практически забытом Знании того факта, что основные деньги зарыты в эксплуатационных расходах в течение всего срока службы Изделия (и тем паче — Системы). Правда, в крайне неудобной для монетизации форме экономии издержек.

В качестве примера приведу задачу конфигурирования баз данных.

С точки зрения KISS стандартные текстовые (человекочитаемые!) конфигурационные файлы отдельно, базы отдельно.

Но принцип монизма бытия… решительно возражает против такого зоопарка (в рамках которого *разработчику* приходится реализовывать минимум два механизма чтения данных, плюс дополнительный механизм проверки, с бесплатно прилагающимися плюшками в виде издержек тестирования и сопровождения). И… побеждает. НЯП ещё в 90-х. Правда не везде в полной мере. Например в случае СУРБД PostgreSQL досейчас (2023 год) сохраняются элементы дуализима (некоторые параметры управляются посредством конфигурационных *файлов*).

До LDAP'ы (читая реализацию OpenLDAP) тенденция устранения дуализма (отказа от использования конфигурационных *файлов*) дошла позже (активное продвижение началось в конце нулевых). Зато реализована *полностью* (то есть в отличие от упоминавшегося PostgreSQL конфигурационные файлы отсутствуют) и с сохранением необходимых плюшек (достаточной человекочитаемости).

Правда данный подход к настройке (OLC) для перелётных профессионалов ТП (по косвенным признакам — категория к которой относится требователь, чьи сказки рассматриваются) оно досейчас (спустя две с лишком пятилетки после объявления сценария умолчательным, с закономерными следствиями для качества поддержки legacy) остаётся *слишком* сложным. Признаваться в чём стрёмно и опасно. И потому на свет извлекается исследуемый принцип (KISS).

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

Следующий и куда более значимый пример: повсеместно распространённый именно в силу простоты точки входа в единичную реализацию парольный механизм аутентификации.

Для которого из вполне очевидных соображений *изначально* рекомендовалось использовать *разные* (!) пароли для *разных* (!!!) сервисов. Да ещё с регулярной сменой оных (паролей). Что при числе сервисов уже лишь в жалкие десятки вырождается… сами понимаете во что.

В качестве частичного решения проблемы разработали систему централизованной аутентификации (с одной из наиболее распространённых частных реализаций «домен», он же AD, в основе которого лежат… да-да, те самые, парольчики). Правда о рисках, следующих из данной схемы (формирование у пользователя условного рефлекса ввода *единого* (!) пароля везде, где его спрашивают) поминать вслух… не принято.

Ещё интереснее становится на следующем этапе, когда на построенную систему пытаются натянуть соответствие хоть каким-то вменяемым требованиям информационной безопасности. Что выливается… пра-а-авильно, в делегирование ответственности функции в нафиг, системам, разрабатывавшимся для других целей и с совершенно иными требованиями. Причём спустя считанные годы пошли уже даже статьи-алиби, решающие задачу прикрытия пятой точки авторов.

О соответствии принципу KISS новомодно-прогрессивной технологии SASL (с документированием, более-менее проработанным до воспроизведения на новом базисе всё того же, такого простого и понятно-привычного парольного механизма, но не далее) ещё раз… выразительно промолчим.

Ну а теперь самый интересный вопрос: согласно некоторым высказывавшимся в пылу дискуссии утверждениям, архитекторы Изначальной модели были в курсе особенностей (и недостатков) схемы. Кто-нибудь в курсе: было ли это Сокровенное Знание сколько-нибудь внятно документировано? И где с ним можно ознакомиться?

Мой опыт (основанный на аналогии с памфлетом господина Смолина) оснований для оптимизма не даёт ☹

ЗЫ: Особенно… ИВНР несмешно наблюдать колебания между «нельзя» (из соображений информационной безопасности) и «очень хоцца» (из соображений удобства эксплуатации). ☹