Как я могу удостовериться, что все разработчики в команде создают универсальный пользовательский опыт? [закрытый]
Это немного зависит от специфики вашего дела. Во многих случаях этапы на самом деле не жестко запрограммированы, как в enum, а настраиваются для различных систем. Кроме того, чем больше потенциальных этапов у вас есть, тем больше стоит иметь более подробные настройки, но избегать повторения.
В общем, я бы порекомендовал паттерн решателя Spring здесь. Код выглядит примерно так, где KeyType обычно является перечислением или строкой. Общая идея заключается в том, что каждая реализация сообщает вам, с какими вещами (этапами, типами, параметрами и т. Д.) Она может справиться, и затем вы ищите соответствие. (Вариант, в котором нет прямого поиска по отображению, - это иметь boolean canHandle(something) и повторяться до тех пор, пока вы его не найдете.)
interface StageProcessor {
OutputType process(Stage stage);
KeyType stageKey();
}
@Service
class StageProcessors {
Map stageProcessors;
StageProcessors(Collection processors) {
stageProcessors = processors.stream().collect(groupingBy(StageProcessor::stageKey));
assert stageProcessors.size() == expectedNumberOfProcessors;
}
StageProcessor getProcessor(KeyType stage) {
// although usually your service would take care of dispatching directly
return stageProcessors.get(stage);
}
}
(И в качестве примечания: Избегать внедрения поля. )
10 ответов
У меня было несколько должностей, где я полностью владел GUI. Это вовлекало меня в создание всех проектов / макетов, а также контролировало написание сценария использования, чтобы убедиться, что все было согласованно. Это, безусловно, лучший подход для обеспечения согласованности, но он не всегда может быть наиболее практичным.
В качестве альтернативы можно было бы написать руководство, но это не совсем то же самое, что обладать хорошими знаниями в области дизайна GUI / навыками HCI. , По крайней мере, он может научить разработчиков использовать пользовательские библиотеки / компоненты, которые могут быть в вашей компании.
Обязательным условием является словарь, содержащий язык домена, который вы используете, и то, как его следует использовать в графическом интерфейсе. Это одна из самых важных вещей, которую должен сделать ведущий разработчик графического интерфейса.
По крайней мере, вы должны убедиться, что вы просматриваете все, что сделано другими разработчиками, если только вы не знаете и не доверяете им, чтобы они поступали правильно. Проектирование графического интерфейса пользователя часто недооценивается, и важно помнить, что не каждый может сделать это без надлежащей подготовки.
Возможно, вы захотите создать стандартный набор шаблонов. Например, если вы создадите шаблон веб-сайта с заранее определенными правилами css, макетами html и т.д., то вы облегчите разработчикам работу по созданию единообразного результата в том, что касается внешнего вида и функциональности.
Я считаю, что самая большая проблема часто заключается в том, что разработчики не знают, что существует руководство для конкретного рассмотрения проекта, а не нежелание осуществлять эти руководящие принципы. Задача руководства состоит в том, чтобы убедиться, что они обладают этими знаниями.
Вам всегда потребуются подробные письменные руководящие указания, если вы хотите стандартизировать какие-либо командные усилия и отсеять «индивидуальность», которая присуща проектированию системы.
Тем не менее, вы должны иметь в виду, что независимо от того, насколько подробны ваши документы, вероятно, будет какое-то непредвиденное условие, которое будет отсутствовать. Чтобы противостоять этой вероятности, у вас должна быть политика открытых дверей, согласно которой члены команды всегда могут прийти к руководителю группы и обсудить такие сценарии. Эти новые элементы должны быть затем обновлены в хранилище руководств.
Ваши руководящие документы должны быть легко доступны для всех заинтересованных сторон проекта. Создание ссылки на «шпаргалку» часто является хорошей идеей.
Все, что написано и разослано / отправлено по электронной почте, будет забыто. Я бы предложил создать внутреннюю вики, на которой размещены стандарты, ссылки на значки, шаги по созданию / сохранению работы, соглашения об именах, примеры работы и т. Д. Что-то, что каждый может получить доступ и обновить
Один из подходов, который у меня работал раньше, - это иметь общую библиотеку для базовых классов, которая применяет или применяет темы и макет.
Мы были командой из 7 разработчиков, и почти мы работаем на десктопах. приложения, поэтому мы создали базовые классы для форм и в основном использовали общие элементы управления и поместили все значки и изображения в репозиторий исходного кода, а в ходе тестирования мы убедились, что все значки и язык пользовательского интерфейса (метки, сообщения и подсказки) согласованы.
Фред Брукс много говорит об этом в месяц мифического человека, который я настоятельно рекомендую прочитать.
Карл
]создать документ который описывает все общие свойства макета.
этот документ должен включать:
цвет фона цвет текста цвет активного текста цвет неактивного текста цвет текста комментария тип шрифта размер шрифта и т. д.
убедитесь (проверяя), что разработчики следуют рекомендациям.
Вы можете применить наказание (увольнение, меньше продаж, отсутствие продвижения), если разработчик этого не делает.
Вы должны использовать некоторые своего рода внедрение зависимости с файлами XML, очень похожее на то, что может предоставить Spring .
Не все разработчики должны интегрировать свой выбор частей GUI, жестко запрограммированных в программу, а скорее оставьте этот выбор в файле XML.
Тогда одному специалисту по обеспечению качества придется проверять приложения, и, если он не будет стандартизирован, изменить только файл XML, а не перекомпилировать и т. д. '... Это будет намного быстрее и проще, так как не нужно смотреть на код приложения.
Если Spring не работает с вашей средой, я уверен, что другой Framework будет, или, в худшем случае, вы можете создать маленький самостоятельно, но это займет гораздо больше времени.
Обширные рекомендации и обзоры а "технический руководитель "," проектный руководитель "и / или QA.
Сделайте руководящие принципы" динамическими "и сохраняйте их точными и актуальными, в нашей компании мы используем Wiki для таких задач совместной работы.
У меня была должность, где я был дизайнером пользовательского интерфейса, и это сработало. Я отвечал за создание мокапов и перенос их в визуальную студию в качестве главных страниц.
Затем приходили программисты и добавляли логику.
Это отличный подход, потому что он не требует руководства по стилю или объемов документации. видя, что за это отвечает один человек.
в действительности большинство компаний не нанимают кого-то специально для роли UI (сейчас больше компаний начинают это делать, чем несколько лет назад).
будучи менеджером проекта на 5 лет в 4 разных компаниях есть другой подход.
Я не очень верю в написание руководства по пользовательскому интерфейсу и не ожидаю, что программисты будут следовать ему. Для этого есть несколько причин: 1) программисты часто плохо разбираются в дизайне пользовательского интерфейса, 2) об этом нужно помнить, 3) это контрпродуктивно.
Руководства по стилю пользовательского интерфейса замедляют программистов, потому что вы ожидаете, что они будут хороши в том, в чем они не очень хороши. они хорошо умеют кодировать - так пусть они пишут.
что вы получите? несоответствия в интерфейсе. такое случается даже тогда, когда вы предоставляете программистам макеты для работы (например, ваш макет может не содержать сообщения об ошибке, которое, возможно, придется показать программисту).
так какое же решение? легко - у вас есть один человек, который просматривает весь интерфейс на этапах и регистрирует ошибки в вашем трекере проблем. эти ошибки будут отмечены как пользовательский интерфейс или низкий уровень. если есть ошибка сценария, очевидно, гораздо важнее сначала исправить это, чем сбой пользовательского интерфейса.
следующий вопрос: кто должен проводить проверку? опять же, просто - только один человек (для последовательности), и этим человеком должен быть тот, кто наиболее талантлив в области дизайна HCI / UI.
Я хочу сказать; не заставляйте программистов пытаться быть UI-дизайнерами. когда вы регистрируете ошибку пользовательского интерфейса, она появляется в системе отслеживания проблем, программисты придут и исправят их, когда они будут готовы. и их, как правило, очень легко исправить, поэтому они могут стать хорошим перерывом для программиста, который может потратить 2-3 часа на отладку, например, серьезной проблемы с повреждением данных (да, исправление ошибки пользовательского интерфейса действительно может снять стресс!).