Qual é a diferença entre um protótipo e uma solução em nível de produção?

Esta pergunta é apenas para aprendizado e aprimoramento do meu entendimento técnico. Sei que não há uma solução perfeita e essa pergunta é possível, sem fim, lista de soluções, mas acho que é muito importante para todo arquiteto entender a diferença entre demo e um projeto ao vivo.

Eu criei muitas soluções de demonstração em .Net no passado. Agora, fui designado para arquitetar e implementar uma solução da web em nível de produção, então eu queria perguntar - em um nível muito alto, o que é necessário para converter uma demonstração em uma solução em nível de produção. Pelo meu entendimento, isso exigirá (além da implementação funcional dos requisitos dos clientes):

1. Unidade de teste de todos os métodos
2. Garantindo ~ 100% de cobertura do código
3. Registrando todas as exceções e possíveis cortes de pontos - possível com o AOP
4. Usando padrão de design de interface, injeção de dependência, possivelmente usando uma estrutura, por exemplo, spring.net
5. Usando contadores e criadores de perfil de desempenho para instrumentação
6. Aplicação de segurança apropriada - ou seja, autenticação do Windows (se for o que for exigido pelo cliente).
7. Gerenciamento de transações em todos os métodos
8. Backup dos arquivos de aplicativos da web antes da nova implantação da solução

O quê mais?

Minha pergunta está mais relacionada ao lado técnico, em vez de funcional / documentação, caso contrário, iremos para outro caminho :-)

Obrigado.

Eu acho que a diferença mais importante é que o objetivo de um protótipo é:
1. Provar que um problema pode ser resolvido de uma certa maneira OU
2. Dar ao cliente / gerência uma ideia de como o produto seria e se pareceria

considerando que o objetivo de um sistema ativo é:
1. Solucionar um determinado problema / resolver um problema.

Observe que os objetivos dos dois são completamente diferentes .
Portanto, na minha opinião, um protótipo deve ser jogado fora antes de desenvolver um sistema ativo .

Isso também ocorre porque um protótipo geralmente é um projeto 'rápido e sujo', reunido sem nenhuma das considerações que você apontou corretamente na sua pergunta (como teste, desempenho, segurança e muito mais).
Portanto, seria melhor iniciar um projeto novo e adequado do que tentar melhorar um projeto ruim.

Nem todas essas coisas são necessárias, dependendo das suas necessidades, ou pode ser muito mais necessário. Se você entende o que quero dizer;) Testes de unidade e cobertura de código são coisas boas, mas dependendo de como você realiza outras partes do processo, pode não ser necessário. Alguns diriam que mais importante do que a criação de perfil de desempenho é um código bem documentado ou um manual de treinamento. Varia!

Sei que você está olhando para o lado técnico, mas espero que você entenda meu ponto, isso varia dependendo do lado não técnico. Ou pelo menos deveria.

O uso de contadores e criadores de perfil de desempenho para instrumentação .. pode ser adequado, mas pode ser um exagero maciço. Pode não ser necessário.

O que você está perdendo aqui é deixar de levar em conta o contexto, o escopo e os requisitos de negócios do projeto.

Por contexto e escopo, quero dizer - você está criando algo para ser usado internamente por uma empresa? Voltado para o cliente? Utilizado pelos usuários finais? É de fato uma versão jazzística do Bloco de Notas ou um novo RDBMS do zero? O que deve ser incluído variará enormemente (massivamente!) De acordo com o projeto que você está visualizando.

Por requisitos de negócios, não quero dizer os casos de uso do software, mas os requisitos do processo de gerenciamento / produção do projeto. Se você insistir em precisar de todas essas coisas para um projeto de produção, o custo será refletido de acordo (muito alto). Isso pode significar que está acima do orçamento, atrasado, ou nem mesmo recebe luz verde para iniciar o desenvolvimento.

Pode ser que mais importante do que ter um conjunto fixo de critérios agora seja simplesmente ter uma boa estrutura de produção / desenvolvimento, alta visibilidade e liberações regulares para que a qualidade possa ser avaliada dessa maneira. Pode ser que ninguém envolvido se importe com a cobertura do código.

Curiosamente, acho que os pontos 1, 2, 4 e 7 já devem ser feitos durante a concepção do seu protótipo, exceto que eu não acho que você deva testar todos os métodos em todas as classes. Teste o código crítico, não se os métodos get / set se comportam corretamente.

Dependendo do objetivo do seu aplicativo, onde a segurança é um grande problema, o ponto 6 pode ser crítico o suficiente para que você precise atingi-lo no protótipo. Dependendo do objetivo do seu aplicativo, onde o desempenho é a chave, o ponto 5 pode ser crítico ... Você entende o que quero dizer. Minha opinião é que os pontos 3, 5 e 6 podem ser necessários no protótipo se forem considerados críticos (o ponto 8 é realmente válido para aplicações de produção)

Edit: parece que minha opinião difere completamente da de sJhonny, porque insinuo que considero o protótipo a base / invólucro / esqueleto de seus desenvolvimentos futuros, portanto, para mim, o protótipo não deve ser jogado fora.

Além do que já foi mencionado, em um projeto de produção você precisa do seguinte (entre outros):

0-Escolha uma metodologia de implementação

1-Finalize e publique os principais requisitos (incluindo casos de uso, etc.)

2-Faça a arquitetura certa

3-Selecione as ferramentas corretas

Banco de dados de 4 projetos para desempenho

5-Produza seu design de classe e design de fluxo de trabalho

6-Determinar e implementar uma estratégia para integrar bancos de dados / fontes de dados / feeds suportados

7-Definir e implementar requisitos de segurança

8-Organize a implementação física (servidores, conectividade, licenças, etc.)

9 - Planeje os requisitos de armazenamento e determine as medidas de desempenho

10-Produza todos os artefatos e instale no ambiente de produção

11-Test

12-Forneça a solução final e implemente o feedback

A característica mais importante das soluções de qualidade de produção é - na minha opinião - robustez .

Independentemente do que aconteça, a solução lida com a situação de maneira sensata, notifica quem precisa saber e continua (se o erro for recuperável).

Existem dois tipos de protótipos:

• Aplicações rápidas e sujas de "prova de conceito" que são "limpas" e se tornam código de produção. O estágio "limpeza" tende a ser um pesadelo ou é realmente um estágio "varrer os problemas para baixo do tapete", resultando em uma enorme dívida técnica.

• Protótipos de "Maquete" ou "wireframes". Podem ser esboços de interface do usuário em papel e lápis ou até maquetes interativas feitas em um idioma em que você pode reunir rapidamente esse tipo de coisa sem pensar muito em como ela se encaixa. Ele deve usar dados falsos, sem arquitetura real, etc. O ponto é que eles dão às partes interessadas uma idéia de como será o sistema, para que você possa refinar seus requisitos, mas eles não podem ser usados ​​como parte da sua solução final .

Eu prefiro o segundo tipo. Eles são jogados fora, porque não há realmente uma escolha.

Digo construí-lo como um projeto sem demonstração, mas agora você pode incluir o que aprendeu com a demonstração em seu design. A codificação inicial pode ser ruim mesmo quando você inicia a produção. Você terá que refatorar muito disso de qualquer maneira.

O verdadeiro problema para resolver é a sua contra-indicação do tempo. Quando os tomadores de decisão querem que você continue trabalhando na demonstração, eles têm a impressão de que grande parte do aplicativo está pronta, por isso não vai demorar. Ouvi outras pessoas usarem essa lógica sobre o motivo pelo qual preferem mostrar esboços aos clientes, em vez de modelos muito realistas. Preste atenção ao código de demonstração, pois ele pode ter descoberto problemas nos quais você nunca pensou e provavelmente não documentou esse processo. Agora você precisa considerá-los (simplificado demais, mas sim, o banco de dados pode não estar acessível, por exemplo).

Todos os protótipos e demonstrações não são criados iguais. O código inteiro pode ser inútil ou certas partes podem ter sido muito bem executadas. Não importa se é uma demonstração, você precisa saber a diferença. Você não jogaria apenas um aplicativo legacay e começaria do zero? Esqueça eu perguntei.