Для того чтобы ответить, какой должна быть платформа общего пользования, например, операционная система, чтобы быть удобной для пользователя и для программиста, сначала нужно прояснить, что вероятно, этот вопрос будет трудно разделить на два независимых — про удобство для пользователей и отдельное удобство для разработчиков. Во-первых, ответы на эти вопросы испытывают тесное взаимное влияние. Во-вторых, если внимательно присмотреться, то в удобной системе сами роли разработчика и пользователя могут существенно переплетаться, и вовсе не потому, что пользователю должны будут предъявлены повышенные требования.
В доработке...
С разработчиком всё просто. Так как речь о платформе общего пользования, то и разработку для неё удобней всего вести из неё самой, поэтому чтобы быть удобной для разработчика, платформе в числе прочего нужно быть удобной для него как пользователя. И даже если разработчику нужно чтобы разработка велась из сторонних платформ, это не противоречит роли разработчика как пользователя, так как удобная платформа может позволять работать с собой поверх других систем, не требуя применения сторонних средств подобных виртуальным машинам.
С пользовательской ролью тоже несложно, если понять, что даже типичный графический интерфейс, с которым пользователь обычно взаимодействует — это всего лишь визуальный интерактивный предметно-ориентированный язык программирования, а программа, соответственно, это ничто иное, как исполнитель(интерпретатор) этого языка. Язык программы может быть алгоритмически неполным, но и это совсем не обязательно. С этой точки зрения пользователь тоже является в некотором роде разработчиком, как минимум, сиюминутно исполняемой программы. Нередко этим всё не ограничивается и специализированный язык нередко требует возможностей из обычных пакетных языков программирования сразу, как только требуется мало-мальски нетривиальное взаимодействие, например, специфичная автоматизация рутинных действий.
Взаимное же влияние проявляется в том, что если платформа помогает разработчику создавать приложения, а не заставляет вести борьбу с собой, то это повышает шансы на появление нужных пользователю функций. Но есть и некоторые противоречия. Например, разработчику на начальном этапе развития системы может быть удобно разрешённость всего, а пользователю наоборот желателен контроль за приложениями, переходящий в набор ограничений. Это не критичное противоречие, потому что в долговременных разработках программисту тоже требуется контроль над доступными возможностями, ведь неограниченный доступ ко всему провоцирует создание запутанных систем со сложноисправляемыми недостатками, в том числе и критичными ошибками. А в этом не заинтересован ни разработчик, ни пользователь.
Направленность на пользователя, а не на компьютер
В современных по положению, но морально устаревших ОС работа пользователя выстраивается в большей степени вокруг устройства, хотя сейчас конкретный компьютер — это, скорее, ячейка и вход в общее пространство вычислений, чем его центральная часть. Тем не менее, уровень связности разрозненных систем вокруг пользователя всё ещё довольно слаб, и по большей части обеспечивается нагромождением хрупких мостиков.
Пользовательское пространство должно обеспечиваться системно. Данные пользователя должны быть доступны ему на любых устройствах, ассоциированных с ним. Желательна техническая возможность опциональной привязки устройств к пользователям-владельцам. При инициализации системы на устройстве должно учитываться, что в большинстве случаев готовую информацию о пользователе она может получить из другого носителя, автоматически присоединяясь к общему информационному пространству без необходимости указания всего с начала.
Направленность на пользователя, а не на производителя
Плохим способом обеспечения связности является завязка на сервисы выпускающей компании, навязывающей пользователю её решения и обеспечивающая интересы пользователя лишь в той степени, в которой это нужно для обеспечения интересов производителя, но не более. Этот подход может лишь частично обеспечить связность и, наоборот, во многом способствует разрозненности из-за соперничества с другими компаниями.
Познаваемость и предсказуемость
Система не должна быть чем-то необъятным и непонятным, о чьих возможностях можно только догадываться, и для полной работы с чем нужно учиться много лет. Ради этого ключевого свойства можно частично пожертвовать многими другими свойствами. Система не должа выглядеть как чёрный ящик, чьи свойства исследуют извне, формируя неполное и часто кривое представление. И ясность должна быть доступна не только «избранным и посвящённым».
Контролируемость
Тот уровень представления системы, который доступен пользователю, при всех упрощениях в сравнении с полной картиной, тем не менее не должен быть бутафорией, не способной предоставить достаточные сведения для принятия обоснованных решений.
Выделение человеческого участия
Система должна отличать события, не связанные с человеческим участием, от событий, отождествляемых с пользователем через устройства ввода или опосредованно получаемые от пользователя по надёжным каналам. Пользовательским действиям следут придавать большей величины во всём — в приоритете обработки, наделении прав, в ценности, сохранности и защищённости введённого.
Устойчивость
Система не должна позволять приводить себя в нерабочее состояние для всех программно контролируемых случаев. Она должна сохранять резерв ресурсов, которые позволят ей функционировать самой и отвечать на пользовательские действия. Пусть лучше отвечает отказом на излишние требования, чем раздаёт оптимистичные обещания, которые если и возможно адекватно выполнить, то только с некоторой вероятностью.
Ошибкоустойчивость
Система должна страховать от программистских и пользовательских ошибок. Например, удаление и замещение данных на системном уровне должно быть отменяемым без необходимости применения как специальных функций удаления, так и специфичных низкоуровневых операций над файловыми системами для восстановления. Данные, удаляемые «сразу», должны иметь лишь существенно меньший период возможности восстановления, а не полностью обходиться без него.
Сохранность
Пользователь не должен организовывать резервные копии или что-то подобное. Надёжность и сохранность данных должны быть базовой частью самой платформы. Особенно это касается данных, создаваемых пользователем, и тем более тех, что не требуют больших ресурсов, например, печатные тексты.
Сохранность работоспособности самой системы в большей степени должна обеспечиваться умением восстанавливаться из конфигурации, а не полноценным резервированием с занятием места под неуникальные файлы системы.
Должна использоваться и естественная побочная резервирующая способность из-за использования одних ресурсов на разных устройствах.
Локальность
Для связывания локальных устройств и подсистем должны максимально использоваться локальные же каналы связи. Они не должны взаимодействовать через посредников, отстоящих от них информационно дальше, чем сами подсистемы. Это касается и системных функций.
Ограничиваемость
Ограничения являются крайне важной составляющей любой информационной системы, имеющей дело с алгоритмически полным кодом, так как он в общем случае может приводить к выходу системы из под контроля. Любая задача и подзадача должна иметь численные рамки того, что ей позволено в отношении ресурсов машины, исходя из адекватных ожиданий от назначения задачи.
Самообслуживаемость
Всё, что может работать без вмешательства человека, и не должно отвлекать его внимание на себя. Например, пользователя не должны заботить второстепенные данные программ, подобные кэшу. Устаревшие или избыточные промежуточные данные в случае нехватки ресурсов должны быть удалены автоматически в порядке устаревания. Не должно это заботить и программы в индивидуальном порядке, так как должно решаться системно.
Высокоуровневость
Многих свойств можно добиться только в том случае, если система будет сохранять в своём основном интерфейсе зависимость только от высокоуровневых понятий. Если же в него проникают низкоуровневые детали, например, пользователю доступна установка кода на машинном языке как базовой возможности, то система оказывается плохо защищённой от угроз и более ресурсоёмкой при желании получить хоть какую-то защиту. То, что на высоком уровне может достигаться просто удачным выбором понятийной основы, на более низком уровне, где эта основа уже недоступна, может достигаться ресурсоёмкими и запоздалыми динамическими проверками.
Пользователю тоже будет проще, если его не будет заботить, под какую из машинных архитектур ему нужно выбрать код.
Даже код на низкоуровневых языках стоит рассматривать подобно коду на высокоуровневых. Для исполнения не требуется совпадения машинных архитектур кода и компьютера-исполнителя. Совпадение можно рассматривать лишь как возможность более оптимального выполнения, если машинная архитектура позволяет использовать действительно надёжную аппаратную изоляцию.
Программируемость
Удобная система не прячет свои страшные инструменты конструирования программ от пользователя, чтобы потом криво надстраивать другие страшные и схожие же возможности для автоматизации и упрощения сложного взаимодействия. Архитектура удачной системы предоставляет последовательность изолированных слоёв взаимодействия, в которых пользовательский интерфейс является верхним его представлением. Система должна предоставлять прямой способ перехода от автоматизации к интерактивному интерфейсу и наоборот[0].
Это предъявляет определённые требования к языкам создания ПО, по крайней мере тем, что находятся ближе к пользователю. В неудачных системах во многом потому и прячут основные инструменты, что они являются слишком эзотеричискими для нормальных людей.
Интерфейс
Должен строиться в большей степени вокруг описания сути, чем концетрации на способе представления. А способ представления должен автоматически или полуавтоматически выстраиваться по модели данных, количественных показателях данных, возможностям устройств отображения, и пожеланиям пользователя. Одни и те же средства могут быть доступны и в подобии командной оболочки, и в визуальной тыкательной среде, и в других способах отображения и взаимодействия, включая автоматизированные. Специальная визуализация по особым пожеланиям должны формироваться через подсказки, дополняющих модель данных, а не замещающих её. То есть в большинстве случаев программист не создают новые представления, а получает их из самой модели с помощью построителя представлений.
Свобода
Свобода — само по себе важное для пользователя и разработчика качество. Кроме того, без свободы сложней добиться других важных качеств. Как минимум, определяющие спецификации должны быть открытыми. Хотя и для весомой части исполняемого кода это тоже желательно.
Свобода кода может накладывать несколько неожиданные ограничения даже на выбор языка кодирования. Излишне сложные и эзотерические языки кодирования не могут дать свободу, так как делают пользователей зависимыми либо от необходимости в избыточном обучении возможности адекватного взаимодействия с такими языками, либо излишне зависимыми от других людей(или систем), освоивших такие языки. Нынешние mainstream-языки, а также их перспективные заменители являются, скорее, эзотерическими.
Комментариев нет:
Отправить комментарий