Quais são as características ou recursos do código de qualidade da produção?

Esta é a primeira vez que entregarei código para um projeto freelancer (aplicativo da web) e, como não tenho muita experiência em código de remessa, estou tendo dificuldades para decidir se meu programa está pronto para implantação ou não.

Meu entendimento é que um código em nível de produção deve ter as seguintes características:

• Tolerância a falhas : capacidade de sobreviver a exceções não capturadas
• Redundância de dados : nunca perca dados do usuário
• Escalabilidade : manipular carga extra não deve exigir a reescrita do aplicativo
• Cobertura de teste : uma quantidade "decente" de código testado

Algumas dessas características são específicas para o próprio programa, enquanto outras são mais relacionadas ao ambiente (seja usando vários clusters). No entanto, mesmo as características dependentes do ambiente afetam a maneira como o programa é projetado.

Minha pergunta então é: Quais são as outras características que tornam o código de produção tão diferente do código não destinado à produção?

Apenas para reduzir o escopo da pergunta, concentre-se apenas nos aplicativos da web .

Edit : Vou tentar restringir o escopo, pedindo características específicas para a minha situação. Como freelancer, eu era responsável por tudo, desde comprar um VPS, configurá-lo, escrever o código e implantá-lo. Embora o projeto e sua configuração estejam bem documentados, o cliente não poderá mantê-lo. O aplicativo não é complexo, mas depende de muitos componentes externos, o que o torna muito propenso a quebrar se esses componentes forem alterados / desaparecerem. O objetivo é configurar um serviço que possa durar o maior tempo possível sem a intervenção do cliente.

"código de qualidade de produção" é qualquer outro usuário, que não seja você, é ...

1. capaz de usar sem ou com suporte mínimo. Se toda ação for atendida com um bug, seu software irá para o lixo
2. capaz de entender como usar com o mínimo de suporte ou documentação. Se o usuário não conseguir entender como usar o software, ele entrará no lixo.
3. disposto a usar porque agrega valor. Se o seu software agregar valor suficiente, talvez eles lhe dêem dinheiro por isso. Se não agregar valor suficiente para você distribuí-lo gratuitamente, seu software irá para o lixo.

É ISSO.

Algumas pessoas precisam de tolerância a falhas absoluta. Outros não se importam tanto se alguns dados forem perdidos quando houver uma falha ... presumindo que elas ocorram falhas com pouca frequência. Não há qualidades ou requisitos rígidos. E nenhum cliente se preocupa com a cobertura do teste, o que importa é os três pontos acima. A cobertura de teste é uma ferramenta (uma de muitas) que você pode usar para chegar lá, mas muitos softwares, alguns deles até bons, foram construídos com nada além de testes manuais.

Qualquer que seja o software que você construa, os requisitos estão entre você e seu cliente e, se você estiver construindo um software para consumo geral, escolha um ou poucos grupos-alvo e não tente ser tudo para todos. Tentar inventar algum tipo de molde genérico parece-me bastante tolo.

Em vez disso, ao tentar prever ou adivinhar quando seu software estará pronto para produção, por que você não trabalha com seu cliente? Dê uma pré-visualização, mas explique que não está pronto para produção. Publique-o em seu próprio servidor e peça que eles o usem, bisbilhotem e dê feedback. Continue trabalhando com eles até que estejam felizes com o que você lhes deu. Em outras palavras, eles informarão quando a produção estiver pronta.