As a proof of concept - I'd take each bit individually and write fake wrappers for the rest. One of the dangers of making prototypes and proofs of concept is that if they are close enough to functional, they tend to end up as an end-product.
Write as much as possible in a unit test framework in a high-productivity language such as Python.
Python unit testing uses reflection to deduce things are tests and catches the normal asesrtions. All up, it requires very little effort to get started - I've used Python in this manner to work out networking protocols as well as wrap command-line XSLT transformations using Saxon jars.
By playing with the fragments in a test-driven manner, you will keep your PoC app from becoming too entangled and you will set the basis for testing in the future implementation.
Even when you're committed to a particular language for the main app, consider something more lightweight for any helpers, such as simple servers testing a network protocol.
For prototyping proof of concept apps it can sometimes be useful to use programming languages that are well suited to Rapid Application Development.
Python is a good example. You have a huge framework to leverage and create the various layers of abstraction you mentioned in your post while still keeping the proof of concept apps code size to a minimum.
Working applications speak louder than words so if you could whip up a quick prototype for your team to see and play with it helps make the tumblers fall into place for them.
It might take a little longer to setup initially, but if you can use a dependency injection/IoC framework right off the bat, it will make it a lot easier to swap out various implementations of things. Spring/Spring.NET have helped me immensely.
I find that drawing pictures and diagrams always helps me get my point across. It also helps me think things through for myself when I run into problems.
You might be able to give your teammates a better understanding of what you're talking about just by showing them some drawings of what you have in mind.
I once did a similar project using Delphi 7 and MIDAS. Implemented the Interop layer (in-process AppServer in my case) as dll files allowing the project to access various data sources (e.g. SQL, Access, Excel and COM objects, etc).
I agree with other responses about getting a prototype up. One way to make sure that your prototype remains as such is to use a language or toolchain that would definitely not be used in the final product, thus forcing it to be rewritten as production-quality. Some ideas I've used:
Write a pre-scripted network client using shell scripts (netcat and a lot of bash)
Write a server in Python, Ruby, or another RAD language you're familiar with
Use a technology that is simpler than your production technology (communicate via static files instead of TCP, or use a very simple RPC mechanism instead of a middleware product)
Use software with incompatible licensing, so the product cannot be released (GPL is good for this, for anything that actually gets distributed).
Write a web form as a static HTML page (no styling or anything, ugly as sin)
If possible replace any remote interactions (database, network) with local object interactions, with handwaving to say "really these two steps would occur separately"
In my experience the best way to get this moving quickly is to code it all as fast as possible in one (or as few as possible) layer, real nasty and heartbreaking. Then once your code-barf is working, start with one of the layers in your list and separate. Repeat until you have the layers you want.
This also has the added benefit of being able to pull up a specific bit and ask your colleagues to pretend it is separated out. If they can do that, you don't have to spend the time actually doing it.
发布评论
评论（8）
作为概念证明 - 我会单独获取每个部分并为其余部分编写假包装。 制作原型和概念验证的危险之一是，如果它们足够接近功能，它们往往最终会成为最终产品。
As a proof of concept - I'd take each bit individually and write fake wrappers for the rest. One of the dangers of making prototypes and proofs of concept is that if they are close enough to functional, they tend to end up as an end-product.
在单元测试框架中尽可能多地使用高生产力语言（例如Python）编写。
Python 单元测试使用反射来推断事物是测试并捕获正常的断言。 总而言之，它只需要很少的努力就可以开始 - 我以这种方式使用 Python 来制定网络协议以及使用 Saxon jar 包装命令行 XSLT 转换。
通过以测试驱动的方式使用这些片段，您将防止您的 PoC 应用程序变得过于混乱，并为未来实施中的测试奠定基础。
即使您致力于主应用程序使用特定语言，也要考虑为任何帮助程序使用更轻量级的语言，例如测试网络协议的简单服务器。
Write as much as possible in a unit test framework in a high-productivity language such as Python.
Python unit testing uses reflection to deduce things are tests and catches the normal asesrtions. All up, it requires very little effort to get started - I've used Python in this manner to work out networking protocols as well as wrap command-line XSLT transformations using Saxon jars.
By playing with the fragments in a test-driven manner, you will keep your PoC app from becoming too entangled and you will set the basis for testing in the future implementation.
Even when you're committed to a particular language for the main app, consider something more lightweight for any helpers, such as simple servers testing a network protocol.
对于概念验证应用程序的原型设计，有时使用非常适合快速应用程序开发的编程语言会很有用。
Python 就是一个很好的例子。 您有一个巨大的框架来利用和创建您在帖子中提到的各个抽象层，同时仍将概念验证应用程序代码大小保持在最低限度。
工作应用胜于雄辩，因此，如果您可以快速制作一个原型供您的团队查看和使用，则有助于让不倒翁就位。
For prototyping proof of concept apps it can sometimes be useful to use programming languages that are well suited to Rapid Application Development.
Python is a good example. You have a huge framework to leverage and create the various layers of abstraction you mentioned in your post while still keeping the proof of concept apps code size to a minimum.
Working applications speak louder than words so if you could whip up a quick prototype for your team to see and play with it helps make the tumblers fall into place for them.
最初的设置可能需要更长的时间，但是如果您可以立即使用依赖项注入/IoC 框架，那么交换各种事物的实现将会变得更加容易。 Spring/Spring.NET 给了我很大的帮助。
It might take a little longer to setup initially, but if you can use a dependency injection/IoC framework right off the bat, it will make it a lot easier to swap out various implementations of things. Spring/Spring.NET have helped me immensely.
我发现画图片和图表总是能帮助我理解我的观点。 当我遇到问题时，它也可以帮助我自己思考问题。
您只需向队友展示您的想法的一些图画，就可以让他们更好地理解您正在谈论的内容。
I find that drawing pictures and diagrams always helps me get my point across. It also helps me think things through for myself when I run into problems.
You might be able to give your teammates a better understanding of what you're talking about just by showing them some drawings of what you have in mind.
我曾经使用Delphi 7和MIDAS做过一个类似的项目。 将 Interop 层（在我的例子中为进程内 AppServer）实现为 dll 文件，允许项目访问各种数据源（例如 SQL、Access、Excel 和 COM 对象等）。
I once did a similar project using Delphi 7 and MIDAS. Implemented the Interop layer (in-process AppServer in my case) as dll files allowing the project to access various data sources (e.g. SQL, Access, Excel and COM objects, etc).
我同意其他关于建立原型的回应。 确保原型保持原样的一种方法是使用最终产品中绝对不会使用的语言或工具链，从而迫使其被重写为生产质量。 我使用过的一些想法：
netcat和大量bash）编写预先编写脚本的网络客户端I agree with other responses about getting a prototype up. One way to make sure that your prototype remains as such is to use a language or toolchain that would definitely not be used in the final product, thus forcing it to be rewritten as production-quality. Some ideas I've used:
netcatand a lot ofbash)根据我的经验，快速实现这一目标的最佳方法是在一层（或尽可能少的）层中尽可能快地编码，这确实令人讨厌和令人心碎。 然后，一旦您的代码栏开始工作，就从列表中的一层开始并分开。 重复直到获得所需的图层。
这还有一个额外的好处，即能够提取特定的位并要求您的同事假装它已被分离出来。 如果他们能做到这一点，您就不必花时间实际做这件事。
In my experience the best way to get this moving quickly is to code it all as fast as possible in one (or as few as possible) layer, real nasty and heartbreaking. Then once your code-barf is working, start with one of the layers in your list and separate. Repeat until you have the layers you want.
This also has the added benefit of being able to pull up a specific bit and ask your colleagues to pretend it is separated out. If they can do that, you don't have to spend the time actually doing it.