Как можно улучшить программное обеспечение
Пути повышения эффективности программных продуктов
Качество программного продукта характеризуется набором свойств, определяющих, насколько продукт «хорош» с точки зрения заинтересова. нных сторон, таких как заказчик продукта, спонсор, конечный пользователь и разработчики продукта, инженеры поддержки, сотрудники отделов маркетинга, обучения и продаж. Каждый из участников может иметь различное представление о продукте и о том, насколько он хорош или плох, то есть о том, насколько высоко качество продукта. Таким образом, постановка задачи обеспечения качества продукта выливается в задачу определения заинтересованных лиц, их критериев качества и затем нахождения оптимального решения, удовлетворяющего этим критериям.
ISO 9126 это международный стандарт, определяющий оценочные характеристики качества программного обеспечения. Российский аналог стандарта ГОСТ 28195. Стандарт разделяется на 4 части, описывающие следующие вопросы: модель качества; внешние метрики качества; внутренние метрики качества; метрики качества в использовании.
Модель качества, установленная в первой части стандарта ISO 9126-1, классифицирует качество ПО в 6-ти структурных наборах характеристик:
1) функциональность — набор атрибутов характеризующий, соответствие функциональных возможностей ПО набору требуемой пользователем функциональности.
2) надёжность — набор атрибутов, относящихся к способности ПО сохранять свой уровень качества функционирования в установленных условиях за определенный период времени.
3) практичность (применимость) — набор атрибутов, относящихся к объему работ, требуемых для исполнения и индивидуальной оценки такого исполнения определенным или предполагаемым кругом пользователей.
4) эффективность — набор атрибутов, относящихся к соотношению между уровнем качества функционирования ПО и объемом используемых ресурсов при установленных условиях.
5) сопровождаемость — набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций).
6) мобильность — набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое.
Вторая и третья части стандарта ISO 9126-2,3 посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств (ПС). В ней изложены содержание и общие рекомендации по использованию соответствующих метрик и взаимосвязей между типами метрик.
Четвертая часть стандарта ISO 9126-4 предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества ПС. В ней повторена концепция трех типов метрик, а также аннотированы рекомендуемые виды измерений характеристик ПС.
Лучшим и самым оптимальным способом (если не брать во внимание научно-технический прогресс и постоянное развитие IT-технологий, которые способствуют повышению качества характеристик программ) повышения надёжности программного обеспечения является строжайший контроль продукции на выходе с предприятия.
В последние годы сформировалась комплексная система управления качеством продукции TQM (Totaly Quality Management), которая концептуально близка к предшествующей более общей системе на основе стандартов ИСО серии 9000. Система ориентирована на удовлетворение требований потребителя, на постоянное улучшение процессов производства или проектирования, на управление процессами со стороны руководства предприятия на основе фактического состояния проекта. Основные достижения TQM состоят в углублении и дифференциации требований потребителей по реализации процессов, их взаимодействию и обеспечению качества продукции. Системный подход поддержан рядом специализированных инструментальных средств, ориентированных на управление производством продукции. Поэтому эта система пока не находит применения в области обеспечения качества жизненного цикла программных средств.
Применение этого комплекса может служить основой для систем обеспечения качества программных средств, однако требуется корректировка, адаптация или исключение некоторых положений стандартов применительно к принципиальным особенностям технологий и характеристик этого вида продукции. Кроме того, при реализации систем качества необходимо привлечение ряда стандартов, формально не относящихся к этой серии и регламентирующих показатели качества, жизненный цикл, верификацию и тестирование, испытания, документирование и другие особенности комплексов программ.
Активные методы повышения надежности ПС совершенствуются за счет развития средств автоматизации тестирования программ. Сложность ПС и высокие требования по их надежности требуют выработки принципов структурного построения сложных программных средств, обеспечивающих гибкость модификации ПС и эффективность их отладки. К таким принципам в работе относят:
— модульность и строгую иерархию в структурном построении программ;
— унификацию правил проектирования, структурного построения и взаимодействия компонент ПС;
— унификацию правил организации межмодульного интерфейса;
— поэтапный контроль полноты и качества решения функциональных задач.
Дата добавления: 2016-03-20 ; просмотров: 2865 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ
«Старческие болезни» программного обеспечения и пути модернизации
В ГОСТ ИСО/МЭК 9126-93 утверждается, что такого понятия, как износ программного обеспечения, нет. Ограничения надежности возможны из-за ошибок в требованиях, проекте и его реализации. Отчасти это так и есть: в ПО действительно нет физических причин для износа, как в механических устройствах. Но все же программное обеспечение устаревает. Далее мы разберемся, почему происходит старение и как с ним бороться.
Программы не люди, но они тоже стареют
Почему происходит устаревание ПО?
Программное обеспечение создается для решения конкретных бизнес-задач по существующим требованиям на базе выбранных технологий. Исходя из этого, можно сделать вывод, что устаревание происходит:
Разберем каждый пункт подробно.
Устаревание программного обеспечения по причине изменения требований
Чаще всего модернизация ПО связана с появлением в законодательстве новых требований к бизнесу
Изменение требований – это основная причина «старческих болезней» ПО. Когда требования меняются, программы перестают корректно справляться с поставленными задачами. О каких конкретно требованиях идет речь?
Если требования не меняются годами, программный продукт может корректно работать очень долгое время.
Новые задачи на старые рельсы
Чаще всего этот пункт вытекает из предыдущего. Если программный продукт разрабатывался давно, но появились новые требования извне (законодательство) или изнутри (увеличение числа пользователей, принципов хранения данных), доработать ПО под них бывает довольно сложно.
В данном случае устаревание ПО проявляется в том, что оно ни в плане архитектуры, ни технологически не отвечает новым, изменившимся задачам. Нередко программу проще полностью переписать, чем пытаться поддерживать устаревший вариант.
Почему такое происходит? Ведь клиент вложил деньги в разработку и надеялся на длительное использование продукта. Причин может быть две:
Иногда бывает сложно объяснить заказчику, что программу грамотнее, проще и дешевле переписать, чем разбираться в логике и дорабатывать ПО, которое, по сути, приказало долго жить.
Использовать устаревшее ПО с каждым днем становится дороже для бизнеса
Обслуживание устаревшей системы дорожает в геометрической прогрессии, и глобальная модернизация программного обеспечения – не столько вопрос желания, сколько насущной и экономически обоснованной необходимости.
Отсутствие поддержки ПО
Есть еще один случай устаревания ПО: когда используется программный модуль, который уже не поддерживается разработчиком и из-за обновления ОС он перестает работать. Это редкий случай, но все же такое случается. И если модуль действительно актуален и необходим, его стоит модернизировать для совместимости с новой версией ПО.
К чему приводит устаревание ПО?
Одна из главных задач бизнеса – снижать издержки. Когда речь идет о программном обеспечении, выделяют:
В случае устаревания программного обеспечения, то есть когда появляются новые задачи, начинает серьезно дорожать стоимость владения. Соответственно, если требования не меняются, то этого не происходит.
Но есть еще одна существенная проблема – устаревание документации. Нередко случается, что при изменении требований и доработке ПО никто не вносит изменений в документацию по программе. В итоге она не соответствует действительности, и это тоже повод заняться модернизацией.
Частое появление ошибок – первый признак необходимости модернизации ПО
Итак, подготовить ТЗ на модернизацию программного обеспечения необходимо, если:
Варианты решения проблемы устаревания программных продуктов
Есть несколько путей решения проблемы устаревшего программного обеспечения. В зависимости от текущей потребности бизнеса можно сделать следующее:
Рассмотрим преимущества и недостатки таких решений.
Преимущества и недостатки коробочного ПО
Коробочное ПО – это быстрый старт, но бывает сложно настраивать его под себя
Когда приобретается коробочное решение, его модификация под потребности бизнеса и поддержка перекладывается на плечи компании-вендора.
Преимущества:
Недостатки:
Преимущества и недостатки самостоятельной модернизации ПО
Самостоятельная модернизация ПО: не всегда эффективно и всегда дорого
Если в ПО есть ноу-хау, на рынке нет подходящих предложений или же коробочное решение стоит очень дорого, лучше модернизировать собственное программное обеспечение.
Когда в штате компании есть собственный ИТ-отдел – директор, архитектор и разработчики, эту задачу можно поручить им.
Преимущества
Преимущества модернизации ПО своими силами кажутся неоспоримыми: безопасность, дешевизна, качество и контроль за процессом. Так ли это?
Преимущества и недостатки обращения к аутсорсеру
Аутсорсинг – это возможность переложить хлопоты по модернизации ПО на плечи ответственных и компетентных специалистов
Недостатки
Модернизация программного обеспечения: услуги HHI
Чаще всего нам приходится иметь дело со «спасением» проекта, когда отсутствует актуальная документация на ПО, имеются проблемы с его отказоустойчивостью и нагрузкой, нет возможности связаться с разработчиком.
Наша компания оказывает полный комплекс услуг по повышению эффективности устаревшего ПО. В зависимости от поставленных задач мы готовы:
Во всем мире передача модернизации ПО на аутсорсинг становится обычной практикой – это выгодно, удобно, эффективно
Если появились новые бизнес-требования или вы столкнулись с ситуацией, когда ПО работает некорректно, бизнес может пострадать. Нет возможности и опыта для самостоятельной модернизации? Обращайтесь к нам.
Команда специалистов HHI проведет тщательное предпроектное обследование, сгенерирует грамотное ТЗ, разработает архитектуру, осуществит все необходимые доработки и произведет миграцию данных в обновленную систему.
Модернизация ПО необходима для выживания в современных условиях бизнеса. Быстрая и безошибочная работа – главное конкурентное преимущество, позволяющее удерживать клиентов и партнеров.
Сотрудничество с HHI – это гарантия быстрого старта, качественной работы и удобного взаимодействия.
Модернизация программного обеспечения — зачем нужна и как заказать
Любой программный продукт, предназначенный для работы под той или иной платформой, имеет свой срок службы, зависящий от стремления и возможностей компании-разработчика по поддержке своего решения в процессе его эксплуатации заказчиками. Как только разработчик отказывается поддерживать выпущенный продукт, у использующих его компаний или потребителей возникает потребность модернизации программного обеспечения, чтобы оно соответствовало возросшим запросам или изменившейся конъюнктуре применения. О том, зачем это нужно и каким образом можно заказать модификацию программы или мобильного приложения, постараемся рассказать в рамках текущего материала.
Причины
Первое, с чего стоит начать, это причины возникновения потребности в модернизации программного обеспечения, а говоря простым языком — его модификации под нужды пользователя. Возникнуть они могут, исходя из многих факторов, основные из которых перечислим ниже:
Процесс устаревания ПО провоцирует существенное снижение эффективности программного обеспечения, модернизацию которого обычно выполняет разработавшая продукт компания. Но зачастую последним приходится отказываться от поддержки устаревшего продукта в пользу разработки более совершенного ПО. Стоимость более современной программы может оказаться существенно выше уже выплаченной покупателем в момент приобретения эксплуатируемого ПО суммы, что зачастую становится крайне невыгодным мероприятием.
Однако чаще всего потребность модернизировать программу или целый комплекс возникает по причине расширения спектра задач, которые должно охватывать ПО. В том числе за счет увеличения количества сотрудников, с ним взаимодействующих, либо банальной необходимости улучшить и расширить пользовательский интерфейс.
Задачи модернизации ПО
Процедура модернизации программного обеспечения преследует сразу несколько целей, полностью перекрывающих потребности организаций, заинтересованных в заказе такого рода услуг. Перечислим их:
Компания, выполняющая работы по модификации программного обеспечения, получает от заказчика полный список задач, которые требуется выполнить в рамках предстоящей модернизации. Только Гграмотно составленное техническое задание на проведение предстоящих работ обеспечит полное соответствие модернизированного ПО требованиям клиента, о чем задумавшимся об улучшении используемых на предприятии программ руководителям стоит побеспокоиться заранее. Также необходимо заключить с разработчиком, готовым произвести модернизацию ПО, специальный договор, описывающий условия и сроки дальнейшей технической поддержки улучшившего функционал решения.
Где заказать?
Выбор разработчика, осуществляющего модификацию “чужих” программ или мобильных приложений, основывается на специфике применения нуждающегося в изменении ПО. Самым оптимальным будет разослать запросы компаниям-разработчикам с подробным перечнем требований к обновленному функционалу эксплуатируемого продукта, чтобы те смогли оценить свои возможности и подготовить для заказчика свой список уточняющих вопросов либо направить встречное предложение о проведении работ по модификации ПО. Вопрос стоимости модернизации программного обеспечения напрямую зависит от сроков реализации задуманного, а также квалификации команды разработчиков, которой предстоит выполнять работы. Все пункты предстоящего взаимодействия сторонам соглашения стоит обсудить заранее, включая этапы и форму проведения тестирования промежуточных версий модифицированной под нужды заказчика программы. Это застрахует обе стороны от возникновения спорных вопросов, особенно в части финансового обеспечения работ.
Что делает программное обеспечение качественным?
КДПВ
Кто-то создает программное обеспечение с открытым исходным кодом, а я провожу много времени размышляя над тем, как сделать программное обеспечение лучше. Бесконечный поток просьб о помощи на форумах Stack Overflow, GitHub, Slack, в электронных письмах и личных сообщениях неизбежен. К счастью, в итоге вы знаете многих людей, которые добились определенного успеха и сделали фантастические вещи, и знание о том, что вы приняли в этом участие благодаря вам и вашей помощи, является хорошей мотивацией для новых достижений.
У вас возникает вопрос: какие качества программного обеспечения приводят разработчика к успеху или к неудаче? Как я могу улучшить свой софт и помочь бо́льшему количеству людей стать успешным? Я могу ясно сформулировать некоторые основные принципы или полагаюсь на интуицию в зависимости от конкретного случая? (Рождение и воплощение одной мысли это два совершенно разных действия).
Возможно это что-то вроде принципов Дитера Рамса, способствующих качественному дизайну программного обеспечения?
И даже если у Вас сложилось правильное «общее представление» о том, что вы делаете, нет никакой гарантии того, что Ваш проект будет успешен. Методы претворения идеи в жизнь имеют такое же важное значение, как и сама идея. Дьявол кроется в деталях.
Я не могу дать эффективный универсальный совет, но, возможно, существует менее другой путь. Вдохновили меня Томас Грин и Мэриан Петре, чьи “когнитивные размерности” определяют набор “дискуссивных инструментов”, для “повышения уровня дискурса” о пригодности таких «информационных артефактов», как код.
Я не буду определять «общие рамки». Но у меня действительно есть некоторые наблюдения, которыми я хотел бы поделиться, и это столь же подходящее время, как и любое другое, для выполнения апостериорной рационализации прошлого года: примерно столько я потратил на D3 4.0.
Я не возвращаюсь к “крупномасштабному” проекту D3. Я вполне доволен такими понятиями, как соединение данных, масштабы и разметки, отдельные от визуального представления. Здесь также есть интересное исследование и это не последний мой фокус. Я разбиваю D3 на модули чтобы сделать его пригодным для использования в большем количестве приложений, чтобы его было проще расширить для остальных приложений, и проще разрабатывать — но, в процессе работы с ним. я также выявляю и фиксирую большое количество дефектов и недостатков API. Эти вещи легко можно упустить из виду, но в то же время, они во многом ограничивают действия людей.
Иногда я переживаю о том, что данные изменения тривиальны, особенно если рассматривать их индивидуально. Я надеюсь, что смогу убедить Вас в обратном. Я волнуюсь, потому что я думаю, что мы (т.е. люди, которые пишут программное обеспечение) склонны недооценивать юзабилити интерфейсов программирования, вместо этого рассматривая более объективные качества, которые проще измерить: функциональность, производительность, правильность.
Такие качества имеют значение, но плохое юзабилити имеет свою, реальную стоимость. Просто спросите любого, кто изо всех сил пытался разобраться в запутанном блоке кода или рвал на себе волосы в ходе борьбы с отладчиком. Нам, скорее, следует лучше оценивать юзабилити и создавать качественное программное обеспечение, которое используется нами в первую очередь.
Вы не можете просто взять кусок кода и почувствовать его вес или текстуру в руках. Код — это “информационный объект”, но никак не физический или графический. Вы взаимодействуете с API посредством манипулирования текстом в редакторе или в командной строке.
И всё же это — взаимодействие по заданному стандарту с наличием человеческого фактора. Таким образом, мы можем оценить код, как и любой инструмент, просто по критерию выполнимости своей намеченной задачи, но неужели это так просто, стать опытным программистом и эффективно его использовать? Мы должны рассмотреть возможности и эстетику кода. Действительно ли всё довольно понятно? Или, наоборот, печально? Или, может быть, красиво?
Интерфейсы программирования — это и есть пользовательские интерфейсы. Или, выражаясь иначе: Программисты тоже люди. На предмет недооценивания человеческого аспекта в разаработке дизайна мы снова услышим Рамса:
«Безразличие по отношению к людям и реальности, в которой они живут на самом деле является одним и единственным смертным грехом в дизайне».
Из этого следует, например, что хорошая документация не оправдывает плохой дизайн. Вы можете советовать людям «идти курить маны», но глупо предполагать, что они прочитали все и запомнили каждую деталь. Ясность примеров, возможность расшифровки и правки программного обеспечения в реальном мире, вероятно, гораздо важнее. Форма должна передавать функцию.
Вот некоторые изменения, которые я на глаз вношу в D3 для удобства использования. Но сначала интенсивный курс по обработке данных в D3.
Случай 1. Удаление волшебства enter.append.
“D3” обозначает дата-управляемые документы. Данные относятся к тем вещам, которые вы хотите визуализировать, и документ относится к его визуальному представлению. Это называется «документ», потому что D3 базируется на стандартной модели для веб-страниц: в объектной модели документов.
Простая страница может выглядеть следующим образом:
Соответствующий образец набора данных может выглядеть следующим образом:
Этот набор данных представляет собой массив строк. (Строка представляет собой последовательность символов, через строки находятся отдельные буквы.) Но данные могут иметь любую структуру, которую вы захотите, если вы можете представить их в JavaScript.
Для каждой записи (каждой строки) в массиве данных, нам нужен соответствующий элемент в документе. Это цель присоединения данных(data-join): быстрый метод преобразования документа — добавление, удаление или изменение элементов так, чтобы это соответствовало данным.
Data-join в качестве исходных берет массив данных и массив элементов документа, и возвращает три варианта на выбор.
Выбор входа представляет собой «недостающие» элементы (входящие данные), которые могут понадобиться для создания и добавления к документу.
Выбор обновления представляет существующие элементы (хранение данных), которые могут потребоваться для модификации (например, репозиционирование). Выбор типа вывода представляет «оставшиеся» элементы (исходящие данные), которые, возможно, нужно будет удалить из документа.
Объединение данных не изменяет сам документ. Оно вычисляет, вводит, обновляет и выводит результат, а затем Вы производите все необходимые операции. Это обеспечивает наглядность: например, для анимации ввода и вывода элементов.
Как Вы предполагаете, объединение данных — это то что Вы часто используете как при первой визуализации, так и при каждом изменении. Юзабилити данного функционала чрезвычайно важно для общей «полезности» D3. Это выглядит следующим образом:
Я не упомянул некоторые детали (например, ключевую функцию, которая присваивает данные элементам), но надеюсь, что суть темы раскрыта. После объединения с данными приведенный выше код удаляет существующие элементы, переставляет обновляющие добавляет входящие элементы.
Обычно данные операции применяют как для ввода, так и для обновления элементов. Если элемент обновляется (то есть, вы не создаете его с нуля), возможно вам будет понадобится изменить его. Такие модификации часто применяются для ввода элементов, так как они должны отражать новые данные.
D3 2.0 внес определенные изменения для решения проблемы дублирования: добавление к выбору ввода теперь будет копировать ввод элементов в выборку обновления. Таким образом, любые операции, применяемые к списку обновлений после добавления к выбору ввода, будут применяться как для ввода, так и для модификации элементов, таким образом дублирующий код будет устранен:
Увы, это ухудшило юзабилити.
Во-первых, нет никаких показателей того, что происходит внутри (плохая выразительность ролей, или, возможно, скрытые зависимости). Большую часть времени selection.append создает, добавляет и выбирает новые элементы; и по-умолчанию изменяет выбор обновлений. Сюрприз!
Данный метод устраняет дублирующий код, не искажая поведение общепринятой методики (selection.append) и без введения зависимости упорядочения. Кроме того, метод selection.merge является незнакомым указателем для читателей, который они могут найти в документации.
Принцип 1. Избегайте смысловой перегрузки
Какой вывод мы можем сделать из данной неудачи? D3 3.x нарушил принцип Рамса: хороший дизайн делает продукт понятным. В отношении размерности он был не согласован, потому что selection.append вел себя по-другому на выборке ввода. У данного метода была плохая выразительность ролей, потому что его поведение в прошлом не являлось очевидным. Также существует скрытая зависимость: операции по выбору текста должны быть запущены после добавления ввода, хотя ничто в коде не делает это требование очевидным.
Случай 2. Устранение магии transition.each
Переход подобен выбору интерфейса для анимации изменений в документе. Вместо того, чтобы изменить документ мгновенно, переходы плавно интерполируют документ от его текущего состояния до желаемого целевого состояния в течение определенного времени.
Переходы могут быть неоднородными: иногда Вам необходимо синхронизировать переход через множественные выборы. Например, для перехода по оси Вы должны отметить галочкой местоположение строк и меток одновременно:
Или как один из вариантов:
(Здесь х является функцией, такой же, как линейный масштаб, которая служит для того, чтобы вычислить горизонтальную позицию каждой галочки от ее соответствующего значения данных).
Проблема состоит отсутствии какой-либо гарантии того, что эти два перехода синхронизируются! Второй переход создается после первого, таким образом, он начинается немного позже. Разница в одну-две миллисекунды может быть здесь незаметной в отличие от других приложений.
Этот пример, к сожалению, изобретен для педагогики. Есть другой, более ясный путь (даже в D3 3.x) для синхронизации переходов посредством выборки, используя transition.select и transition.selectAll:
При этом, переход t на корневой директории документа применяется к строке и текстовым элементам, выбрав их. Данный переход является ограниченным, решение этой проблемы: переход может применяться только к новому выбору. Повторный выбор всегда возможен, но это — лишняя работа и лишний код (особенно для временного ввода, обновления, и выборов выхода, возвращаемых объединением данных).
D3 4.0 удаляет неоднозначность логики перехода transition.each; теперь он предоставляет реализацию команды selection.each. Вместо этого команда selection.transition может быть передана по средствам преобразования, в результате чего новый переход унаследует время от указанного перехода. Теперь мы можем достигнуть желаемой синхронизации при создании новых вариантов выбора:
Новый дизайн искажает поведение selection.transition. Но новый метод подписи (метод с тем же именем, но с другими параметрами) является довольно распространенным шаблоном дизайна, разница в поведении располагается в одиночном вызове.
Принцип 2. Избегайте модели поведения.
Этот принцип является продолжением предыдущего, во избежание перегрузки значение для более вопиющего нарушения. Здесь D3 2.8 ввёл несогласованность с selection.transition, но поведенческий триггер не являлся другим классом; он просто находился внутри вызова transition.each. Замечательным следствием такой конструкции является то, что вы можете изменить поведение кода, который вы не писали, обернув его с помощью transition.each!
Если вы видите код, который установиливает глобальную переменную, чтобы вызвать глобальные изменения в поведении, скорее всего, это плохая идея.
Оглянувшись назад, я делаю вывод, что на этот раз это особенно бросается в глаза. О чем я только думал? Может я неудавшийся дизайнер? Есть некоторое утешение в понимании того, почему плохие идеи являются привлекательными: это легче распознать и избежать в будущем. Здесь я вспоминаю попытку минимизировать мнимую сложность, избегая применения новых методов. Тем не менее, это является наглядным примером того, где введение новых методов (или подписи) проще, чем перегрузка существующих.
Случай 3. Удаление магии d3.transition (выбор)
Мощной концепцией в большинстве современных языков программирования является возможность определения многократно используемых блоков кода как функции. Превращая код в функцию, вы можете вызвать его везде, где захотите, не прибегая к копированию и вставке. В то время, пока некоторые программные библиотеки определяют свои собственные абстракции для повторного использования кода (скажем, расширяя тип диаграммы), D3 является показателем того, как инкапсулировать код, я рекомендую делать это только с помощью функции.
Так как запросы выборки и переходы совместно используют множество таких методов как selection.style и transition.style для настройки свойств стиля, Вы можете написать функцию, которая будет воздействовать как на на запросы выборки, так и на переходы. Например:
Этот подход применяется со встроенными компонентами D3, такими как оси и кисти, а также с такими режимами, как изменение масштаба.
Глюк этого подхода заключается в том, что у переходов и выборов нет идентичных API, поэтому не весь код может быть агностическим. Такие операции, как подсчет объединения данных для того, чтобы обновить галочки оси, требуют запросов выборки.
D3 2.8 предоставил другую ошибочную функцию данного варианта использования: он перегрузил d3.transition, который обычно возвращает новый переход на корневую директорию документов. Если бы Вы ввели команду d3.transition, и находились бы внутри transition.each callback, то команда d3.transition возвратила бы новый переход на указанный выбор; иначе она просто вернула бы указанный выбор. (Эта функция была добавлена в тот же комит, что и выше упомянутый дефект transition.each. Беда не приходит одна!)
Путаница функции transition.each заключается в следующем: d3.transition вызывает selection.transition и находится внутри transition.each обратного вызова, поэтому новый переход наследовал синхронизацию от окружающего перехода. Проблема заключается в том, что d3.transition не выполняет того, что должен. И также путаница есть в том, что и контекст, и t являются неизвестными типами — либо выбора, либо перехода — хотя, возможно, это оправдано удобством вызова функции makeitred как для выбора, так и для перехода.
Принцип 3. Аккуратное использование
Случай 4. Повторение переходов с d3.active
D3 переходы являются конечными последовательностями. Чаще всего переход является этапом перехода от текущего состояния документа к желаемому. Тем не менее, иногда вам потребуются более продуманные последовательности, которые проходят несколько этапов:
(Будьте осмотрительны при подготовке анимации! Прочтите информацию об анимационных переходах в Statistical Data Graphics by Heer & Robertson.)
Возможно, вы захотите повторить последовательность, которая описана в данном примере:
У D3 нет специального метода для бесконечных последовательностей перехода, но Вы можете создать новый переход, когда старый уже будет закончен. Это привело к самому запутывающему примеру кода, который я когда-либо писал:
Кроме того, Вы наверное заметили, что transition.each с одним параметром делает что-то абсолютно отличающееся от transition.each с двумя параметрами?
Ух!
Теперь давайте сравним с D3 4.0:
Принцип 4. Непонятные решения не являются решениями
Это тот случай, когда существует способ решения проблемы, но он настолько сложный и шаткий, что вы вряд ли найдёте его, и вряд ли вообще запомните. Я хоть и написал библиотеку, но всё-равно постоянно обращаюсь к Google.
Кроме того, это некрасиво.
Случай 5. Зависание в фоновом режиме
Бесконечно повторяемый переход в D3 3.x демонстрирует интересное поведение, если вы оставите его открытым в фоновой вкладке в течение длительного времени. Ну, под словом «интересное» Я имею в виду. что это выглядит следующим образом:
Это происходит, потому что, когда вкладка возвращается в активный режим, она старательно пытается показать все переходы, которые Вы упустили. Если вкладка определяет переходы на сотни элементов в секунду, находясь в активном режиме, то в фоновом режиме она это делает в течение нескольких часов, которые могли бы «стать» миллионами переходов!
Конечно, нет никакого смысла в выполнении этих переходов: они были запланированы в прошлом и закончатся так же быстро, как были запущены. Но так как бесконечная цепочка переходов никогда не прерывается, они должны выполняться.
D3 4.0 устраняет эту проблему путем изменения времени выполнения. Переходы обычно не должны не синхронизируются с абсолютным временем; они в основном являются вспомогательными средствами для отслеживания объектов посредством просмотра. Поэтому D3 4.0 работает в режиме реального времени, которое идет только тогда, когда страница находится в активном режиме. Когда закладка возвращается в фоновый режим, она просто ничего не делает.
Принцип 5. Подвергните сомнению свои предположения
Иногда недостаток дизайна нельзя исправить путём добавления или изменения одного метода. Но может существовать основное предположение, которое нуждается в пересмотре, например такое как неограниченное время.
Случай 6. Отмена переходов с selection.interrupt
Переходы часто инициированы событиями, такими как поступление новых данных по проводному или пользовательскому взаимодействию. Так как переходы не мгновенны — их может быть несколько и они могут конкурировать между собой за право контроля элементов. Чтобы избежать этого, переходы должны быть монопольными, что позволит новому переходу превосходить (прерывать) старый.
Тем не менее, такая исключительность не должна быть глобальной. Несколько одновременных переходов должны быть разрешены при условии, что они работают с разными элементами. Если Вы быстро переключаетесь между сгруппированными панелями ниже, Вы можете отправить волны, слегка колеблющиеся через диаграмму:
Проблема с selection.interrupt в D3 3.x заключается в том, что он не отменяет незаконченные переходы, которые запланированы для выбранных элементов. Отсутствует контроль — причина может быть в другом недостатке дизайна в таймерах D3 3.x’s, которые не могут быть остановлены внешними факторами, отмена переходов неуместна в данном случае. (Вместо этого вытесненный переход самостоятельно заканчиваются на старте).
Решением данной проблемы в D3 3.x может стать создание холостой команды, переход с нулевой задержкой после прерывания:
Поскольку первый переход пока не активен, он не прерывается. А так как второй переход запланирован после первого перехода, первый переход может запуститься до того, как впоследствии будет прерван.
В D3 4.0, selection.interrupt прерывает активный переход, если таковой имеется, и отменяет все запланированные переходы. Отмена сильнее вытеснения: запланированные переходы немедленно уничтожаются, освобождая ресурсы и гарантируя невозможность их запуска.
Принцип 6. Рассмотрим все возможные способы использования
Асинхронное программирование, как известно, является довольно сложным, потому что порядок операций является весьма непредсказуемым. Несмотря на то, что трудно реализовать надежные и детерминированные асинхронные API-интерфейсы, конечно, еще труднее использовать «кривые». Дизайнер несет ответственность за «тщательность вплоть до последней детали.»
Случай 7. Название параметров
Я закончу простыми вещами. D3 4.0 имеет несколько улучшений синтаксиса предназначенных для того, чтобы сделать код более читаемым и само-описываемым. Рассмотрим код, используя D3 3.x:
Некоторые вопросы, которые могут возникнуть:
Значение 1 и 0,3 теперь очевидны, или, по крайней мере, теперь вы можете посмотреть амплитуду и период упрощения по ссылке API, которая включает данное изображение:
Кроме того, больше нет сложно кодированного набора упрощения имен, известных как transition.ease ; упрощение всегда определяется функцией. D3 4.0 все еще обеспечивает встроенные функции упрощения и теперь Вы можете написать собственную.
Принцип 7. Дайте подсказки
Функции, которые используют множество параметров, очевидно имеют плохой дизайн. Людям не стоит пытаться запомнить такие сложные определения. (Я даже не могу сказать вам, сколько раз мне приходилось искать параметры context.arc в работе с 2D canvas.)
С момента основания, D3 одобрил названные свойства, используя метод цепочки и метод единственного параметра. Но существуют еще возможности совершенствования. Если код не может быть абсолютно очевидным, по крайней мере он может указать на правильное место в документации.
Какова цель хорошего программного обеспечения?
Речь идет не только о быстром и правильном вычислении результата. И даже не просто о краткой или изящной нотации.
У людей есть мощные, но ограниченные когнитивные способности. Многие актеры конкурируют между собой за эту способность как маленькие дети. Самое главное, что люди учатся. Я надеюсь, что мои примеры показали, как сильно влияет дизайн интерфейсов программирования на возможность людей понимать код и стать опытными программистами.
Но обучение выходит за рамки владения данным инструментом. Если вы можете применить свои знания об одном домене к другим доменам, такое знание очень ценно. Вот почему, например, D3 использует стандартную модель объекта документа, а не специфическое представление. Возможно, оно и будет более эффективным в будущем, когда инструменты изменятся, а вот время, которое вы потратили на изучение узкой области знаний может оказаться потраченным впустую!
Я не хочу, чтобы Вы изучили D3 ради D3. Я хочу, чтобы Вы изучили то, как исследовать данные и взаимодействовали эффективно.
Хорошее программное обеспечение является доступным. Это можно понять на примере простых вещей. Вам не нужно знать все, прежде чем Вы сможете понять что-либо.
Хорошее программное обеспечение совместимо. Оно позволяет делать то, что вы узнали об одной части и экстраполировать эти знания к остальным. Оно не противоречиво. Это позволяет избежать применения лишних элементов.
Хорошее программное обеспечение оправдывает себя. Оно предоставляет возможности для изучения и открытий. Оно является довольно простым и минимизирует количество непонятных вещей.
Хорошее программное обеспечение обучает. Оно не только автоматизирует существующую задачу, но и обеспечивает понимание или передает знание определенной проблемы.
Хорошее программное обеспечение создано для людей. Оно осведомляет людей о действительности, в которой они живут. Оно не предполагает, что люди должны запомнить все правила. Оно лишь подразумевает потребность в изучении и отладке.