it-swarm.it

Dare a uno sviluppatore una macchina di sviluppo più lenta comporta un codice più veloce / più efficiente?

Supponiamo che io dia ai miei sviluppatori una macchina veloce e urlante. VS2010 basato su WPF si carica molto rapidamente. Lo sviluppatore crea quindi un'applicazione WPF o WPF/e che funziona perfettamente sulla sua scatola, ma molto più lentamente nel mondo reale.

Questa domanda ha due parti ...

1) Se do a uno sviluppatore una macchina più lenta, significa che il codice risultante potrebbe essere più veloce o più efficiente?

2) Cosa posso fare per offrire ai miei sviluppatori un'esperienza veloce IDE, offrendo allo stesso tempo esperienze di runtime "tipiche"?

Aggiornamento:

Per la cronaca, sto preparando la mia risposta equilibrata alla direzione. Questa non è una mia idea e voi mi state aiutando a correggere le richieste sbagliate del mio cliente. Grazie per avermi fornito più munizioni e riferimenti su dove e quando affrontarlo. Ho + + casi d'uso validi come:
- ottimizzazioni di programmazione lato server specifiche
- laboratori di prova
- il possibile acquisto di un server migliore anziché delle schede grafiche top di gamma

130

assolutamente

È anche vero che i manager dovrebbero condurre tutti gli incontri in latino-maiale. Migliora le loro capacità comunicative in generale per averle svantaggiate quando parlano frasi semplici. Dovranno fare più affidamento sulle espressioni facciali e sul linguaggio del corpo per ottenere il loro punto di vista e sappiamo tutti che è almeno il 70% di tutte le comunicazioni comunque.

I CFO dovrebbero usare solo un abaco e un gesso. Altrimenti finiscono per fare troppo affidamento sui "dati grezzi" e non abbastanza sulla loro "sensazione viscerale".

E i vicepresidenti e superiori dovrebbero essere tenuti a tenere tutti gli incontri di lavoro importanti in contesti di distrazione come campi da golf mentre sono semi-intossicati. Oh scatto ...

234
Jay Beavers

La risposta è (sarò in grassetto e dirò) sempre

[~ ~ #] non [~ ~ #].

Sviluppa il meglio che puoi ottenere con il tuo budget e testa sulla gamma di specifiche min-max delle attrezzature che implementerai.

Ci sono emulatori, macchine virtuali, macchine reali con tester che possono testare tutte le prestazioni per vedere se è un fattore.

376
Steven Evers

1) Molto, molto improbabile.No, e i tuoi sviluppatori potrebbero mettere qualcosa di brutto nel tuo caffè per suggerirlo. Il tempo che i tuoi sviluppatori impiegano ad attendere la compilazione del codice o il IDE per fare qualunque cosa stia facendo o qualunque sia il tempo che stanno non spese per migliorare il codice. Interrompe anche il loro flusso mentale. Tieni a mente il problema e saranno molto più efficienti a risolverlo.

2) Dai a ciascuno di loro un secondo PC che rappresenti le specifiche più basse che vuoi veramente supportare, con un interruttore KVM per passare tra quello e la loro vera workstation.

70
BlairHippo

Mi piacciono i tempi di compilazione lunghi. Mi dà più tempo per lavorare sul mio curriculum.

43
Wonko the Sane

Questa è un'idea terribile. Vuoi che i tuoi sviluppatori siano il più produttivi possibile, il che significa dare loro una macchina il più veloce possibile, in modo che non siedano tutto il giorno in attesa che le cose vengano compilate. (Leggermente OT, ma aiuta anche a non bloccare il loro accesso a siti potenzialmente utili con WebSense e simili.) Se sei costretto a disporre di utenti che utilizzano ancora la tecnologia Stone-Age, dovrai disporre di una macchina di prova con specifiche simili e assicurati di testare presto e spesso per assicurarti di non seguire la strada sbagliata in termini di scelte tecnologiche.

33
o. nate

Lo sviluppo dovrebbe essere fatto nel miglior ambiente possibile. I test dovrebbero essere eseguiti nel peggior ambiente possibile.

32
Yevgeniy Brikman

Se mi venisse data una macchina lenta passerei la giornata a ottimizzare il processo di sviluppo e non a ottimizzare il mio codice consegnato. Quindi: NO!

27
user6015

I programmatori di sistemi integrati si imbattono sempre in questo! E c'è una soluzione in due parti:

  1. I tuoi requisiti devono specificare le prestazioni X sull'hardware Y.
  2. Prova su hardware Y e, quando non ottieni prestazioni X, bug di file.

Quindi non importa su quale hardware lavorano i tuoi sviluppatori.

Una volta che lo hai fatto, supponiamo che un'attrezzatura più veloce possa far risparmiare ai tuoi programmatori mezz'ora al giorno o 125 ore all'anno. E diciamo che costano $ 100.000 all'anno con benefici e spese generali (ridicolmente bassi per la Silicon Valley), o $ 50 l'ora. Quel 125 ore * $ 50/ora è $ 6250. Quindi, se spendi qualcosa di meno di $ 6250 all'anno in hardware di sviluppo rockin per programmatore, stai risparmiando denaro.

Questo è ciò che dovresti dire alla tua direzione.

Tim Williscroft ha praticamente detto la prima metà di questo in un commento, e in un mondo giusto, otterrebbe la metà di tutti i punti che ottiene questa risposta.


Aggiunto il 24 ottobre:

Il mio ex datore di lavoro aveva questa teoria e li ha aiutati a far incazzare circa $ 100 milioni.

Sono un conglomerato con base giapponese che era abituato ad assumere programmatori in Giappone, Corea e Cina. Le persone sono fantastiche nell'utilizzare hardware di sviluppo scadente, giorni di lavoro di 13 ore, dormire nei loro banchi e non avere una vita. Così hanno pensato quando hanno acquisito una nota azienda della Silicon Valley per fare un sistema operativo basato su Linux per telefoni cellulari, quegli sciocchi californiani che volevano equipaggiamento moderno erano solo lamentosi prima-donnas e in realtà non avevano una buona ragione per farlo (come la produttività).

Quattro anni dopo, il sistema operativo funzionava come una cazzata, tutti i programmi erano saltati e i clienti erano incazzati e avevano concluso i contratti a destra e a sinistra. Infine, il progetto OS è stato annullato e una grande percentuale della forza lavoro mondiale del conglomerato è stata licenziata nell'ultimo anno. E francamente, non avrei voluto essere uno dei dirigenti che ha dovuto spiegare agli azionisti dove sono andati tutti quei soldi e gli sforzi.

Non sono state solo le macchine a sviluppo lento a causare questo fiasco. C'erano molti altri errori strategici e tattici, ma erano lo stesso tipo di cose in cui le persone che lavoravano nelle trincee potevano vedere arrivare il disastro ferroviario e si chiedevano perché i decisori non potevano.

E la marcia lenta è stata sicuramente un fattore. Dopotutto, se sei sotto la pistola per consegnare in tempo, è davvero una cosa intelligente rallentare deliberatamente il lavoro?

26
Bob Murphy

Nella programmazione, c'è un vecchio detto che " l'ottimizzazione prematura è la radice di tutti i mali ". Penso che tu sia riuscito a creare con successo un'altra "radice" (o almeno il primo ramo) di tutti i mali. Da ora in poi, possiamo dire "la deoptimizzazione prematura degli sviluppatori è la radice di tutti i mali".

In breve, la risposta è che ciò rallenterà i tempi di sviluppo e renderà più difficile l'ulteriore manutenzione. I tempi di compilazione richiederanno più tempo, la ricerca di codice su disco rallenterà, la ricerca di risposte online richiederà più tempo e, soprattutto, gli sviluppatori inizieranno a utilizzare il codice in modo prematuro per poter anche testare le funzionalità necessarie.

Quest'ultimo punto è il problema più critico e non viene sollevato in molte delle altre risposte. Potresti ottenere la tua prima versione ok, ma poi quando vuoi aggiornare il codice in futuro, scoprirai che l'ottimizzazione prematura degli sviluppatori ha spostato il focus del tuo codice lontano da un buon design e lo ha avvicinato a "Devo farlo a almeno lavoro per mantenere il mio "stile di codice di lavoro. L'aggiunta di funzionalità aggiuntive diventerà più difficile perché le ottimizzazioni scelte al momento potrebbero non essere necessarie e bloccare il codice in un percorso di hack semi-ottimizzati oltre ad altri hack semi-ottimizzati.

A titolo di esempio, immagina che il requisito di sistema minimo della tua versione attuale sia un singolo processore con una velocità piuttosto bassa. Metti gli sviluppatori in questa scatola e escono con una soluzione intricata a thread singolo che si basa su molti hack perché volevano sviluppare rapidamente il prodotto. Ora 5 anni dopo, hai una nuova versione del prodotto che ha un requisito minimo di una macchina a doppio processore. Vorresti essere in grado di separare in modo chiaro parti del programma che puoi eseguire in parallelo, ma la decisione che hai preso 5 anni fa che ha costretto i tuoi sviluppatori a creare un software hacky ora ti impedisce di sfruttare tutta la potenza del tuo nuovo requisito minimo .

Quello che dovresti fare è aggiungere una fase alla fine del tuo ciclo di sviluppo in cui esegui i test di accettazione nelle caselle con limite inferiore. Certamente parte del codice sarà troppo lento a causa della macchina più veloce dello sviluppatore, ma puoi isolare quella parte e ottimizzarla lì. Il resto del codice rimane pulito e gestibile.

Vedo la tua domanda dire: "Posso forzare i miei sviluppatori a ottimizzare in anticipo dando loro macchine sviluppatrici povere ma ancora ottenere un buon codice?" E la risposta è no.

20
EntropyFails

Lettura interessante, tutte quelle risposte.

Ma penso che alla maggior parte delle persone che rispondono qui manchi il punto. La domanda, come ho letto, non riguarda (almeno almeno) il fatto di dare agli sviluppatori un P1 per rendere il codice più veloce.

Il punto è che molti software oggi sono altrettanto lenti o persino più lenti del software di base che abbiamo usato nell'ultimo millennio, nonostante i computer molto più potenti. A giudicare dalle risposte qui la maggior parte degli sviluppatori non ha quel suggerimento. Questo è molto evidente nelle applicazioni web. Questo sito fa un'ottima eccezione, ma molti siti hanno una prima pagina in 1 mb. Cosa ottengo in attesa del download? Non lo so. Penso che si tratti di un'ignoranza da parte dello sviluppatore che non rispetta il tempo che l'utente ha bisogno di spendere per esso, o peggio ancora se paghi per mb. Il fatto è che tutte quelle pagine web non contengono nemmeno immagini ad alta risoluzione. Spesso è solo un po 'di codice di merda fornito da un ambiente di sviluppo. Beh, ovviamente non è un codice di merda, immagino, ma non mi dà alcun vantaggio come utente.

In generale non si tratta solo di ottimizzare il codice, ma anche di scegliere di non includere le cose che rallentano più di quanto non dia.

Alcune settimane fa ho avviato un laptop dal 1995. Windows 3.x era attivo e funzionante in pochissimo tempo. Il database dovrei ottenere alcuni dati da avviare prima che la chiave di invio fosse completamente rilasciata (almeno).

So che oggi otteniamo molto di più dal nostro software, ma abbiamo anche computer molte volte più veloci. Perché l'industria dello sviluppo non decide di mantenere la velocità del software dal 1995 e indurre le persone ad acquistare nuovo hardware perché desiderano nuove funzionalità. Oggi è più come i programmi di tutti i giorni e i siti Web costringono le persone ad acquistare nuovo hardware per fare esattamente le stesse cose di prima. Ma ovviamente in modo più elaborato.

Devo dire che penso che lo sviluppo di Linux sembra gestirlo meglio. Le distribuzioni Linux sono state per molti anni molto più avanti di Windows anche nella fantasia con molte cose accattivanti come le finestre animate. Il fatto è che, nonostante ciò, hanno funzionato sui computer di oggi e anche di ieri. Non solo su hardware Edge all'avanguardia.

Ormai suppongo che molti sviluppatori abbiano un livello malsano di adrenalina. Sì, ho trovato un modo per restituire un po 'di frustrazione da tutte le attese di fronte a:
office sql server (avvio console di gestione) arcgis (avvio e utilizzo) acrobat reader (avvio) agresso (utilizzo, almeno come applicazione web) windows (avvio e utilizzo, beh, non ho provato 7 ancora) pagine web .net (download)

e così via

Mi sento bene :-)

Saluti
Nicklas

15
Nicklas Avén

1) Se do a uno sviluppatore una macchina più lenta, significa che il codice risultante potrebbe essere più veloce o più efficiente?

Abbiamo creato software negli ultimi 6 decenni e abbiamo ancora domande come queste? Sembra più un ennesimo tentativo di tagliare gli angoli. Senza offesa, ma dai, pensi che la domanda sia persino logica? Pensaci in questi termini (se puoi): vuoi costruire un veicolo 4x4 che possa operare in condizioni difficili, pioggia, fango, qualunque cosa. Metterai i tuoi ingegneri e la catena di montaggio sotto gli elementi solo per assicurarti che il veicolo risultante possa operare su di essi?

Voglio dire, Gesù Cristo! C'è sviluppo e test. I test vengono eseguiti in un ambiente diverso e più difficile, oppure lo sviluppatore sa come assemblare un banco di prova nel proprio ambiente di sviluppo in un modo adatto per le prove di stress. Se non ci riesce, sostituiscilo con uno sviluppatore migliore.

2) Cosa posso fare per offrire ai miei sviluppatori un'esperienza veloce IDE, offrendo allo stesso tempo esperienze di runtime "tipiche"?

Dovresti chiedere questo ai tuoi sviluppatori. E se non possono darti una risposta obiettiva e valida, devi sostituirli con sviluppatori reali.

Ma per intrattenere la domanda, dai ai tuoi sviluppatori (supponendo che tu abbia buoni sviluppatori), buoni strumenti e buon hardware, il meglio che puoi permetterti. Quindi imposta un ambiente di base comune più basso in cui il tuo software deve operare. Ecco dove dovrebbe avvenire il test. È molto meglio la pratica ingegneristica avere un ambiente di test che è distinto dall'ambiente di sviluppo (preferibilmente uno che ti consente di fare stress test.)

Se i tuoi sviluppatori sono bravi, dovrebbero averti comunicato questo (supponendo che tu l'abbia chiesto).

10
luis.espinal

Il risultato è un sacco di sviluppatori puttanati. Questa roba è abbastanza dura com'è, non peggioriamo l'esperienza.

Ti incoraggio a disporre di hardware simile ai tuoi utenti in un ambiente di prova o di controllo qualità per eliminare eventuali problemi di prestazioni. Questa è una buona idea.

6
bigtang

Rispetterò la norma e dirò di sì SE E SOLO se stanno scrivendo un software server. Ridi tutto ciò che vuoi, ma il team più efficiente che abbia mai visto era un gruppo di ragazzi del Perl con terminali Wyse. Era la fine degli anni '90, era un negozio off-shoot dell'Università e stavano scrivendo un software di griglia spaziale (che sostanzialmente calcola). Stavano comunque parlando con alcuni relativamente potenti RS/6000 del modello recente.

Solo per aggiungere interesse all'evento, c'era un programmatore cieco lì. Sono rimasto molto colpito.

alt text

6
Jé Queue

Questa non è una cattiva idea, ma vuoi che i tuoi sviluppatori abbiano un ambiente di programmazione veloce.

Potresti implementarlo dando ai tuoi programmatori due macchine: una scatola di sviluppo veloce e una scatola di merci più lenta (possibilmente virtuale) per i test.

Alcune modifiche al processo di compilazione di VS potrebbero rendere la distribuzione nella casella di test la norma, con il debug remoto.

Esistono altri modi per considerare di forzare i programmatori a sviluppare codice più efficiente: ad esempio, è possibile includere obiettivi di prestazioni e utilizzo della memoria nei test delle unità. Anche impostare budget per l'uso della memoria è un obiettivo eccellente. Anche l'impostazione dei budget di peso pagina per il codice html.

5
damien

Il problema non è lo sviluppatore che sviluppa codice inefficiente su una macchina veloce, il problema è che non hai definito le metriche delle prestazioni che devono essere misurate.

È necessario definire, nell'ambito dei requisiti del prodotto, un obiettivo specifico che può essere misurato su tutti i computer sulla base dell'esperienza del cliente richiesta. Esistono molti siti Web (Verifica specifiche) che consentono di mettere in relazione il computer con altri tipi di computer.

Questo è buono per molte ragioni. Ti consente di definire più facilmente l'hardware minimo supportato in modo da poter limitare il numero di reclami dei clienti - sappiamo tutti che la maggior parte dei software viene eseguita sulla maggior parte dei computer, è solo una questione di prestazioni - se impostiamo le nostre specifiche in modo che le persone rientrino nella gamma dei requisiti minimi ha prestazioni ragionevolmente accettabili, si limitano i reclami dei clienti - e quindi quando un cliente chiama, è possibile utilizzare i parametri di riferimento per determinare se esiste davvero un problema o se il cliente non è soddisfatto del funzionamento del prodotto.

5
Mike Glasspool

Sono convinto che avere un computer più lento per lo sviluppo si traduca in un codice più veloce, ma questo ha un prezzo. La logica è che ho sperimentato questa prima mano: avendo un lungo tragitto giornaliero, ho comprato un netbook per lavorare in treno, un netbook che è più lento di qualsiasi computer che ho comprato negli ultimi 5 anni. Poiché tutto è così lento, vedo molto rapidamente quando qualcosa è insopportabilmente lento su questo netbook e sono consapevole dei punti lenti molto più rapidamente (non c'è bisogno di fare un benchmark per tutto il tempo). Lavorare su un netbook ha davvero cambiato il modo in cui mi sono sviluppato.

Detto questo, non sto sostenendo di farlo, specialmente in un ambiente professionale. Innanzitutto, è demoralizzante. Il fatto stesso che quasi tutti abbiano affermato che l'idea non ha nemmeno senso ha dimostrato che i programmatori reagiscono male all'idea.

In secondo luogo, avere tutto più lentamente significa che le cose che potresti voler fare su una macchina veloce (diciamo 1 minuto) non sono più realmente realizzabili su una macchina lenta, a causa della pigrizia, ecc ... È una questione di incentivo.

Infine: il codice prodotto potrebbe essere più veloce, ma quasi sicuramente impiegherà più tempo a produrlo.

5
David Cournapeau

Punto 1, NO! Studio è progettato per essere eseguito su macchine decenti e tale requisito è diventato solo più potente con ogni versione. Puoi effettivamente bloccare alcune versioni di studio se accendi intellisense e usi un box single core non HT.

Al punto 2 ci sono alcune funzionalità nei progetti di test che consentono di limitare alcune risorse. Non sono perfetti, ma ci sono. VPC o low spec VM immagini per un buon lavoro di essere anche vincolate. Ho avuto utenti seduti a macchine cattive per fare test occasionalmente in modo che possano vedere le implicazioni delle funzionalità che ho richiesto.

4
Bill

No, in effetti si tradurrebbe in più bug perché non eseguiranno così tanti test e non useranno più strumenti extra come i profiler. Fornisci loro le migliori macchine che puoi permetterti (incluso l'hardware di accelerazione grafica se sei uno sviluppo di giochi o un negozio di grafica) e falli testare all'interno delle VM. Le specifiche VM possono essere ridimensionate in base alle esigenze.

4
JohnL

Penso che questa sia una domanda interessante e non vorrei fare un "no" così rapidamente. La mia opinione è: dipende dal tipo di team di sviluppo di cui stiamo parlando. Esempio: se stai guidando un gruppo in esecuzione per il concorso annuale di programmazione ICFP, forse avere buoni risultati dopo una piccola quantità di tempo di sviluppo su un cluster HPC non significherebbe necessariamente che la soluzione che hai trovato è buona. Lo stesso si può dire se stai scrivendo un algoritmo scientifico o numerico: sul tuo vecchio AMD Duron 600 MHz con 64 MB di memoria sei costretto a stare attento al modo in cui stai facendo le cose, e questo può influire anche su alcuni progetti scelte.

D'altra parte, un programmatore/scienziato intelligente/qualunque cosa dovrebbe fare attenzione comunque. Ma mi sono ritrovato a scrivere alcuni dei miei migliori codici quando NON avevo un computer AT ALL e dovevo prendere appunti su carta. Ciò potrebbe non valere per i grandi progetti che coinvolgono enormi framework, quando un IDE è strettamente necessario.

Una cosa è certa: macchine veloci e buoni risultati immediati rendono i programmatori (cattivi) viziati e possono essere uno dei motivi di alcune cazzate che troviamo sui computer.

4
Lorenzo Stella

Lavoro su un pacchetto che impiega circa un'ora per costruire sulla mia macchina 8G 8 core (build completamente pulita). Ho anche un laptop relativamente di fascia bassa su cui collaudo. Il laptop di fascia bassa non gestisce due build complete in una singola giornata lavorativa.

Sono più produttivo sulla macchina veloce con alcuni test deliberati eseguiti sul laptop o dovrei fare tutte le mie build sul laptop?

Tieni presente che questi non sono numeri inventati.

È una demo truccata in cui normalmente non ho bisogno di fare una build pulita ogni giorno (posso fare molti test su singoli moduli), ma anche le build parziali mostrano all'incirca un ordine di differenza di grandezza nei tempi di compilazione/collegamento .

Quindi il vero problema è che sulla mia macchina più lenta una tipica costruzione è abbastanza lunga per farmi prendere una tazza di caffè, mentre sulla mia macchina più veloce posso solo sorseggiare un caffè.

Dal punto di vista del lavoro svolto preferisco fare lo sviluppo su una macchina veloce. Posso raggiungere scadenze molto più affidabili. D'altra parte, immagino che se la gestione mi facesse fare lo sviluppo sulla mia macchina lenta, farei molto più navigazione sul web, o almeno leggendo i libri.

4
Stripes

È interessante notare che ho lavorato in una startup in cui abbiamo finito per farlo. Penso che in realtà abbia funzionato abbastanza bene, ma solo a causa della situazione specifica in cui ci trovavamo. Era un negozio mod_Perl in cui il ricaricamento automatico della classe funzionava correttamente. Tutti gli sviluppatori hanno utilizzato vim come IDE di scelta (o hanno utilizzato alcuni software di editing remoto). Il risultato finale è stato che è stato perso pochissimo tempo (se presente) in attesa della compilazione del codice/ricarica/eccetera.

Fondamentalmente, mi piace l'idea IFF che ha un impatto trascurabile sul ciclo di sviluppo per tutti gli sviluppatori e influisce solo sul funzionamento del runtime del codice. Se il tuo codice è comunque compilato, preelaborato, ecc., Allora stai aggiungendo tempo al ciclo "fix bug; test; next" in cui gli sviluppatori stanno lavorando.

Dal punto di vista interpersonale, le persone non erano mai obbligate a usare i server lenti, ma se si utilizzavano i server lenti, non era necessario eseguire alcuna manutenzione o configurazione. Inoltre, questa configurazione esisteva fin dall'inizio, non riesco a immaginare di provare a venderlo a un team di sviluppo affermato.

Dopo aver riletto la tua domanda originale, mi viene in mente che una cosa che mi terrorizza perpetuamente sono gli ambienti di sviluppo che differiscono dagli ambienti di produzione. Perché non usare un VM per l'esecuzione del codice che puoi paralizzare per il runtime senza influenzare la workstation dev? Ultimamente, sto usando/amando VirtualBox.

3
user6041

Ho intenzione di invertire anche la tendenza qui.

Aneddoto: ho lavorato per una società di sviluppo software olandese che ha aggiornato 286 computer a 486 es (sì, sono così vecchio). Nel giro di poche settimane le prestazioni di tutte le nostre librerie interne sono diminuite del 50% e i bug sono aumentati ... Una piccola ricerca ha dimostrato che le persone non hanno più pensato al codice stesso durante il processo di debug, ma hanno fatto ricorso a un codice successivo "rapido" -> compila -> test -> correggi (codice) ecc. cicli.

Correlati: quando ho avviato una filiale per la stessa società negli Stati Uniti, ho finito per assumere programmatori russi perché erano abituati a PC con meno funzionalità/meno potenza ed erano programmatori molto più efficienti.

Mi rendo conto che questi erano tempi diversi e che le risorse erano molto più scarse di quanto lo siano oggi, ma non smette mai di stupirmi di come, con tutti i progressi fatti sul fronte hardware, il risultato netto sembra essere che ogni passo avanti è negato dalla programmazione più sciatta che richiede specifiche minime più elevate ...

Quindi ... Sento che i programmatori dovrebbero essere costretti a testare le loro applicazioni su macchine che non superano la potenza di calcolo di "Joe medio" e le specifiche hardware.

3
John SMythe

L'hardware è meno costoso del tempo di sviluppo.

La maggior parte dei colli di bottiglia si trova nel database non nel PC client, ma ciò non scusa il test su macchine più lente rispetto allo sviluppatore. Utilizzare strumenti di test per testare l'ottimizzazione.

3
Brian

Assolutamente no. Offri ai tuoi programmatori il miglior laptop che il denaro possa comprare, una tastiera a loro scelta, più grandi schermi di grandi dimensioni, un ufficio privato, niente telefono, bevande analcoliche gratuite, tutti i libri che vogliono (che sono pertinenti), viaggi annuali a conferenze tecnologiche chiave e otterrai grandi risultati. Quindi testare le combinazioni hardware/software/browser/larghezza di banda limite superiore e inferiore.

3
addictedtoswdev

Per molte applicazioni il problema sta spingendo gli sviluppatori a testare con set di dati del mondo reale prima che vengano "completati". Per le applicazioni interattive, sarebbe necessaria una macchina/VM di prova di base.

2
user6043

Lavoro su una macchina Windows95 lenta e mi consente di scrivere in modo efficiente l'intelligenza artificiale MindForth in Forth e in JavaScript.

2
Mentifex

Questo è un pensiero interessante (dare agli sviluppatori una macchina lenta può portarli a ottimizzare di più).

Tuttavia, la soluzione è strutturata in modo migliore: inserisci i tempi di risposta nei requisiti per i programmi e disponi di una macchina di fascia bassa disponibile per i test.

Inoltre, se disponi di un compilatore/linguaggio veramente sfrenato, potrebbe essere in grado di escogitare diversi modi per generare codice e scegliere quello migliore. Ciò sarebbe aiutato solo da un computer più veloce.

2
Paul Nathan

Altri hanno risposto che in genere vuoi che gli sviluppatori abbiano macchine veloci. Sono d'accordo. Non saltare RAM - vuoi più memoria che puoi - alcuni processi di compilazione sono molto pesanti sull'uso del disco.

Le cose che potresti prendere in considerazione per sbarazzarti sono l'antivirus sulle unità di build! Questo rallenta solo e può essere un fattore di rallentamento estremamente forte.

Potresti voler lasciare che gli sviluppi si sviluppino su Linux, se possibile. Gli strumenti sono molto migliori per tutti i tipi di attività extra (basta grep per qualcosa in un file, ecc.). Questo elimina anche l'antivirus.

2
user1249

Chiedere ai programmatori se i programmatori dovrebbero ottenere un buon hardware è come chiedere a un uomo grasso se gli piace il cibo. So che questo è lo scambio soggettivo, ma comunque ... vale la pena farci una domanda? : P

Detto questo, ovviamente sono d'accordo con la maggioranza: NO .

2
Matthew Read

Sono tentato di dire "No" in modo categorico, ma vorrei condividere un'esperienza recente: qualcuno del nostro progetto stava lavorando su un codice per importare i dati nel database. All'epoca aveva il PC più vecchio del nostro gruppo, forse persino l'intera organizzazione. Funzionava bene con VS 2008, ma ovviamente una macchina più veloce avrebbe migliorato l'esperienza. Ad ogni modo, ad un certo punto il processo che stava scrivendo è stato bombardato durante i test (e questo prima che fosse completamente descritto). Ha esaurito la memoria. Il processo ha anche impiegato diverse ore per essere eseguito prima di essere bombardato. Tieni presente, per quanto ne sapevamo, questo è ciò che gli utenti avrebbero dovuto usare.

Ha chiesto più RAM. Si rifiutarono, dato che avrebbe ricevuto una nuova macchina in 3-4 settimane e quella vecchia sarebbe stata scartata.

Tieni presente che la filosofia di questo ragazzo sull'ottimizzazione è: "Abbiamo macchine veloci con molta RAM" (le sue e alcune macchine escluse, comunque), quindi perché perdere tempo prezioso per il programmatore? Ma la situazione lo ha costretto a cambiare l'algoritmo per renderlo più efficiente in termini di memoria in modo che potesse funzionare sulla sua macchina da 2 GB (con XP). Un effetto collaterale della riscrittura è che il processo ha funzionato anche molto, molto più velocemente di prima . Anche la versione originale alla fine sarebbe stata bombardata anche con 4 GB quando venivano importati più dati: era un porco di memoria, chiaro e semplice.

Soooo ... Anche se in genere direi "No", questo è un caso in cui lo sviluppatore che ha una macchina meno potente ha portato a un modulo ottimizzato meglio e gli utenti ne trarranno beneficio di conseguenza (poiché non è un processo che deve eseguito molto spesso, inizialmente non aveva intenzione di ottimizzarlo in entrambi i modi, quindi sarebbero rimasti bloccati con la versione originale se la macchina avesse avuto abbastanza RAM per eseguire alcuni test di grandi dimensioni .. .) Posso capire il suo punto, ma personalmente non mi piace l'idea che gli utenti debbano attendere 8 ore per completare un processo, quando può essere eseguito in una frazione di quel tempo.

Detto questo, come regola generale i programmatori dovrebbero avere macchine potenti perché la maggior parte dello sviluppo è piuttosto intensa. Tuttavia, è necessario prestare molta attenzione per garantire che i test vengano eseguiti su macchine con il "minimo comune denominatore" per assicurarsi che il processo non bombardi e che gli utenti non guardino Paint asciutto tutto il giorno. Ma questo è già stato detto. :)

2
MetalMikester

Nel leggere la domanda e le risposte, sono un po 'sbalordito dalla veemenza del caso NO.

Ho lavorato nello sviluppo di software per 25 anni e posso dire senza esitazione che i programmatori hanno bisogno di un sacco di cose per sviluppare un buon codice:

  • Un ambiente di sviluppo RAGIONABILE. Non un dinosauro. Né deve sanguinare Edge. Abbastanza buono da non essere frustrante.

  • Una buona specifica (quanto viene fatto senza specifiche scritte?)

  • Gestione buona e solidale.

  • Un programma di sviluppo ragionevole.

  • Una buona conoscenza degli utenti E DELL'AMBIENTE che gli utenti avranno.

Inoltre, su quest'ultimo punto, gli sviluppatori devono essere nella mentalità di ciò che gli utenti useranno. Se gli utenti dispongono di supercomputer e eseguono simulazioni di divisione dell'atomo o qualcosa in cui le prestazioni costano un sacco di soldi e i calcoli vengono eseguiti per molte ore, quindi pensare che le prestazioni contino.

Se gli utenti hanno 286 laptop alimentati a Steam, lo sviluppo e la messa a punto da parte degli sviluppatori del loro test di sviluppo sugli ultimi 47 GHz Core i9000 comporteranno alcuni problemi.

Coloro che dicono "dai agli sviluppatori il meglio e provalo" hanno in parte ragione, ma questo ha un grosso problema MENTALE per gli sviluppatori. Non apprezzano l'esperienza dell'utente fino a quando non è troppo tardi, quando i test falliscono.

Quando i test falliscono - le architetture si sono impegnate a, la direzione ha fatto promesse, molti soldi sono stati spesi e poi si è trasformato in un disastro.

Gli sviluppatori hanno bisogno di pensare, comprendere ed essere nella zona dell'esperienza utente dal primo giorno.

Coloro che piangono "oh no non funziona così" stanno esprimendo il loro discorso. L'ho visto succedere molte volte. La risposta abituale degli sviluppatori è quella di "dire ai CLIENTI di acquistare un computer migliore", che incolpa effettivamente il cliente. Non buono abbastanza.

Quindi questo significa che hai diversi problemi:

  • Mantenere gli sviluppatori felici e pisciare della direzione, aumentare le possibilità di fallimento del progetto.

  • Usa macchine più lente per lo sviluppo, con il rischio di sconvolgere gli sviluppatori, ma mantenendoli concentrati su ciò che conta davvero.

  • Metti 2 macchine sulla scrivania degli sviluppatori e costringili a testare sul CLUNKER (cosa che non faranno perché è sotto disprezzo .... ma almeno è molto chiaro quindi se ci sono problemi di prestazioni nel test).

Ricordi i sistemi batch e le schede perforate? La gente ha aspettato un'ora o un giorno per l'inversione di tendenza. Roba fatta.

Ricordi i vecchi sistemi unix con processori a 5 MHz? Le cose sono state fatte.

I fanatici della tecnologia adorano inseguire Edge sanguinante. Questo incoraggia a armeggiare, non a pensare. Qualcosa su cui ho discusso con più sviluppatori Juniour nel corso degli anni ... quando li esorto a staccare le dita dalla tastiera e passare più tempo a leggere il codice e pensare.

Nello sviluppo del codice, non c'è sostituto per pensare.

In questo caso, la mia sensazione è: capire COSA REALMENTE. Successo del progetto? Si tratta di un'azienda che fa esercizio/uccide? Se lo è, non puoi permetterti di fallire. Non puoi permetterti di spendere soldi per cose che falliscono nei test. Poiché il test è troppo tardi nel ciclo di sviluppo, gli impatti del fallimento sono rilevati troppo tardi.

[Un bug trovato nel test costa circa 10 volte tanto da risolvere come un bug trovato da uno sviluppatore durante lo sviluppo.

E un bug trovato nel test costa circa 100 volte tanto da risolvere quanto quel bug che è stato progettato durante la fase di progettazione architettonica.]

Se questo non è un rompicapo e hai tempo e denaro da bruciare, usa l'ambiente di sviluppo Edge di livello sanguinante e subisci l'inferno dei fallimenti dei test. Altrimenti, trova un altro modo. Parte inferiore h/w, o 2 macchine su ogni scrivania.

2
quickly_now

Il mio Macbook Pro al lavoro ha qualche anno. Tra Linux e Windows (per testare IE stranezze) vms così come un paio di browser Web e terminali aperti, la ruota che gira OSX si presenta molto. Indovina cosa faccio quando gira, mi siedo e aspetta. In questo caso, una macchina lenta rallenta la produttività.

2
Thierry Lam

Dico che gli sviluppatori hanno bisogno del miglior sistema di sviluppo disponibile, ma ciò non significa necessariamente il più veloce. Può anche significare un sistema moderno ma relativamente lento con raffreddamento completamente passivo, per ridurre al minimo il rumore, ad esempio.

Una cosa: un sistema di sviluppo dovrebbe essere ragionevolmente nuovo e dovrebbe assolutamente avere più core.

Un vecchio PC può sembrare attraente in un primo modo di problemi di prestazioni, ma un Pentium 4, ad esempio, potrebbe effettivamente essere più veloce (per core) di alcuni chip attuali. Ciò significa che limitando uno sviluppatore all'utilizzo di un sistema P4 (in realtà quello che sto usando ora - anche se questo è il mio problema di budget personale) ...

  1. Incoraggia lo sviluppo di software non simultaneo che non trarrà vantaggio dagli attuali sistemi multi-core tradizionali.
  2. Anche se viene sviluppato un software multi-thread, i bug potrebbero non essere rilevati (o almeno non essere notati in anticipo) perché i problemi relativi alla concorrenza potrebbero non apparire nei test su un sistema single-core.
  3. Il software multi-thread può causare seri problemi di prestazioni che possono peggiorare notevolmente con i processori multi-core. Uno potrebbe causare il blocco della testina del disco (che può comportare un accesso ai dati molte volte più lento) in cui i singoli thread stanno eseguendo l'accesso sequenziale, ma ciascuno in una parte diversa del disco. Questo può persino andare via sui vecchi PC più lenti, ad es. avendo due vecchie unità da 160 GB invece di un'unità da 1 TB, quei thread potrebbero non essere più in conflitto tra loro per l'accesso allo stesso disco.

Esistono anche problemi con i PC che sono troppo limitati per supportare bene le macchine virtuali, ad es. per i test su più piattaforme.

1
Steve314

La risposta sta nel mezzo.

Avere una scatola veloce per eseguire l'ambiente di sviluppo (ad esempio Eclipse)

E un'altra casella lenta per testare l'output. Ciò è particolarmente importante per le app Web.

Schermi affiancati, uno per ogni scatola.

Se il codice è accettabile nella casella di output, sarà più che accettabile per la maggior parte degli utenti.

Le caselle di sviluppo veloci rendono i programmatori pigri. Ad esempio, cercare un elemento nel DOM ogni volta che è necessario. Trovalo una volta e memorizza nella cache il risultato.

Noterai davvero la differenza su una scatola lenta in esecuzione IE 6 ....

1
David Semeria

Questa teoria è semplice e obsoleta. Era vero ai giorni nostri.

Ricordo di aver trascorso più tempo a microottimizzare le mie cose Turbo Pascal sul mio computer pre-Pentium. Aveva senso prima di Y2K, tanto meno da allora. Al giorno d'oggi non ottimizzi per hardware di 10 anni. È sufficiente testare il software per trovare i colli di bottiglia. Ma dato che tutti qui agiscono, questo non significa che gli sviluppatori (e quindi l'ottimizzazione) siano produttivi correlati a fornire loro hardware obsoleto per lo sviluppo.

1
mario

1) Se do a uno sviluppatore una macchina più lenta, significa che il codice risultante potrebbe essere più veloce o più efficiente?

No. I buoni sviluppatori sono viziati. Se vedono che ottengono strumenti dannosi nella tua azienda, andranno a lavorare altrove. (I bravi sviluppatori di solito hanno la scelta di andare altrove)

1

La risposta a questa domanda non è un "NO" clamoroso indipendente da chiunque tu chieda?

Chiedi ai tuoi artisti grafici se dovrebbero ricevere una macchina più lenta.

Chiedi ai tuoi scrittori se sceglierebbero una macchina più lenta rispetto a una più veloce.

Chiedi ai tuoi assistenti amministrativi se preferirebbero una macchina più lenta o più veloce.

Tutti diranno che saranno più produttivi con una macchina più veloce.

1
Barry Brown

Posso solo immaginare l'esperienza del profilo mentre utilizzo una macchina lenta. Yikes.

In breve. Diavolo, no.

Hanno anche almeno 4 GB di RAM in modo da poter avere 2 GB sul computer principale, 1 per a VM e l'altro 1 per la memoria aggiuntiva di VM necessita e per te avere un margine di memoria.

Inoltre, due processori sono indispensabili, quindi se un'app blocca/consuma CPU lo sviluppatore non deve dolorosamente passare a ctrl-alt-del qualcosa.

0
user2528

Andiamo contro il flusso qui: SÌ. O almeno questa è stata la saggezza generale del settore per decenni (tranne ovviamente tra gli sviluppatori, che si arrabbiano sempre quando non vengono trattati come dei re e ottengono i gadget e i computer più recenti).

Ovviamente c'è un punto in cui ridurre la macchina dello sviluppatore sarà dannoso per le sue prestazioni di lavoro, poiché diventa troppo lento per eseguire le applicazioni che deve eseguire per svolgere il suo lavoro. Ma quel punto è molto lontano da un computer da $ 10000 + con 6 GB di RAM, 2 videocamere da 4 GB, una scheda audio di fascia alta, 4 schermi, ecc. Ecc.

Non ho mai avuto una macchina di fascia alta, e non mi ha mai rallentato considerevolmente finché è stato decente (e le poche macchine sub-standard sono state rapidamente sostituite quando ho mostrato come mi hanno rallentato).

0
jwenting

La velocità di runtime sulla macchina dello sviluppatore è così irrilevante, a meno che tu non voglia vendicare o punire lo sviluppatore per aver scritto codice lento e per ignoranza dell'ambiente di distribuzione di destinazione.

Come manager, dovresti assicurarti che gli sviluppatori conoscano l'obiettivo del progetto e assicurarti sempre che siano sulla buona strada. A proposito del problema relativo alla macchina target di cui stiamo discutendo, potrebbe essere prevenuto test precoci e frequenti su macchine lente, non dando loro macchine lente da usare e soffrire.

La bassa velocità di runtime rallenta anche lo sviluppo, poiché la maggior parte dei programmatori utilizza il metodo di codice e test. Se il tempo di esecuzione è lento, anche il loro compito sarà lento.

0
tia