Лучший способ написать доказательство концепции (PoC) приложение?

в настоящее время я работаю над проектом, с которым мне нужно программу немного доказательство концепции приложения. Я писал приложения PoC раньше, но они были только очень маленькими и на самом деле не имели много слоев, где в качестве приложения, которое я пишу сейчас, есть:

  • Form layer-переговоры со слоем данных.
  • Data layer-переговоры с базой данных и уровнем взаимодействия.
  • Interop Layer-переговоры с COM-объектом.
  • COM объект

каков был бы лучший способ написать программу, чтобы показать, что я могу получить от A до B и процесс, который необходим, без необходимости тратить много времени на написание PoC.

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

может ли кто-нибудь порекомендовать какие-либо советы/рекомендации при кодировании PoCs? Или есть лучший способ объяснить, что я имею в виду, а не писать код.

7
architecture design modeling

8 ответов

Я согласен с другими ответами о получении прототипа. Один из способов убедиться, что ваш прототип остается таким,-использовать язык или цепочку инструментов, которые определенно не будут использоваться в конечном продукте, тем самым заставляя его переписываться как качество продукции. Некоторые идеи, которые я использовал:

  • напишите предварительно написанный сетевой клиент, используя сценарии оболочки (netcat и bash)
  • напишите сервер на Python, Ruby или другом знакомом языке RAD с
  • используйте технологию, которая проще, чем ваша технология производства (общайтесь через статические файлы вместо TCP или используйте очень простой механизм RPC вместо промежуточного продукта)
  • используйте программное обеспечение с несовместимым лицензированием, поэтому продукт не может быть выпущен (GPL хорош для этого, для всего, что действительно распространяется).
  • напишите веб-форму как статическую HTML-страницу (без стиля или чего-либо, уродливого, как грех)
  • по возможности заменить любой удаленные взаимодействия (база данных, сеть) с локальными взаимодействиями объектов, с размахиванием руками, чтобы сказать: "действительно, эти два шага будут происходить отдельно"
8

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

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

3

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

2

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

модульное тестирование Python использует отражение, чтобы вывести, что это тесты и ловит обычные asesrtions. В целом, для начала требуется очень мало усилий - я использовал Python таким образом, чтобы разработать сетевые протоколы, а также обернуть преобразования командной строки XSLT с помощью Saxon jars.

играя с фрагментами в тестовом режиме, вы будете держать ваше приложение PoC становится слишком запутанным, и вы создадите основу для тестирования в будущей реализации.

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

2

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

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

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

2

Это может занять немного больше времени для первоначальной настройки, но если вы можете использовать инъекцию зависимостей/IOC framework сразу же, это значительно упростит замену различных реализаций вещей. Весна / Весна.NET очень помогли мне.

1

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

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

1

Я однажды сделал аналогичный проект, используя Delphi 7 и MIDAS. Реализован уровень взаимодействия (in-process AppServer в моем случае) в виде dll-файлов, позволяющих проекту получать доступ к различным источникам данных (например, SQL, Access, Excel и COM-объектам и т. д.).

1