Dissidenze tra capo programma e me, cosa dovrei fare? [duplicare]

prova il valore

o accetta che al momento non è una priorità per loro

forse entrambi

Sia che il leader del tuo programma sono parzialmente a destra .

Un programma che perde memoria è in effetti un potenziale problema se porta a un processo (oltre al supporto essenziale del sistema operativo) che occupa più memoria di quella che il suo computer host è fisicamente disponibile. In teoria, puoi conviverci se la memoria sprecata sta lentamente scomparendo, ma troppo spesso non funziona così. Una volta che molta memoria viene rimescolata da e verso il disco, le prestazioni sono distrutte . Inoltre, può richiedere molto tempo per cercare perdite di memoria (la strumentazione di memoria è piuttosto costosa), quindi non è una buona idea lasciarla appena prima del rilascio, in quanto aggiunge troppo rischio al programma del progetto.

D'altra parte, non ha senso mettere uno stupido sforzo nella ricerca di perdite di memoria una volta che hai fatto le cose sotto il punto in cui non sono più un problema sull'hardware disponibile e il tempo impiegato nell'esecuzione. La disponibilità media della memoria è decisamente in aumento, e sul lato server è sicuramente possibile calcolare la quantità di hardware da gettare al codice.

Quindi, non c'è motivo di conflitto. Hai solo prospettive diverse.

Ma non è un piano d'azione! Cosa dovresti fare? Suggerisco di non avere discussioni su questo argomento (dopotutto, hai entrambi solo parzialmente ragione) e invece di concentrarti sul cercare di assicurarti che il codice che scrivi non abbia perdite di memoria in esso. Dopotutto, è sempre così raro che una perdita di memoria sia una buona cosa! È molto meglio farlo bene la prima volta. Prestare particolare attenzione quando si lavora con il codice client, poiché è molto più probabile che sia necessario eseguire piccole quantità di memoria e perdite di memoria, con un impatto maggiore sulla qualità percepita dei clienti dell'intero sistema. Per quanto riguarda i server, concentrarsi in particolare sulle perdite nel percorso del servizio critico, poiché potrebbero danneggiare enormemente la distribuzione. All'altra estremità della scala, una perdita una tantum (ad esempio, nell'analisi del file di configurazione del server) non vale la pena di andare a caccia. E non andare a caccia di perdite nel codice prodotto da altri membri della tua squadra ancora; hai bisogno del consenso del leader del tuo programma per questo e lui deve bilanciare questo compito con tutti gli altri importanti che hanno bisogno di fare.

Dovresti ascoltare la tua guida alla programmazione. Ottimizza solo quando necessario, quando il programma funziona. E la memoria è economica. Se riesci a ottenere 4 GB per cento dollari e il problema è risolto, non vale nemmeno la pena di prendere in considerazione solo un'ora di lavoro nell'ottimizzazione dell'utilizzo della memoria.

Il tuo lead potrebbe aver ragione di dare priorità al comportamento giusto prima di provare a migliorare l'utilizzo della memoria. Personalmente, mi concentrerei sul comportamento prima di concentrarmi sull'ottimizzazione, dal momento che non è sempre chiaro dove si trovano i colli di bottiglia all'inizio o anche a metà del ciclo di vita del prodotto.

Tuttavia, non c'è nulla che ti impedisca di sollevare le tue presumibilmente preoccupazioni ben motivate sullo stato attuale del codice scrivendo un'analisi dello stato delle cose così come sono. Se è possibile fornire una valutazione della pressione della memoria, magari supportata da test delle prestazioni, profilazione, analisi statica o strumentazione di codice progettata per rilevare perdite di memoria, è possibile creare un caso che ci siano motivazioni tecniche e commerciali da investire in quella zona.

Ogni membro del team offre spesso una prospettiva diversa sull'importanza complessiva di una particolare preoccupazione nel sistema. Ma devi sempre soppesare i compromessi tra ottenere qualcosa di spedizione e ottenere il tutto "giusto", con una definizione di "giusto".

Anni fa in un'altra vita, posso ricordare di aver passato ore a cercare di convincere i nostri sviluppatori a correggere un bug che causava un arresto anomalo dell'applicazione in modo affidabile ogni volta che qualcuno cercava di stampare una pagina Web con un'applet Java, solo sull'Asia orientale versioni di Windows 95. Era alta severità, ma nel grande schema di cose, era un problema di bassa priorità per l'obiettivo più grande di ottenere il browser fuori dalla porta. I miei sforzi non hanno fermato il rilascio, ma alla fine è stato un affare abbastanza grande da essere risolto (ha funzionato davvero, davvero) nella prossima versione.

Sollevare le preoccupazioni con prove adeguate, senza sembrare eccessivamente allarmanti, o risulterà in un investimento nel risolvere il problema, o una chiara affermazione da parte della direzione che il problema è un rischio che sono disposti a prendere. O uno di quei risultati va bene. Dovresti concentrarti sul lavoro attraverso i problemi del tuo sistema; non essere troppo attaccato a risultati specifici.

+1 per concentrarsi su una cosa a cui la maggior parte degli sviluppatori non pensa nemmeno. Come ha affermato Steven Lowe, è necessario dimostrare il valore dell'ottimizzazione della memoria. Solo quando il costo lo giustifica, il tuo manager sarà d'accordo. Se si utilizza solo 10 KB di memoria per un'app e si sprecano altri 10 KB non è molto (anche se è 100% di wasteage) perché 10KB non importa a un PC moderno con 2-3gigs di RAM. D'altra parte, se la tua applicazione occupa 1 GB di memoria, anche un 10% di wasteage sarà critico.

Non sono assolutamente d'accordo con il tuo manager sul fatto che le ottimizzazioni possano aspettare fino al rilascio. In fretta, le ottimizzazioni dell'ultimo minuto potrebbero finire per soffiarti in faccia. Se ritieni che il problema sia serio, dovrai fare un caso strong.

Cicli di sviluppo:

1. Funziona correttamente senza errori (il che significa assenza di perdite di memoria)
2. Stabilità (ridimensiona qualsiasi cosa che potrebbe causare problemi di manutenzione lungo la strada)
3. Prestazioni (solo dopo la profilazione, include l'ottimizzazione dell'uso della memoria)
4. Vai a 1

Le prestazioni sono le ultime perché causano rischi e compromessi ai primi due. I ritocchi delle prestazioni possono rompere le cose che funzionano e possono rendere le cose non mantenibili.

I miglioramenti delle prestazioni dovrebbero essere implementati solo quando la profilazione dimostra un valore nel fare il lavoro e fuori pesa il rischio legato alla modifica del codice stabile di lavoro.

Il comportamento scorretto veloce del software non è un successo.

Il software non stabile veloce non è un successo.

In poche parole, il tuo manager è corretto.

Il sistema funzionerà correttamente mentre è in fase di sviluppo, anche se la memoria non è gestita molto bene. Attendi finché non ci sono centinaia di utenti simultanei che colpiscono l'applicazione nello stesso momento. Quindi si sbriciolerà.

La linea di fondo è questa e sarà sempre questa, a meno che non lavori per il governo. Sales Drives Everything. Se questo progetto è in modalità di sviluppo con solo potenziali clienti, è una dimostrazione del concetto. L'obiettivo a questo punto potrebbe essere semplicemente un modello funzionante da mostrare ai potenziali clienti. Non hai intenzione di spendere tonnellate di ore lavorative per realizzare un prototipo perfetto.

Il problema diventa questo ... quando mostri al management che hai un modello funzionante tutto ciò che è qui è la parola funzionante . Non hanno idea che sia solo una prova di concetto. Iniziano a venderlo e ora devi scramble perché tutti i problemi di memoria che hai rilevato iniziano a emergere e il server continua a bloccarsi.

Tutto quello che puoi fare è esprimere le tue preoccupazioni. Nella mia esperienza non arriverà nulla di buono spingendo la questione. Lascia che si impicchi ...