Речь пойдет, о технических стандартах, т.е. протоколах, спецификациях, паттернах, конвенциях, интерфейсах, форматах данных, нотациях и других отраслевых и особенно внутренних нормах, которые мы используем или изобретаем при разработке программных систем. Очевидных вещей я не буду повторять, каждый знает, что стандарты — это хорошо и правильно, что они способствуют унификации и, следовательно, совместимости систем и их модулей. Надеюсь, мои обобщения опыта, в форме «заметок для себя», будут полезными и нетривиальными.
Пояснения: в технике мы имеем дело с многоуровневыми системами, и зафиксировав правилами один уровень (уменьшив степень свободы или ликвидировав свободу на этом уровне), мы сразу увеличиваем разнообразие и получаем дополнительную свободу на том уровне, который непосредственно опирается на зафиксированный. Например, появление массы разнообразных и взаимозаменяемых периферийных устройств, было обусловлено введением таких стандартов, как RS-232, ISA, PCI, RJ45, SCSI, USB и т.д., а POSIX и WinAPI предопределили появление великого множества ПО.
Полезные выводы:
Пояснения: Можно создать стабильный слой на нестабильной (неупорядоченной) основе, но его сутью должна стать грубая обработка и упрощение. Это аналогично тому, что в городе, где твердое покрытие дороги, есть разнообразие обуви, а по бездорожью и грязюке — только самое простое и грубое, только сапоги подходят. Пример из ИТ: на базе веб стандартов образовалось разнообразие сайтов самого разного оформления, структуры, функционала и навигации. И объединить их смогли только поисковые системы, которые грубо анализируют все как текст, отбрасывая разнообразие в функциях и дизайне. Большие потоки неструктурированных данных могут быть переварены только бессхемными, документно-ориентированными СУБД и файловыми хранилищами, которые обрабатывают все грубо, крупными кусками, не вдаваясь в подробности.
Пояснения: невозможно придумать идеальный стандарт, но всегда хочется к этому стремиться. В результате, зафиксировав спецификацию в текущем уровне своего понимания, мы всегда боремся с мыслью, что мы что-то не учли и можно сделать лучше. Кажется, что выпустив такой стандарт мы размениваемся, так и не достигнув желаемого.
Полезные выводы:
Пояснения: существует распространенное заблуждение, что нормы, стандарты и законы основаны на научном методе и обоснованы. Хоть на самом деле, любые нормы есть результатом чьего-то произвола, очень часто основанном на корысти определенных заинтересованных сторон. Чтобы понять, что это произвол, всегда можно задать к норме такие вопросы:
Например, почему где-то принят порядок битов (или байтов) от старшего к младшему или от младшего к старшему? Эта задача — чистейший спор «тупоконечников» (big-endian) и «остроконечников» (little-endian), на английском порядок битов и байтов так же и называется. Почему взята скобка квадратная, а не круглая, угловая или фигурная? Конечно, можно сказать, что это исторически сложилось, но изначально же был произвол. Можно сказать, что для принятия именно такого решения были взяты «вот эти вот» параметры и критерии и на основе их анализа мы пришли к оптимальному решению. Но, почему именно эти параметры и критерии рассматривались, а не какие-то другие, ни кто не ответит, потому, что инженерная мысль есть рационализация интуитивных прозрений, а обосновать можно все.
Пояснения: из исторических аналогий мы знаем, что каждый правитель древности знал, что эффективнее вводить законы, чем воевать. Наполеон боролся с Британией введением глобальной системы мер и весов и укрепил свою страну продуманной системой законодательства. Чингисхан наладил стандарты скоростного курьерского сообщения между отдаленными частями империи, Великобритания смогли создать почтовую службу с подобной скоростью и надежностью доставки только в XIX веке. ИТ-шных примеров войны стандартов я даже не буду приводить. Стандарт — самое эффективное средство борьбы с конкуренцией в ИТ.
Полезные выводы: очевидны.
Пояснения: кроме положительных аспектов стандартизации, не стоит забывать и об отрицательных. Введение любых канонических правил всегда приводит к тому, что коллектив, или вся отрасль, уже не ставит вопросов «почему?», «как?», «можно ли иначе?». Это позволяет сосредоточиться на решении других задач, для чего, собственно, и необходимо введение норм. Но это же приводит и к шаблонности мышления, инерционности и неповоротливости систем. Избавиться от старой и хорошей спецификации, всегда тяжело, даже если она уже давно неактуальна.
Нижний уровень — стандартом зафиксируешь если, на верхнем уровне — разнообразия жди
Пояснения: в технике мы имеем дело с многоуровневыми системами, и зафиксировав правилами один уровень (уменьшив степень свободы или ликвидировав свободу на этом уровне), мы сразу увеличиваем разнообразие и получаем дополнительную свободу на том уровне, который непосредственно опирается на зафиксированный. Например, появление массы разнообразных и взаимозаменяемых периферийных устройств, было обусловлено введением таких стандартов, как RS-232, ISA, PCI, RJ45, SCSI, USB и т.д., а POSIX и WinAPI предопределили появление великого множества ПО.
Полезные выводы:
- Чем большее разнообразие имеем на одном слое, тем меньшее разнообразие на нем можно построить сверху. Под разнообразием тут нужно понимать — много энтропии и мало унификации.
- На стандарте можно нарастить стандарт, но его устойчивость будет уже меньше или такой же, как и базовый стандарт.
- Если хотите создать разнообразие — отступите один уровень вниз и укрепляйте стандарты в этом уровне. Например, хотите сложные формы — займитесь библиотекой компонентов, а не клепанием форм из чего-попало. Хотите десятки тысяч форм — еще больше зафиксируйте свободу их составных частей — сделайте генератор форм. А если хотите поднять энтузиазм и самовыражение программистов в команде — закрепите четкие конвенции написания кода и архитектурные принципы.
С разнообразным совладать сможет простое только
Пояснения: Можно создать стабильный слой на нестабильной (неупорядоченной) основе, но его сутью должна стать грубая обработка и упрощение. Это аналогично тому, что в городе, где твердое покрытие дороги, есть разнообразие обуви, а по бездорожью и грязюке — только самое простое и грубое, только сапоги подходят. Пример из ИТ: на базе веб стандартов образовалось разнообразие сайтов самого разного оформления, структуры, функционала и навигации. И объединить их смогли только поисковые системы, которые грубо анализируют все как текст, отбрасывая разнообразие в функциях и дизайне. Большие потоки неструктурированных данных могут быть переварены только бессхемными, документно-ориентированными СУБД и файловыми хранилищами, которые обрабатывают все грубо, крупными кусками, не вдаваясь в подробности.
Разменяться хочешь если — спецификацию измысли
Пояснения: невозможно придумать идеальный стандарт, но всегда хочется к этому стремиться. В результате, зафиксировав спецификацию в текущем уровне своего понимания, мы всегда боремся с мыслью, что мы что-то не учли и можно сделать лучше. Кажется, что выпустив такой стандарт мы размениваемся, так и не достигнув желаемого.
Полезные выводы:
- Главное понимать, что от этого чувства невозможно избавиться, и оно не должно останавливать.
- Если ты не разменялся, то и пожил зря, только мечтая об идеальном.
Стандарт — произвол полнейший это, но не знания обоснованные и выведенные
Пояснения: существует распространенное заблуждение, что нормы, стандарты и законы основаны на научном методе и обоснованы. Хоть на самом деле, любые нормы есть результатом чьего-то произвола, очень часто основанном на корысти определенных заинтересованных сторон. Чтобы понять, что это произвол, всегда можно задать к норме такие вопросы:
- Возможно ли иначе?
- Везде ли так, или где-то иначе?
- Почему именно так, а не иначе?
Например, почему где-то принят порядок битов (или байтов) от старшего к младшему или от младшего к старшему? Эта задача — чистейший спор «тупоконечников» (big-endian) и «остроконечников» (little-endian), на английском порядок битов и байтов так же и называется. Почему взята скобка квадратная, а не круглая, угловая или фигурная? Конечно, можно сказать, что это исторически сложилось, но изначально же был произвол. Можно сказать, что для принятия именно такого решения были взяты «вот эти вот» параметры и критерии и на основе их анализа мы пришли к оптимальному решению. Но, почему именно эти параметры и критерии рассматривались, а не какие-то другие, ни кто не ответит, потому, что инженерная мысль есть рационализация интуитивных прозрений, а обосновать можно все.
Стандарты контролирует кто, так ведь безудержен он в гордыне своей
Пояснения: из исторических аналогий мы знаем, что каждый правитель древности знал, что эффективнее вводить законы, чем воевать. Наполеон боролся с Британией введением глобальной системы мер и весов и укрепил свою страну продуманной системой законодательства. Чингисхан наладил стандарты скоростного курьерского сообщения между отдаленными частями империи, Великобритания смогли создать почтовую службу с подобной скоростью и надежностью доставки только в XIX веке. ИТ-шных примеров войны стандартов я даже не буду приводить. Стандарт — самое эффективное средство борьбы с конкуренцией в ИТ.
Полезные выводы: очевидны.
Стандарт — не думать каждый раз позволяет он
Пояснения: кроме положительных аспектов стандартизации, не стоит забывать и об отрицательных. Введение любых канонических правил всегда приводит к тому, что коллектив, или вся отрасль, уже не ставит вопросов «почему?», «как?», «можно ли иначе?». Это позволяет сосредоточиться на решении других задач, для чего, собственно, и необходимо введение норм. Но это же приводит и к шаблонности мышления, инерционности и неповоротливости систем. Избавиться от старой и хорошей спецификации, всегда тяжело, даже если она уже давно неактуальна.
В завершение добавлю слова Гёте, которые мне почему-то кажутся близкими к теме:
Природа с красоты своей
Покрова снять не позволяет,
И ты машинами не выудишь у ней,
Чего твой дух не угадает.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:
- Massacres That Matter - Part 1 - 'Responsibility To Protect' In Egypt, Libya And Syria
- Massacres That Matter - Part 2 - The Media Response On Egypt, Libya And Syria
- National demonstration: No attack on Syria - Saturday 31 August, 12 noon, Temple Place, London, UK
Комментариев нет:
Отправить комментарий