Come convincere i miei compagni di squadra che generano numerosi thread è un cattivo design? [chiuso]

La generazione di un nuovo thread per ogni attività non è necessariamente un cattivo progetto, ma ci sono alcuni fattori che devono essere presi in considerazione:

• Il cambio di contesto tra i thread richiede tempo. Se il numero di thread eseguibili diventa molto grande (un ordine di grandezza maggiore del numero di core / processori disponibili), ciò può influire negativamente sulle prestazioni percepite dell'applicazione
• Ci sono solo così tanti thread che puoi creare. Se non esiste un limite superiore al numero di thread creati da un'applicazione, l'applicazione esaurirà le risorse prima o poi.
• La creazione di una nuova discussione è un'operazione pesante. Se crei un nuovo thread per ogni attività a breve durata, potresti scoprire che la creazione del thread richiede una parte significativa del tempo in cui quei thread "esistono". L'utilizzo di una coda di lavoro e un pool di thread potrebbe effettivamente aumentare le prestazioni dell'applicazione.

Sono sicuro che devi spiegare loro cos'è Pool di thread . E ogni framework solido ne ha uno implementato e le persone che lo hanno implementato sono probabilmente molte volte migliori di loro per risolvere questo tipo di problemi.

Non gestire manualmente i thread se non è necessario e si tenta invece di utilizzare un pool di thread. Praticamente tutte le lingue e i runtime che supportano i thread hanno anche un'implementazione del pool di thread incorporata nella libreria standard. Quindi utilizzare thread in sé e per sé non è una cattiva idea, ma la gestione manuale dei thread può sfuggire di mano abbastanza rapidamente, quindi all'inizio cerca di restare fedele a qualsiasi gestione di thread di alto livello sia integrata.

È difficile proporre una soluzione a persone che non pensano di avere un problema. La tua app si arresta in determinate circostanze è considerata accettabile. Come tutto, c'è un livello di rischio e di ricompensa. Puoi provare ad avvicinarti in una o entrambe le direzioni.

1. Will "è stato progettato in questo modo" essere accettabile per gli utenti / clienti? Personalmente, suggerirei che il design sia difettoso (e il designer è un idiota per averlo fatto intenzionalmente) e deve cambiare perché andrò a cercare un'app che non si arresti. I tuoi colleghi vogliono affrontare queste lamentele? Forse è più semplice correggerlo?
2. La correzione è difficile? Un sacco di suggerimenti forniscono quadri che si occupano di discussioni per la maggior parte. Quanto sarebbero difficili da usare?

"È così che è stato progettato." "È così che l'abbiamo sempre fatto." Se vogliono obiettare che i clienti non si preoccupano e / o che la correzione è troppo difficile da fare a causa di caratteristiche più importanti o il rischio di ostacolare ulteriormente l'applicazione sembrerebbe molto più simile a come hanno pensato un po '.