Você pode prototipar uma mudança complexa no sistema?

Parece-me que você pode distinguir entre o código que faz o trabalho e o código que se comunica entre os servidores. Como a diferença entre o Apache e o TCP / IP. Você pode prototipar sua nova rede de comunicação entre os servidores sem ter nenhum código de trabalho de nível superior. Se houver uma rede existente funcionando OK, deixe-a em paz e crie seu protótipo de rede de comunicação independente disso. Interconecte os aplicativos do psuedo em vez dos aplicativos reais. Isso pode ser criado e testado.

Outra etapa pode ser "escutas" do sistema existente. Quando o sistema S1 disser "Olá" para o sistema S2, seu código X1 verá S1 dizer "Olá" e transmitirá isso para seu código X2, que então compara o que ouviu de X1 e o que S2 ouviu de S1.

Não há muito para ver na tela, mas você estaria fazendo o protótipo da parte crítica de seu novo sistema.

O seu servidor de aplicativos está dividido em micro-módulos ou kernels (ala JBoss)? Nesse caso, você poderia talvez prototipar o núcleo mínimo que está sendo distribuído entre as máquinas.

Você, é claro, precisa deixar claro que aspectos como mensagens remotas, mensagens e distribuído ainda precisam ser trabalhados, mas pelo menos você terá um começo.

Se você está falando de um servidor de aplicativos estilo bola monolítico, então sim, é improvável que você possa prototipá-lo rapidamente. Nesse caso, eu sugiro construir um 'palhaço' que represente os pontos fracos do que você está tentando alcançar. Hmm, isso provavelmente não estava claro. Por exemplo, você pode criar algumas classes representando uma parte móvel do servidor de aplicativos (digamos, transações) e implementar sua ideia de distribuição em toda a extensão.

Por protótipos, eles significam um protótipo de código real, ou eles estão realmente procurando por um projeto detalhado? Talvez eles estejam procurando por telas ou interfaces simuladas e apenas chamando-os de protoptyes? Se eles estão procurando por um protótipo de código antes ou junto com o design, é uma má idéia. Prepare o design de nível mais alto primeiro e discuta-o com sua equipe / cliente. O ir para o design detalhado e interfaces. Convença-os de que fazer um código "protótipo" não é realmente possível.

Geralmente protótipos ou stubs invocam uma grande quantidade de códigos próprios e não devem ser feitos a menos que você realmente precise de uma "prova de conceito": para mostrar que algo pode (ou não pode ser feito) (algo como mudar para um novo biblioteca ou portando um aplicativo). Ou talvez você precise de stubs para implementar códigos de nível mais alto sem criar primeiro um código de nível inferior. Eu não sei se este é o seu caso, mas se não há uso justificado para o seu protótipo, oponha-se à ideia educadamente, mas com firmeza.

É muito raro que os problemas não possam ser divididos em partes menores. Quanto mais complexo o projeto, mais pedaços podem ser quebrados.

Se você fosse projetar um aplicativo distribuído do zero, certamente o resultado final não será o primeiro resultado testado. Assim como quando você projeta um videogame, por exemplo, você pode ter certeza de que seus comandos básicos de vídeo funcionam, então trabalhe na interação com o usuário, então trabalhe em partes do cenário do jogo ... Mesmo com um aplicativo distribuído.

Dito isso, um protótipo, ou uma prova de conceito, geralmente não está diretamente relacionado ao aplicativo em que você trabalha. É uma aplicação simplificada que demonstra os principais requisitos ou recursos de design que você planeja implementar.

Se um protótipo ou uma prova de conceito é um investimento adequado ou não é para você discutir com seu chefe, com seu conhecimento e situação específicos. Mas geralmente eu não acho que há muitas situações em que isso não é possível. Pode não ser custo ou tempo efetivo, ou você pode não saber como construir um efetivamente.

Tenha em mente que um protótipo, dependendo do que você pretende provar, não precisa necessariamente ser construído usando as mesmas ferramentas que o produto acabado. Especialmente se você está apenas tentando provar os conceitos gerais & arquitetura. Se você pode reduzir os requisitos para os menores conceitos significativos que precisam ser testados para convencer seu chefe a investir mais, então você tem a definição do que seu protótipo deve ser.

Tudo pode ser prototipado

Se um problema parece ser muito complexo para o protótipo, divida-o em problemas menores e faça um protótipo de cada um deles.

No entanto, neste caso, eles querem que as alterações subjacentes funcionem, antes de você ir e alterar o aplicativo existente.

Você - obviamente - não pode fazer isso no aplicativo existente sem realmente fazer todo o trabalho, então o que eles estão procurando é um aplicativo de amostra simples e leve (novo código) que exerça os mecanismos que você colocará no aplicativo. aplicativo existente.

Este novo protótipo deve ser o mais simples possível, enquanto ainda exercita as áreas problemáticas da aplicação existente (tão simples quanto possível, mas não mais simples).

Eles podem testar o protótipo para consumo de memória / balanceamento de carga, etc. e comprovar que o esforço para atualizar o aplicativo existente é econômico.

Sim , você deve prototipar alterações de software grandes e complexas.

O velho ditado, "medir duas vezes, cortar uma vez" se aplica aqui. A partir do seu protótipo, você obterá uma compreensão inestimável do comportamento do sistema e dos possíveis problemas que poderá encontrar nas mudanças reais. O que você aprende pode afetar drasticamente a solução final! É fácil pensar que consideramos todas as ramificações, mas especialmente com mudanças grandes e complexas que não podemos ter. Existem problemas ou dependências que perdemos. Você quer que sua solução final seja pura e pronta para produção.

Michael Feathers recomenda uma tática semelhante em seu livro, Trabalhando efetivamente com o código herdado - scratch refatoração (pp. 212-213.264): "Basta entrar lá", diz ele, "e começar a mudar as coisas e tornar o código mais claro ... apenas não verificar ..." para entender melhor o código e para elicitar problemas que você terá que resolver quando estiver pronto para fazer as alterações reais.