О стандартах мыслей свежих несколько

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


    Нижний уровень — стандартом зафиксируешь если, на верхнем уровне — разнообразия жди


    Пояснения: в ИТ мы имеем дело с многоуровневыми системами, и зафиксировав правилами один уровень (уменьшив степень свободы на этом уровне), мы сразу увеличиваем разнообразие и получаем дополнительную свободу на том уровне, который непосредственно опирается на зафиксированный. Например, появление массы разнообразных и взаимозаменяемых периферийных устройств, было обусловлено введением таких стандартов, как RS-232, ISA, PCI, RJ45, SCSI, USB и т.д.
    Полезные выводы:
    • Чем большее разнообразие имеем на одном слое, тем меньшее разнообразие на нем можно построить сверху. Под разнообразием тут нужно понимать — энтропию и отсутствие унификации.
    • На стандарте можно нарастить стандарт, но его устойчивость будет уже меньше или такой же, как и базовый стандарт.
    • Если хотите создать разнообразие — отступите один уровень вниз и укрепляйте стандарты в этом уровне. Например, хотите сложные формы — займитесь библиотекой компонентов, а не клепанием форм из чего-попало. Хотите десятки тысяч форм — еще больше зафиксируйте свободу их составных частей — сделайте генератор форм. А если хотите поднять энтузиазм и самовыражение программистов в команде — закрепите четкие конвенции написания кода и архитектурные принципы.


    С разнообразным совладать сможет простое только


    Пояснения: Можно создать стабильный слой на нестабильной (неупорядоченной) основе, но его сутью должна стать грубая обработка и упрощение. Это аналогично тому, что в городе, где твердое покрытие дороги, есть разнообразие обуви, а по бездорожью и грязюке — только самое простое и грубое, только сапоги подходят. Пример из ИТ: на базе веб стандартов образовалось разнообразие сайтов самого разного оформления, структуры, функционала и навигации. И объединить их смогли только поисковые системы, которые грубо анализируют все как текст, отбрасывая разнообразие в функциях и дизайне. Большие потоки неструктурированных данных могут быть переварены только бессхемными, документно-ориентированными СУБД и файловыми хранилищами, которые обрабатывают все грубо, крупными кусками, не вдаваясь в подробности.

    Разменяться хочешь если — спецификацию измысли


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


    Стандарт — произвол полнейший это, знания не обоснованные


    Пояснения: существует распространенное заблуждение, что нормы, стандарты и законы основаны на научном методе и обоснованы. Хоть на самом деле, любые нормы есть результатом чьего-то произвола, очень часто основанном на корысти определенных заинтересованных сторон. Чтобы понять, что это произвол, всегда можно задать к норме такие вопросы:
    • Возможно ли иначе?
    • Везде ли так, или где-то иначе?
    • Почему именно так, а не иначе?

    Например, почему где-то принят порядок битов (или байтов) от старшего к младшему или от младшего к старшему? Эта задача — чистейший спор «тупоконечников» (big-endian) и «остроконечников» (little-endian), на английском порядок битов и байтов так же и называется. Почему взята скобка квадратная, а не круглая, угловая или фигурная? Конечно, можно сказать, что это исторически сложилось, но изначально же был произвол. Можно сказать, что для принятия именно такого решения были взяты «вот эти вот» параметры и критерии и на основе их анализа мы пришли к оптимальному решению. Но, почему именно эти параметры и критерии рассматривались, а не какие-то другие, ни кто не ответит, потому, что инженерная мысль есть рационализация интуитивных прозрений, а обосновать можно все.

    Стандарты контролирует кто, так ведь безудержен он в гордыне своей


    Пояснения: из исторических аналогий мы знаем, что каждый правитель древности знал, что эффективнее вводить законы, чем воевать. Наполеон боролся с Британией введением глобальной системы мер и весов и укрепил свою страну продуманной системой законодательства. Чингисхан наладил стандарты скоростного курьерского сообщения между отдаленными частями империи, Великобритания смогли создать почтовую службу с подобной скоростью и надежностью доставки только в XIX веке. ИТ-шных примеров войны стандартов я даже не буду приводить. Стандарт — самое эффективное средство борьбы с конкуренцией в ИТ.
    Полезные выводы: очевидны.

    Стандарт — не думать каждый раз позволяет он


    Пояснения: кроме положительных аспектов стандартизации, не стоит забывать и об отрицательных. Введение любых канонических правил всегда приводит к тому, что коллектив, или вся отрасль, уже не ставит вопросов «почему?», «как?», «можно ли иначе?». Это позволяет сосредоточиться на решении других задач, для чего, собственно, и необходимо введение норм. Но это же приводит и к шаблонности мышления, инерционности и неповоротливости систем. Избавиться от старой и хорошей спецификации, всегда тяжело, даже если она уже давно неактуальна.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 4

      +4
      Просто оставлю это здесь: Магистр Йода (оригами)
        0
        Очень сложно для восприятия. Конкретные примеры были бы очень кстати.
          0
          Сложности, думаю, с первыми двумя пунктами? Возможно, у меня не хватило слов, выразить это по-человечески, но там все просто. Давайте сначала на бытовых аналогиях, а потом на примерах из ИТ. Возьмем полку, которая крепится к стене. Полка — позволяет организовать различные предметы и как только она появляется, то на ней сразу растет разнообразие. Пусть там лежат хоть мелкие предметы, хоть посуда или книги, что угодно. Но вот сверху, на это разнообразие уже не положишь второй слой предметов, тогда все превратится в срач и пользоваться этим будет уже сложно. Но если взять коробки определенного размера и разложить предметы по ним, то их можно будет класть на полку уже в 2-3 уровня. Это будет конечно менее удобно, чем без коробок, но лучше, чем срач. Тут полка — это стандарт первого уровня, он дает базу для коробок — они формируют стандарт второго уровня, а предметы — это появившееся разнообразие. Стандарт первого уровня более жесткий, чем стандарт второго уровня, ибо мы не можем положить шкаф на полку, но вот полку на шкаф положить можем, т.к. шкаф — стандарт более устойчивый. Так же и с программными системами. Вот есть у нас сервер приложений, который по HTTPS с определенных URL запросов отдает нужные ответы в формате JSON. Мы уже ввели конвенции, закрепили протокол, формат представления данных, клиент-серверный принцип обработки (запрос-ответ). Можно множество обработчиков, объединенных конвенциями в сетевое API. А без стандартов, если бы каждый обработчик представлял данные в разном формате и передавал по разному протоколу, это было бы не API, а полный хаос, т.е. обработчики бы было писать значительно сложнее, а пользоваться этим вообще невозможно. Теперь, хотим создать не просто разнообразие API, а разнообразие пользовательских приложений, которые подключаются к этому API. Тогда нам нужно ввести конвенции на уровне запросов и ответов от приложений к серверу. Например, говорим, что ответ всегда будет JSON хешем {}, а не массивом [] и не одинарным значением. Введем правило, чтобы в ответе были всегда поля ErrorCode, Message и Result, например, вот так {«ErrorCode»:null, «Message»:«Work done», «Result»: {...}}. Закрепим, что каждый вызов должен происходить через POST запрос и клиент присылает серверу в POST-e тоже JSON c полем SessionId. И этот SessionId будет даваться в процессе аутентификации. Для демонстрации нам хватит конвенций. Теперь мы можем написать клиентскую библиотеку, которая будет реализовывать данную конвенцию на 5-и языках программирования и на базе этой библиотеки может появиться разнообразие приложений.
          0
          О приключениях думают они, о написании стандартов, да! Только мудрый джедай стандарт хороший составить может. Мудрый джедай, опытный джедай. Магистром ИТ сначала стать он должен. Сложна и заковыриста работа эта. Камней подводных много. Тройному совету джедаев под силу это только.

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

          Самое читаемое