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

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

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

Задержка разработки с полным стеком: сначала UX

Используйте AngularJS (или лучше). Ручная запись JSON-документов, которые будут обслуживаться бэкэндом для соответствующих RESTful GET, и помещать их в систему контроля версий. Также поместите в один HTML-файл, который сейчас является целым приложением. У вас будут все прямоугольники, которые могут появляться / исчезать на странице в одном и том же исходном файле, и использовать Angular, чтобы показать / скрыть их в зависимости от обстоятельств. На этом этапе вы избежите модульности.

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

То, что вы хотите, чтобы они приняли, тоже материал AngularJS. Все это добро в атрибутах, которые являются нестандартными HTML. Такие атрибуты, как ng-show, ng-hide, ng-click и усатые выражения. Было бы замечательно, если бы он существовал, но это не так: удобный набор примеров / рецептов для новичка

программисты
дизайнеры для копирования / вставки при разработке взаимодействий, поведения и эстетики AngularJS.

Конечно, ничего не происходит, так как данные являются консервированными, и каждое обновление страницы возвращает вас к началу, но дизайнер и владелец продукта должны иметь возможность продвигать приложение вперед без серверной части. По крайней мере, какое-то время. Ох, и забудьте IE6 & 7.

Вышеуказанное и отсутствие защитной сетки от тестов приведут вас к размерам истории за час или около того.

Я сказал, задержка!

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

Когда разработчики приходят массово, все меняется. Код HTML / JS будет подвергнут рефакторингу, чтобы стать более модульным. Нефункциональные результаты и приоритеты начинают влиять. Тесты начинают следить за прогрессом, если не за развитием. Конечно, дооснащение тестами далеко от идеала. Работа бизнес-аналитика начинает становиться более ориентирующим направлением, а формальное объединение работ в гибкие итерации защищает ценные приоритеты.

Ангулярное несовершенство

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

Там нет причин для этого на самом деле. Фреймворк, который перенял у Angular (ThoughtWorkers сейчас обсуждают это в частном порядке), будет иметь более высокую эквивалентность между этими двумя способами ведения дел. Взять загрузку ресурсов Angular из смежного документа JSON: https://docs.angularjs.org/api/ngResource/service/$resource —

var User = $resource('/user/:userId', {userId:'@id'});
var user = User.get({userId:123}, function() {
    user.abc = true;
    user.$save();
  });

Конечно, вы могли бы преподнести это UX людям как нечто подходящее для копирования / вставки, но было бы лучше иметь:

<div ng-resource="user, '/user/:userId', @id">
  <div>{{ user.name }}</div>
  <button ng-click="user.$delete(); window.location.href = '/'">Delete</button>	
</div>

Я допускаю, что эти два фрагмента не являются функционально идентичными. HTML-1 — это более реальный мир (удаление), а тот из Angular doco придуман (загрузка, изменение, сохранение без взаимодействия). Поверьте мне, страница ngResource в несколько раз лучше, чем раньше, когда она была сосредоточена на давно мертвом API Google-Buzz (в качестве примера).

Я также гарантирую, что нет обработки «сбой загрузки ресурса». То же самое относится и к «невозможности удаления». Однако и то, и другое не должно замедлять идеализированную функциональность под руководством UX.

Идеальная команда для начинающих

Конечно, это сработает только для того, чтобы сделать акцент на том, чтобы «сделать все как можно дешевле», а не «как можно быстрее». У идеальной команды все еще есть эксперт по JavaScript / Angular и бакалавр, чтобы помочь сконцентрироваться на полном описании необходимого поведения. Лучше всего это делать в Agile-итерациях, и, если PM вообще задействован, следует заглянуть в итерации впереди, чтобы уточнить продолжительность проекта и когда разработчики должны прибыть для получения полного стека.

Нужен еще один навык (указывает Дейв Смит): Data Modeler. Структура документов JSON, предлагающих хранение в бэкэнде NoSQL, означает, что кто-то в команде должен с самого начала распространяться вокруг навыков Data Modeler. Эти JSON-документы должны не только соответствовать простой привязке к представлению, но и иметь шанс быть сохраненным для будущего соединения с нуля.

Ловушки

Помимо упомянутых:

• Любой, кто кодирует слишком далеко вперед (функциональный или нефункциональный)
• Позолота вместо демонстрации
• Отсутствие требований
• Плохое руководство
• Интеграция с бэкэндами, которые нельзя отложить

дальнейшее чтение

Год назад я обрисовал модель, в которой сотрудники UX могут заниматься интерфейсом AngularJS: когда Agile встречается с разработкой под Angular и UX . В этой статье была представлена ​​идея UX-led (в этом контексте) и приводятся предварительные наборы, которые вы должны научиться любить. Этот принимает UX-привело к его выводу.

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

Может быть, даже UI Technology Paradigm Shift стоит прочитать.

Наконец, NoSQL для хранилища и реляционный для отчетности могут умиротворить архитекторов «будущего мышления», которые предполагают, что хранение документов не будет работать для их корпорации (когда команда приступает к созданию бэкэнда).

Последнее замечание

DDD есть и всегда будет доменным дизайном, а не разработчиком с задержкой разработки.