Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Lines Club

Ищем достойных соперников.

Библиотека сайта rus-linux.net

Blockcode: Инструментальное средство визуального программирования (окончание)

Оригинал: Blockcode: A visual programming toolkit
Автор: Dethe Elza
Дата публикации: 17 December 2015
Перевод: Н.Ромоданов
Дата перевода: 2016 г.

Начало статьи смотрите здесь

Усвоенные уроки

Почему не используется MVC?

Паттерн Model-View-Controller (MVC) был хорошим примером дизайна для программ Smalltalk в 80-е годы, и его тможно использовать с некоторыми вариациями или прочим в веб приложениях, но он не подходит для любой задачи. Все состояние ("модель" в MVC) определяется в любом случае элементами блоков блочного языка, поэтому его репликация в язык Javascript принесет мало пользы в случае, если нет какой-либо другой необходимости использовать модель ( например, если мы совместно выполняем редактирование или развертывание кода).

Ранняя версия Waterbear была больше по размеру из-за использования модели в JavaScript, синхронизированной с DOM, причем до тех пор, пока я не заметил, что более половины кода и 90% ошибок были обусловлены необходимостью синхронизации модели с DOM. Устранение дублирования позволило сделать код проще и надежнее; все состояния хранились в элементах DOM и большое количество ошибок стало возможным обнаружить просто посмотрев DOM в инструментарии разработчика. Так что в данном случае мало пользы от применения MVC, чем то, что у нас уже есть в HTML / CSS / JavaScript.

Игрушечные изменения могут привести к реальным изменениям

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

Некоторые проделанные эксперименты

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

  • использование механизма перетаскивания drag-and-drop, имеющегося в HTML5;
  • запуск блоков непосредственно через итерацию с DOM с помощью вызова функций,
  • отделение кода, работа которого понятна, от DOM языка HTML,
  • более простое тестирование механизма перетаскивания,
  • создание наших собственных крошечных библиотек для работы с векторами и спрайтами (для игрушечных блоков), и
  • "живое кодирование", когда результаты видны сразу при изменения блочного скрипта.

Что касается экспериментов, которые оказались неудачными. Мы склонны замалчивать о неудачах и тупиках в нашей работе (неудач стесняются вместо того, чтобы рассматривать их как важные этапы обучения), но неудачи важны, если вы собираетесь двигаться вперед. Хотя я действительно заставил работать свойство drag-and-drop языка HTML5, тот факт, что оно не поддерживается в любом мобильном браузере, означает, что оно не подходит для Waterbear. Отделение исполняемого кода и выполнение кода при помощи итерации по блокам работало настолько хорошо, что я уже начал переносить эти идеи в Waterbear с отличными результатами в тестировании и отладке. Упрощенное тестирование с некоторыми изменениями также вернулось в Waterbear точно также, как и крошечные библиотеки для работы с векторами и спрайтами. Живая кодирование еще не перенесено в Waterbear, но после того, как нынешний раунд изменений будет застабилизирован, я могу также его ввести.

Что мы в действительности пытаемся построить?

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

Программа – это процесс, а не предмет

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

Дополнение

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


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

Комментарии отсутствуют