Ingénierie de l'application et nombre d'utilisateurs

Question

Outre les problèmes de performances, les applications Web devraient-elles être construites différemment selon le nombre d'utilisateurs (concurrents)? Si oui, quelles sont les principales différences pour (par exemple) 4, 40, 400 et 4000 utilisateurs?

Je suis particulièrement intéressé par la façon dont la journalisation, la gestion des erreurs, les modèles de conception, etc. seraient utilisés en fonction du nombre d'utilisateurs simultanés.

Answer 1

Je ne suis pas un expert dans ce..mais voici ce que je pense.

L'utilisation de modèles de conception étendus, la création de capacités de journalisation étendues, etc. peut ne pas être très nécessaire si l'application est utilisée par 4 utilisateurs connus - dans la mesure où chaque unité d'effort supplémentaire rapporte moins. Cependant, si l'application doit être utilisée par un plus grand nombre de personnes, vous avez des inquiétudes telles que l'évolutivité, la sécurité, etc. L'utilisation de modèles de conception, etc., peut être plus logique. Bien sûr, je fais l'hypothèse que si seulement 4 personnes utilisent une application - ce n'est probablement pas très critique.

Donc je crois que vous devriez commencer simple, et apporter des modifications au besoin. Cependant, suivre de bons modèles de conception est toujours bon - idéalement, votre conception vous permet de changer les pièces au besoin.

Answer 2

La réponse donnée par aip.cd.aish m'a donné cette idée:

Je pense que la réponse est d'estimer le coût par rapport avantage relatif de l'effort d'ingénierie dans une situation donnée.

Il n'est pas rare que les applications avec moins d'utilisateurs ajoutent moins de valeur à l'entreprise, mais vous devez examiner attentivement chaque cas.

En effet, il existe des cas où moins d'utilisateurs justifient de plus effort d'ingénierie. Par exemple, si votre application est utilisée par quelques clients clés qui iront ailleurs à moins que votre offre n'offre un meilleur service que vos concurrents, alors vous pourriez être justifié de passer du temps sur une ingénierie solide.

idées spécifiques:

Logging: Pour les applications "petits", vous pouvez être mieux en train de parler aux utilisateurs (... je sais ...) plutôt que de tout l'exploitation forestière. Pour les applications «volumineuses», la consignation aléatoire peut signifier que les journaux se développent trop rapidement pour être très utiles.