Лучший процесс программирования для создания графически сложного Java Swing Application?

Question

Я запускаю довольно сложное приложение Swing, которое в значительной степени ориентировано на графику и содержит около 1000 отдельных jpeg-файлов, более 30 различных форм и таймеры, отслеживающие скорость взаимодействия с пользователем на всем протяжении.

Мой вопрос с практической точки зрения программирования, после того, как я уже написал раскадровку для всего проекта и получил ее одобрение от клиента, где лучшее место (с точки зрения кода), чтобы начать программирование этого масштабного проекта и в каком порядок я должен программировать элементы?

(Пример ответа: сначала начните кодировать операторы объявления и инициализации всех необходимых частей, затем напишите скелетные версии всех методов, затем разберитесь с менеджером дизайна и компоновки свинга (gridbag), а затем разберитесь с событиями и слушателями)

Спасибо за советы всем, ох и кстати, я действительно люблю StackOverflow!

Answer 1

Вы описываете подход к разработке «водопадом» - сначала пройти какой-то уровень программы, затем пройти следующий уровень и т. Д. Это действительно один из возможных подходов, но многие люди находят его так называемым tracer bullet подходить лучше; сначала сделайте что-нибудь функциональным , затем учитесь на нем, настраивайте то, что нужно, и продолжайте. Это особенно полезно, если вы работаете с клиентом, потому что, демонстрируя прототипы, вы можете получить обратную связь и избежать недоразумений.

Answer 2

Я бы взял книгу по TDD, и даже если вы не собираетесь писать автоматизированные тесты, она будет полна полезных советов о том, как подходить к вашему проекту.

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

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

- EDIT

Кроме того, я бы посмотрел на использование графического дизайнера для ваших экранов вместо использования GridBagLayout. Это просто потратит время и может быстро стать кошмаром обслуживания при смене экранов. Я лично предпочитаю те, которые работают по типу файла ресурсов, когда экран по сути «скомпилирован», и вы просто загружаете его в свой код

Answer 3

Я думаю, Mad-J имеет слова мудрости.

Не концентрируйтесь на «всем» ... идентифицируйте разделы / компоненты / модули и поставьте их. Затем переходите к следующему и следующему. Это называется Итеративное и поэтапное развитие (ответ на слабые стороны модели водопада)!

Это также позволит вам создавать инструменты и интегрированные среды, которые должны упростить и ускорить разработку по мере продвижения вперед.

Это позволит вам заранее показать функциональные детали ваших клиентов. Но слово совета! Ваш клиент, скорее всего, будет постоянно менять свои требования, менять графический интерфейс, менять свое мнение и т. Д. Я видел, как целые проекты проваливались из-за этих постоянных изменений. Из этого вопроса выходит за рамки упоминания об этом, но, пожалуйста, имейте в виду, что это скорее всего произойдет, и будьте готовы с этим справиться!

Если у вас и у клиента есть функциональные части, их можно протестировать немедленно, а не тестировать одну огромную систему.

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

Первые 90% кода составляют первые 90% времени разработки. Оставшиеся 10% кодовых аккаунтов для остальных 90% развития время. - Том Каргил

Определение, признание и понимание этих сложных областей позволит вам управлять своими рисками и более эффективно изменять свои усилия и ресурсы.

Удачи,

Jeach!

Answer 4

Я предпочитаю писать UI так, чтобы сначала я писал (используя TDD) бэкэнд-классы, которые реализуют поведение UI, без каких-либо зависимостей от представления UI (то есть без Swing или любой другой библиотеки UI). После этого я пишу тонкий слой представления с библиотекой пользовательского интерфейса, где все обработчики событий и т. Д. Делегируются бэкэнду пользовательского интерфейса (они должны быть просто однострочными без какой-либо логики). Преимущество этого состоит в том, что вы можете легко писать тесты для пользовательского интерфейса, что, в свою очередь, облегчает изменение и поддержку пользовательского интерфейса. Для получения более подробной информации см. Ссылки на http://martinfowler.com/eaaDev/ModelViewPresenter.html.

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

Answer 5

Как уже упоминал MrWiggles, вы можете захотеть использовать построитель пользовательского интерфейса.

Если вы смотрите на написание множества форм, и похоже, что данные формы могут хорошо соответствовать некоторым javabeans, вы можете сначала подумать о создании панелей фреймворка.

Если вы сможете создать несколько простых базовых классов, которые позаботятся о разводке (синхронизация полей с bean-компонентами и наоборот), это сэкономит вам много работы.

Возможно, вы даже захотите настроить некоторые панели, которые будут «автоматически создавать» поля на основе bean-компонентов. Просто пройдите боб и панель создаст себя. Здесь есть хитрость: задание макета для полей и работа с полями, которые имеют фиксированные значения, проверку и т. Д. (С фиксированными значениями можно справиться с помощью редакторов свойств javabean - см. http://javadude.com/articles/propedit/index.html.

Если вы используете Swing (eclipse RCP - это хорошо, кстати), вы можете обратиться к Swing Application Framework (https://appframework.dev.java.net/).. Если он не используется напрямую, он может дать вам некоторые идеи по как настроить привязки.

Надеюсь, это немного поможет

Answer 6

Вы действительно уверены в Swing? Eclipse RCP намного лучше и гибче, начиная с EMF и продолжая

В любом случае, с Swing, сначала я подготовлю шаблон XSLT из всех: стандартная подпрограмма и другие общие части, чтобы затем привести их в абстрактные и интерфейсные классы, используемые вами шаблоны ORM.

Тогда я разработаю общую схему пользовательского интерфейса, этот "xslize" тоже.

В конце концов, с процессором ANT XSLT я подготовлю полную процедуру сборки на основе ваших спецификаций.

P.S. Я делал подобные проекты для простых веб-приложений и Swing Cruds незадолго до 2001 года, и если вы используете какой-то особенный конструктор пользовательского интерфейса, вы также можете вкладывать или писать в xslt все спецификации, не добавляя грязный код в ваши необработанные концепции пользовательского интерфейса, поэтому, когда я делаю / добавляю функции удаления для всего или отдельного фрагмента кода, максимум 30 секунд для полной перестройки ALL, конечно, вы должны "XSLIZE" все использовать также много переопределения / импорта xslt.