原型和生产级解决方案之间有什么区别？

这个问题纯粹是为了学习和加强我的技术理解。我知道没有完美的解决方案，这个问题可能永远也不会结束，但是我认为对于每个架构师来说，了解演示和实际项目之间的区别非常重要。

过去，我在.Net中创建了许多演示解决方案。我现在已被分配给架构师并实现生产级别的Web解决方案，所以我想问-在一个很高的水平上，将演示转换为生产级别的解决方案需要什么。据我了解，这将需要（除了在功能上实现客户的要求以外）：

1. 每种方法进行单元测试
2. 确保实现约100％的代码覆盖率
3. 记录所有异常和可能的切入点-AOP可能记录
4. 使用接口设计模式，进行依赖项注入，可能使用诸如spring.net之类的框架
5. 使用性能计数器和分析器进行检测
6. 应用适当的安全性-即Windows身份验证（如果这是客户端所要求的）。
7. 每种方法的交易管理
8. 在新部署解决方案之前备份Web应用程序文件

还有什么？

我的问题与技术方面而不是功能/文档更多相关，因为否则我们将走另一条路:-)

谢谢。

我认为最重要的区别是原型的目标是：
1.证明可以某种方式解决问题，或者
2.使客户/管理人员对产品的外观有何感觉

而实时系统的目标是：
1.解决特定问题/解决问题。

注意，两者的目标完全不同。
因此，我认为在开发实时系统之前应丢弃原型。

这也是因为原型通常是一个“快速而肮脏的”项目，没有您在问题中正确指出的任何考虑因素（例如测试，性能，安全性等等），就将它们放在一起。
因此，与尝试使一个不好的项目变得更好相比，开始一个新的，适当的项目会更好。

根据您的要求，并非所有这些事情都是必需的，或者可能还有更多要求。如果您知道我的意思；）单元测试和代码覆盖都是不错的选择，但是根据您进行该过程的其他部分的情况，可能不需要。有人会说，比性能分析更重要的是记录良好的代码或培训手册。变了！

我意识到您正在研究技术方面，但希望您能理解我的观点，具体取决于非技术方面。或者至少应该如此。

使用性能计数器和性能分析器进行检测..可能是合适的，但可能会导致过多的杀伤力。可能不是必需的。

您在这里缺少的是无法考虑项目的上下文，范围和业务需求。

通过上下文和范围，我的意思是-您是否正在创建某种东西供企业内部使用？面向用户的？最终用户使用过吗？它实际上是爵士版的记事本，还是从头开始的新RDBMS？应该包含的内容将根据您正在查看的项目而有很大不同（很大！）。

根据业务需求，我并不是指软件的用例，而是项目管理/生产过程的需求。如果您坚持认为生产项目需要所有这些东西，那么成本将相应地反映出来（非常高）。这可能意味着它超出预算，太迟了，或者甚至没有获得开始开发的绿灯。

比现在拥有一套固定的标准更为重要的是，简单地拥有一个良好的生产/开发框架，高可见性和定期发布，以便可以通过这种方式评估质量。可能没有人提供有关代码覆盖率的废话。

有趣的是，我认为在原型设计期间应该已经完成​​了第1、2、4和7点的工作，但我认为您不应在每个类中测试每个方法。测试关键代码，而不是测试get / set方法是否正确运行。

根据应用程序的用途（安全性是一个大问题），第6点可能非常关键，因此您需要在原型中实现它。根据性能的关键所在，取决于应用程序的用途，第5点可能很关键……您知道我的意思。我的观点是，如果认为第3、5和6点很关键（第8点对于生产应用程序确实有效），则它们可能是必需的。

编辑：看来我的观点与sJhonny完全不同，因为我暗示我认为原型是您未来开发的基础/外壳/骨架，因此对我而言，原型不应被丢弃。

除了已经提到的内容之外，在生产项目中，您还需要以下内容：

0-选择一种实施方法

1-完成并发布主要需求（包括用例等）

2-建立正确的架构

3-选择正确的工具

4-设计数据库以提高性能

5-生产您的班级设计和工作流程设计

6-确定并实施整合后备数据库/数据源/提要的策略

7-定义和实施安全要求

8-安排物理实施（服务器，连接性，许可证等）

9-计划存储需求并确定性能指标

10-生产所有工件并安装在生产环境中

11测试

12-提供最终解决方案并实施反馈

我认为，生产质量解决方案的最重要特征是坚固性。

无论发生什么情况，该解决方案都会明智地处理这种情况，通知需要了解的信息，然后继续解决（如果错误是可恢复的）。

有两种原型：

• 快速，肮脏的“概念验证”应用程序得到“清理”并成为生产代码。“清理”阶段往往是一场噩梦，或者实际上是“扫除地毯下的问题”阶段，从而导致大量技术债务。

• “样机”原型或“线框”。这些可以是纸和铅笔的UI草图，甚至可以是用一种语言完成的交互式模型，在这种语言中，您可以快速将此类内容放到一起，而无需考虑如何将它们组合在一起。它应该使用伪造的数据，没有真实的体系结构等。重点是，它们可以使利益相关者了解系统的外观，以便您可以优化需求，但不能将其用作最终解决方案的一部分。 。

我喜欢第二种。他们被扔掉了，因为真的没有选择。

我说它像没有演示的项目一样进行构建，但是现在您可以在设计中包括从演示中学到的知识。即使开始生产，初始编码也会很糟糕。无论如何，您将不得不重构其中的大部分内容。

要解决的真正问题是您的时间矛盾。当决策者希望您继续进行演示时，他们会觉得很多应用程序已准备就绪，因此用时不长。我听说其他人使用这种逻辑来说明为什么他们更喜欢向客户显示草图，而不是过于现实的模型。请注意演示代码，因为它可能发现了您从未想到的问题，并且在此过程中可能没有记录。现在，您必须考虑它们（过于简化，但是是的，例如，可能无法访问数据库。）。

不是所有的原型和演示都一样。整个代码可能一文不值，或者某些部分做得很好。不管是演示版都没有关系，您必须了解其中的区别。您不仅会扔掉一个传统的应用程序，然后重新开始吗？忘了我问。