Механизмы и интерфейсы взаимодействия с гражданами что это

Интерфейс

Об интерфейсе часто говорят, когда имеют в виду взаимодействие человека и компьютера или приложений. В статье разберем определение интерфейса, что это за взаимодействия, их виды и особенности.

Что такое интерфейс

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

ввод и отображение информации (звук, изображение);

управление отдельными приложениями;

обмен данными с другими устройствами;

взаимодействие с операционной системой.

Интерфейс подразумевает взаимодействие не только человека и техники, но и компьютер-программа, программа-программа, компьютер-устройство. Например, когда устройства подключают к системному блоку компьютера, как способ взаимодействия используют разъем.

Виды интерфейсов

Одни виды взаимодействия позволяют получить больше контроля над компьютером или смартфоном, но требуют дополнительных навыков. Другие — более комфортные, но предоставляют меньше возможностей. У каждого типа есть свои особенности.

Командная строка

Через командную строку можно выполнить максимальное количество операций — это прямой способ общения с операционной системой. Чтобы набрать команду, нужно ввести текст на языке компьютера и нажать Enter, компьютер начнет выполнять.

Минус способа в том, что он подходит только подготовленным пользователям. В командной строке нет вспомогательных графических элементов, для взаимодействия придется освоить язык, а чтобы команды работали — нельзя допускать ошибок.

Графический и текстовый

Графика упрощает взаимодействие с компьютером, с ней работать гораздо легче и комфортнее, чем с текстом. В роли графического интерфейса выступают такие элементы:

другие графические элементы.

Например, при взаимодействии с Windows используют иконки и окна, для ввода подключают мышь. На смартфоне устройством ввода служит сенсорный дисплей.

Текстовый интерфейс не использует изображения: команды отдаются с помощью текста и информация предоставляется в текстовом виде.

Жестовый, голосовой, тактильный и нейронный

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

Голосовой интерфейс — это управление голосом. Гаджет распознает и выполняет звуковые команды.

Тактильный подразумевает взаимодействие с помощью осязания: вибрация или чувствительность к силе нажатия.

Нейронный интерфейс передает команды прямо из мозга в компьютер, для этого в мозг вживляют электроды. Его применяют в медицине: так парализованный человек может общаться с окружающим миром.

Программный, аппаратный, аппаратно-программный

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

Аппаратный предназначен для организации связи между физическими устройствами через разъемы и слоты. А когда компьютер считывает информацию с жесткого диска — это совместная работа программы и физического устройства, то есть, аппаратно-программный интерфейс.

Пользовательский интерфейс

Все, с чем взаимодействует обычный пользователь, когда включает компьютер, заходит на сайт или в приложение, все, что человек видит на экране — это пользовательский интерфейс.

Веб, игровой сайт

Веб-интерфейс позволяет работать через браузер. Это взаимодействие программ в интернете. Например, можно зайти на сайт магазина и там же оплатить покупки. Браузер в этом случае будет веб-интерфейсом, благодаря которому страницы взаимодействуют.

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

Материальный

Это тактильный контакт с гаджетами. Он включает в себя прикосновения к сенсорному экрану, действия с мышкой или джойстиком.

Интерфейс в телефонах

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

Каким должен быть интерфейс

Важно, чтобы интерфейс соответствовал целям и контексту. Если это взаимодействие специалиста с компьютером, то главное — это способность обеспечивать получение информации и выполнение задач. Для обычного пользователя он имеет не только техническое, но и эстетическое значение: работа с ним должна быть удобной и понятной.

Заключение

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

Источник

Приложение вместо чиновника: как цифровизация изменит госуправление

РБК продолжает публикацию совместных материалов с проектом «Россия будущего: 2017–2035». Цель проекта, который реализуется Центром стратегических разработок совместно с Министерством экономического развития, — очертить вызовы будущего и понять, готова ли Россия на них ответить.

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

Строительство платформы

Идея государства как платформы основана на идее межмашинного взаимодействия, интерфейса программирования приложений (Application Programming Interface, API) —​ сложившейся в сфере IT практики выведения функций программных систем во внешнюю для организации среду. Это способ обеспечить автоматизированное взаимодействие новых сторонних продуктов и приложений с функционалом организации. Например, вместо того чтобы при установке приложения из AppStore или Google Market на ваш телефон вручную каждый раз вводить данные о себе, достаточно нажать кнопку «установить», и устанавливаемое приложение с помощью API автоматически настраивается для вас, начиная от вашего имени и заканчивая географическим расположением и текущей погодой.

Использование API в области государственных услуг предполагает, что многие функции, на которые государство традиционно тратит много ресурсов, автоматизируются с помощью приложений, разрабатываемых как государством, так и коммерческими компаниями и социально ориентированными организациями. Это сокращает и затраты, и время оказания услуги.

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

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

Интеллектуальные агенты

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

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

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

Кнопка «государство»

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

Такой подход позволит показать примеры новых, современных и более качественных сервисов в максимально короткий срок. При этом обеспечивается сопровождение жизненной ситуации человека или жизненного цикла объекта под ключ с пакетным осуществлением всех государственных функций и услуг в сочетании с коммерческими услугами. В конечном счете производится отладка процессов под результат и передача его на рынок.

В итоге новое цифровое государство станет более открытым, прозрачным и подотчетным. Больше открытости обеспечит новая статистика, основанная на больших данных, собираемых и обрабатываемых под запрос​​ со значительно большими, чем у традиционной статистики, возможностями мониторинга. Это значит больше информации и здравого смысла, меньше ошибок, проверок и злоупотреблений. Больше прозрачности возникнет, поскольку платформа и всеобъемлющая цифровизация документооборота на всех государственных и муниципальном уровнях сделают невозможной бюрократизацию и заблокируют значительную часть коррупционных схем. Больше подотчетности получится за счет апгрейда способностей государства учитывать интересы разных групп граждан, в том числе «незаметных» для традиционных систем государственного мониторинга, например самозанятых.

Платформенный подход к реформе госуправления разрабатывается Центром стратегических разработок с участием Министерства экономического развития в рамках подготовки стратегии развития России на 2018–2024 годы, часть идей была предложена участниками форсайт-сессии конференции «Реформа государственного управления: региональный аспект», проведенной Минэкономразвития в Калининградской области в ф​еврале 2017 года.

Источник

Интерфейс

Интерфейс – это комплекс средств, предназначенных для взаимодействия двух систем друг с другом. В качестве таких систем может выступать что угодно, включая людей и искусственный интеллект. Слово «интерфейс» позаимствовано из английского языка: interface означает «место соприкосновения».

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

Типы интерфейса

Человеко-машинный интерфейс подразделяется на четыре разновидности.

Командная строка

Самым надежным типом пользовательского интерфейса считается командная строка. Это старейший, но трудоемкий способ взаимодействия. Команды пользователя вводятся на машинном языке. Эта разновидность применяется в операционных системах, предназначенных для профессионалов.

Графический интерфейс

Самый распространенный и популярный тип, использующийся во всех ОС и в большинстве приложений. Главные элементы такого интерфейса – пиктограммы, меню и списки. Для управления программами с графическим интерфейсом удобно использовать мышь.

Жестовый интерфейс

В последнее время этот тип человеко-машинного взаимодействия стал популярным и востребованным. К этой категории относят сенсорные экраны, джойстики и стилусы.

Голосовой интерфейс

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

Источник

Интерфейсы — важнейшая концепция в разработке ПО

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

Важнейшая концепция в разработке ПО — концепция интерфейса. Эта статья не об интерфейсах на Java, а об интерфейсах в программном дизайне. И в меньшей степени — об интерфейсах в окружающем мире. Конечно, в разработке ПО используется немало других важных концепций, но я считаю, что большинство из них так или иначе зависят от важности интерфейса.

Что такое интерфейс?

Большинству из нас знакомы две краткие формулировки:

Интерфейс — это договор между системой и внешним окружением.
Интерфейс — это сопряжение системы с внешним окружением.

Интерфейс = Система ∩ Окружение

Определение с сопряжением подходит лучше, если система — это физический объект. Оба определения очень абстрактны, поэтому давайте рассмотрим их на примере печатания на клавиатуре:

Здесь система — ноутбук, окружение — руки (а также лапы кота, забравшегося на клавиатуру). Следовательно, интерфейс должен быть любой частью взаимодействия между руками и ноутбуком, которую нельзя отнести лишь к какой-то одной из сторон, а только к обеим. Обычно мы думаем о руках и о клавиатуре обособленно, так что точные границы интерфейса в данном случае — предмет философского спора. Вам решать: будет ли это клавиатура в целом или отдельные атомы, взаимодействующие друг с другом при контакте пальцев и клавиш.

Наверное, вас удивит, как этот пример соотносится с определением интерфейса как договора. В данном случае под договором подразумевается соглашение, что мы в своё время потратили достаточно усилий, когда запоминали расположение клавиш и нарабатывали мышечную память. С договором связан ещё ряд нюансов. Например, нажатие и удерживание клавиши имеет другое значение по сравнению с простым однократным нажатием.

Всё это любопытные философские рассуждения, но как они относятся к написанию ПО? Ну, начнём с того, что интерфейсы в программировании окружают вас со всех сторон, даже если вы не обращаете на это внимания. Например, если вы программируете на Java, то явным образом именуете интерфейсы в зависимости от их назначения. И в других языках они тоже присутствуют. Давайте рассмотрим пример интерфейса функции add_numbers :

Применим ту же методику цветовой дифференциации штанов для описания окружения, системы add_numbers и интерфейса:

Как видите, здесь добавлена четвёртая концепция: «реализация». Довольно сложно дискутировать на тему интерфейсов без учёта конкретных реализаций. Давайте определим этот термин:

Реализация — это система минус интерфейс.

Implementation = System ∖ Interface
Implementation = System ∖ (System ∩ Environment)

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

Оно, в свою очередь, приводит нас к следующему логическому заключению: когда мы говорим об интерфейсах физической системы, то обычно представляем себе «реализацию» этой системы в виде единого физического объекта. Ведь было бы странно рассматривать «настоящую» реализацию без учёта кнопок, дисплеев или других компонентов. И это подталкивает нас к тому, чтобы рассматривать интерфейс больше как «соглашение», а не совокупность физических объектов. То есть в виде набора обещаний, гарантий или чего-то вроде… договора между системой и окружением.

Интерфейс как договор

Если рассматривать интерфейс функции add_numbers в виде договора, то гарантии будут такие:

unsigned int add_numbers();

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

С компьютерными программами всё то же самое. Модули и функции говорят, что им нужно и (иногда) что они дадут взамен. Нарушение этого договора приведёт к ошибке компиляции, к ошибке выполнения, к сбою приложения, системы, средств контроля качества кода и к выговору от руководства. Я бы даже сказал, что определение интерфейса как договора не метафорическое. Здесь используются те же принципы, что и в коммерческом договоре, хотя он и не столь детализирован.

Патенты, авторские права и интерфейсы

Я не буду давать вам советы в области права. Возможно, что-то из мною сказанного даже будет противоречить законам. Всё нижеследующее — лишь частное мнение автора.

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

Следует ли патентовать интерфейс? Учитывая его определение как договора между системой и окружением, я считаю, что использование патентов было бы ошибкой. И, судя по всему, существующее прецедентное право поддерживает мою позицию. Но имейте в виду, что слово «интерфейс» используется очень широко, и зачастую совсем не в том смысле, как я описал выше.

Следует ли защищать интерфейс авторскими правами? Опять же, учитывая «договорную» природу, я считаю, что объектом авторского права должен быть «исходный код» интерфейса. В то же время авторские права не должны применяться к тем аспектам интерфейсов, которые делают их такими особенными. Достаточно лишь защитить исходный код или рукописное изображение, но не гарантии или ограничения. Если гарантии или ограничения интерфейса станут неотделимы от любой из частей его кода, то эти части следует лишить права защиты.

Предлагаю простой тест, позволяющий оценить, нужно ли что-то защищать авторскими правами.

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

Считаю, что с помощью этого теста целесообразно проверять ещё и на патентоспособность. Обратите внимание: цель теста — исключительно определить нецелесообразность защиты авторскими правами или патентом. Он не поможет в решении о том, что следует подвергнуть защите. Кроме того, этот тест — лишь моё мнение, а не нормативный акт или закон.

Также хочу отметить, что любой критерий, рассматриваемый как часть интерфейса в одном языке, может не являться таковым в другом языке. К примеру, в Java порядок объявления функций не влияет на выполнение программы. И если вы случайно скажете, что порядок следования функций в файле не имеет значения, то это будет ошибкой по отношению к программе на Python:

Все эти разговоры о законах напомнили мне дело Oracle против Google. По приведённой ссылке вы можете найти интересные для разработчиков подробности, так что я буду опираться на них в своём анализе. Учитывая все аспекты, не вижу причин не соглашаться с решением дела в пользу Oracle. Не могу сказать, что безоговорочно их поддерживаю, поскольку нам доступно не так много деталей разбирательства.

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

«Окружной суд заключил, что „есть лишь один способ написания“ объявлений для взаимодействия с Java. Если это так, то использование одинаковых объявлений не подлежит защите авторским правом. В Google не оспаривают тот факт, что они могли бы написать свои собственные API для доступа к Java, за исключением трёх». И наконец, «В Google признали, что они дословно скопировали объявления».

Думаю, суд принял верное решение, заключив, что уникальные по сути свойства интерфейса не должны подвергаться защите. К тому же в Google признали «дословное» копирование. Если под этим подразумевается копипастинг, включая все пробелы и орфографические ошибки в комментариях, то я считаю это нарушением прав. Даже если нельзя защищать интерфейс, то это не должно мешать защите индивидуального творческого самовыражения.

Об этой тяжбе я знаю лишь из открытых сетевых источников, но, судя по всему, в Google полностью скопировали исходный Java-код, включая интерфейсы. Похоже, они и сами считали, что нужно лицензировать своё использование Java, поскольку это было предметом переговоров по лицензионным соглашениям с Sun ещё до 2010 года. Но эти соглашения потерпели неудачу после того, как Sun была приобретена Oracle. Тем не менее Google продолжала использовать «дословные» копии кода, что явно не пошло ей на пользу при судебном разбирательстве. Подозреваю, что их адвокаты знали о слабости своей позиции, поэтому выбрали стратегию защиты, основанную на законном требовании о нераспространении авторского права на интерфейсы. Надеялись выиграть дело за счёт представления интерфейса в виде исходного кода и его объединения с более философской концепцией.

Что такое «модуль», или «абстракция»?

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

Другой пример: строение клеточной мембраны. Различные компоненты обеспечивают прохождение через мембрану только необходимых веществ и только тогда, когда это нужно.

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

Вы можете считать отдельную функцию модулем в языке С, «модулем» — в Python, классом или пакетом — в Java. Чем угодно, лишь бы оно имело внешний интерфейс и «скрытую» реализацию. Причём «скрытость» может быть следствием правил языка или даже решения программиста.

Дырявые абстракции

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

Перебор отсортированных данных может дать совсем другой результат по сравнению с перебором случайных данных. Допустим, нужно найти минимальное значение в списке:

Ветка else if никогда не будет выполнена, если данные отсортированы по возрастанию. Даже если вы начнёте проверку со случайного места списка, программа никогда не столкнётся с этой строкой. И это огромная проблема, поскольку если вы поменяете реализацию карты и она не будет возвращать отсортированные ключи, то ваш код неожиданно станет выполняться по ветке с багом. А к тому моменту вы совершенно забудете об этом коде и скрытой внутри него бомбе.

Хочу предложить своё собственное определение утечки абстракций.

Утечкой абстракций (abstraction leak) называется ситуация, когда реализация может влиять на окружение так, как не было предусмотрено интерфейсом.

Согласно этому определению, почти каждая абстракция — дырявая. Ведь описание в интерфейсе всех видов воздействия на окружение имеет смысл лишь в наиболее строгих математических системах. А что касается физических систем, то вам может вспомниться теорема Гёделя о неполноте.

Идея дырявости большинства абстракций не является необоснованной. Это подразумевал и Джоел Сполски в своём «The Law of Leaky Abstractions»:

«Все нетривиальные абстракции являются дырявыми до определённой степени».

Раз все абстракции дырявые, то о чём говорить? Проблемы возникают только тогда, когда часть окружения начинает опираться на один из непредусмотренных способов воздействия системы на окружение. Именно о таких утечках все и говорят.

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

Каждая физическая реализация криптосистемы уязвима к атакам по сторонним каналам.

Учитывая всё сказанное выше, эту идею можно распространить не только на физические, но и на эмулированные реализации.

Оценка и сравнение интерфейсов

Как мы уже видели выше, в интерфейсах на С задаются такие вещи, как тип возвращаемого значения и количество параметров, которые могут быть переданы функции. А что насчёт Python? Я использую термин «интерфейс» в соответствии с контекстом статьи, то есть в более широком понимании по сравнению с тем, что пишут в книгах об «интерфейсах» в Python.

В этом языке нам требуется формализовать типы интерфейса функции. Это упрощает определение и вызов функции, поскольку нужно обработать меньше информации. С другой стороны — ограничений, по которым можно со временем проводить проверку для поиска ошибок, меньше.

Думаю, нужно кое-что сказать об оценке и сравнении разных характеристик интерфейса с точки зрения способов передачи информации. Оценивать можно как конкретный интерфейс, так и совокупность всех интерфейсов, которые могут быть реализованы на данном языке. Давайте вспомним наш пример с add_numbers и оценим, сколько информации мы можем передать через интерфейс и в обход него, с помощью утечек абстракции.

И есть ряд вещей, которые могут коммуницировать с add_numbers через интерфейс Python.

А теперь взгляните на количество типов интерфейсов, которые мы можем описать в Haskell:

Учитывая этот код, интерфейс add_numbers может получить следующую информацию:

Для конкретного интерфейса на выбранном вами языке можно оценить ещё и количество уникальных способов передачи информации:

А теперь рассмотрим ту же задачу смены папки с помощью командной строки и cd :

В предыдущие две таблицы я не включил такие данные, как количество шума в сигнале. Если сравнить сложность повторения одной и той же последовательности при нажатии клавиш (одна за другой) и движении мыши (пиксель за пикселем), то очевидно, что во втором случае ошибок гораздо больше. В графических интерфейсах это компенсируется благодаря принятию менее строгой семантики. Представьте, если бы на кнопках «OK» и «Cancel» доступная для кликов зона была шириной всего 1 пиксель.

Можно ещё больше усложнить анализ, если оценивать изменение доли ошибок у пользователей с физическими отклонениями.

Итак, мы рассмотрели один из возможных способов оценки и сравнения интерфейсов. На основании приведённых примеров и собственного опыта позволю себе сделать несколько экстраполяций:

Дырявые и ограниченные интерфейсы

Я опишу несколько наблюдений на основании анализа из предыдущего раздела. Но сначала приведу пару определений:

Дырявый интерфейс (leaky interface) — интерфейс, который игнорируется в ходе любых взаимодействий между системой и окружением.

Ограниченный интерфейс (specific interface) — интерфейс с относительно небольшим количеством возможных входов и выходов.

Хороший пример ограниченного интерфейса — кусочно-заданные функции, определённые только для небольшого количества входных данных.

Если вы можете обоснованно оценить «дырявость» или «ограниченность» интерфейсов, то имеет смысл очертить диапазон, на одном конце которого будут очень ограниченные и недырявые интерфейсы, а на другом — неограниченные и дырявые.

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

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

Асимптотическая сложность технического долга

Основная часть технического долга возникает в проекте либо из-за недопустимого полагания на утечки абстракций, либо из-за полагания на договоры крайне нестрогих интерфейсов, что сильно затрудняет прогнозирование последствий.

В самом начале проект содержит один-два модуля, и для проработки договора хорошего интерфейса вам понадобится выполнить объём работы О(1). Если ваш интерфейс плох, то объём технического долга тоже будет равен О(1), так что вам не придётся потратить слишком много времени на приведение в порядок договора интерфейса. Но при линейном росте количества модулей объём межмодульных связей может достигать О(N^2). Следовательно, при плохом интерфейсе, если каждый модуль взаимодействует со всеми остальными модулями, количество обращений к интерфейсу в худшем случае будет пропорционально N^2.

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

Обычно уровень межмодульного взаимодействия растёт медленнее, чем О(N^2), но определённо быстрее, чем О(N). Также есть один фактор, сдвигающий начало быстрого роста в будущее: это человеческая память. Даже когда в вашем проекте 20 модулей, вы, вероятно, ещё помните, что делает каждый из них. Так, из всех договоров вам нужны лишь туманные названия функций и эзотерические соглашения. Но как только проект становится достаточно большим, то многие детали забываются, или когда в проект приходят новые люди — и начинается степенной рост трудовых затрат.

Почему всё ещё пользуются командной строкой?

На этот вопрос вы получите от людей разные ответы, ни один из которых мне не кажется самым важным:

Хотя мы и могли бы внедрять автоматизацию через кликанье и экранные грабберы, нельзя забывать о том, что такой тип взаимодействия с машиной придуман для людей. Он подразумевает использование нестрогого интерфейса, не требующего высокой точности. Поэтому ваш автоматизированный кликер наверняка будет сбоить, если окно вдруг сдвинется со своей позиции или поменяется системный шрифт. С GUI связано слишком много переменных. А командная строка позволяет действовать гораздо точнее, вы взаимодействуете через очень строгий интерфейс. Поэтому многие люди его не любят, в отличие от компьютерных программ.

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

Выбор правильного языка

После раздела про асимптотическую сложность технического долга вы могли подумать, что любой проект нужно писать на языке с очень строгими условиями договоров интерфейса, вроде Haskell или Java. Но это не совсем то, что я хотел донести. Ответ на следующий вопрос может помочь вам сделать правильный выбор.

Насколько вероятно изменение требований к вашему проекту?

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

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

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

Когда-то было сломано немало копий относительно того, что Twitter начали создавать на Ruby on Rails, а потом это стало причиной затруднений при масштабировании проекта. Позднее Twitter был переведён на Scala. Кто-то может считать, что разработчики совершили ошибку и им следовало сразу выбрать Scala. Я так не думаю. В основе Twitter’а лежит очень простая идея, и в условиях большого количества конкурентов им нужно было завоевать доминирующую позицию на рынке. Им требовалось расти как можно быстрее, невзирая на расходы. Циклы разработки новых возможностей должны были проходить максимально быстро, поскольку это позволяет в кратчайшие сроки понять, что именно нужно пользователям, какой продукт они хотят в результате получить. Трудности масштабирования – это признак не неудачи, а успеха. Было сформулировано видение Twitter’а как готового продукта, и оставалось только реализовать его. С точки зрения разработчиков, это просто нирвана, все о таком мечтают, но мало кому удаётся поработать в таких условиях: «Перепиши это дерьмо с нуля на своём любимом языке, как тебе удобно, лишь бы в будущем с ним было легче работать». Гораздо проще переписывать что-то с нуля, имея перед глазами более слабую реализацию, чем пытаться нащупать облик продукта, который позволит компании взлететь. К сожалению, большинство участников рынка идут только путем избегания «ненужных» расходов на создание с нуля и тратят массу сил и времени на масштабирование того, что изначально не предполагало масштабирования.

Почему так популярен Python?

В разделе про дырявые и строгие интерфейсы я говорил о способе классифицирования интерфейсов в зависимости от их склонности к утечкам абстракций, а также о том, как строги могут быть определения интерфейса. И я указал на тот факт, что более «дружелюбные» и «продуктивные» интерфейсы куда более склонны к утечкам, чем другая часть спектра интерфейсов.

Я считаю, что популярность Python проистекает из того, что это прекрасный вводный язык, предоставляющий крайне простые договоры интерфейса. По той же причине с увеличением проекта на Python поддерживать его становится всё труднее.

Python очень популярен в научном сообществе и среди любителей экспериментировать с численным анализом. Сама суть эксперимента требует постоянного улучшения создаваемого продукта, а строгие интерфейсы это замедляют.

Почему корпоративное ПО обычно пишут на Java/C++?

В разделе про дырявые и строгие интерфейсы я говорил о компромиссах, связанных с разными типами интерфейсов. Java и С++ относятся больше к строгой части спектра, в отличие от Python или Ruby. Да, в них могут возникать утечки, и есть более строгие языки (тот же Haskell), но зато Java и С++ более сбалансированы с точки зрения масштабируемости, дружелюбности и продолжительности итерирования. Кроме того, эти два языка позволяют гибче управлять дырявостью интерфейсов в зависимости от проектных соглашений. Например, делая переменные или функции частными, публичными или защищёнными.

Как эффективнее срезать углы

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

Источник