Quanto spesso rivaluti e aggiorni il tuo ambiente di sviluppo e sviluppo. utensili?

Question

Ero curioso di sapere con quale frequenza altri sviluppatori di software hanno rivalutato i loro ambienti e strumenti di sviluppo. Lavoravo in una grande azienda con set di strumenti rigidi che tutti odiavano, ma non potevano fare nulla. Quindi nessuno ha mai aggiornato realmente i loro ambienti di sviluppo perché non potevamo farlo in quell'ambiente.

Ora che sono nella mia start-up, trovo che posso passare un tempo infinito a valutare nuovi strumenti e ambienti di sviluppo, ma che non dovrei e non posso permettermi. Mi sono impegnato a passare 1 giorno al mese a guardare i nuovi strumenti di sviluppo e a provarli per vedere se vale la pena passare.

Con quale frequenza si provano nuovi IDE, editor, strumenti di bugging, debugger? O aggiornare a versioni più recenti della tua?

Answer 1

Aggiornamento solo a meno che non mi stia sfuggendo un determinato elemento di funzionalità, o mi rendo conto che NON utilizzare uno strumento invece di un altro porta a più attività che richiedono più tempo/sono meno efficienti.

Answer 2

È un processo in corso, ma non faccio grandi cambiamenti più spesso di ogni due anni circa. Un cambiamento importante comporta troppo tempo e il compromesso in genere non vale la pena. Le principali modifiche potrebbero essere definite come la modifica dell'intero target o architettura del compilatore e toolchain per un progetto esistente.

Si noti che possono verificarsi grandi cambiamenti tra i progetti: un nuovo progetto può stabilirsi su un'architettura e una toolchain completamente diverse senza costi significativi. Ma attenzione dovrebbe essere presa per non andare troppo sanguinante qui. È necessario un processo di valutazione per impedire la selezione di una configurazione che non supporterà il progetto in un secondo momento in quanto il progetto diventa più complesso.

Ma per modifiche minori, semplicemente aggiorno i miei strumenti e l'ambiente quando trovo l'opportunità e la ragione per farlo.

-Adam

Answer 3

Per me, gli aggiornamenti sono event-driven, non timer-driven. Tengo l'orecchio a terra per nuovi strumenti (librerie, IDE, strumenti CASE, ecc.) E li valuto mentre appaiono sul mio radar.

Lavorando con le tecnologie Microsoft, passo alla versione più recente se non ci sono motivi validi per trattenermi. Con l'OSS, uso quello che so a meno che non ci sia qualcosa di avvincente che mi spinga avanti.

Answer 4

Al lavoro, eseguiamo l'aggiornamento di uno strumento quando la nostra versione raggiunge la durata del supporto. Eseguiamo l'aggiornamento alla versione precedente precedente.

A casa, eseguo l'aggiornamento non appena riesco a trovare una copia della nuova versione gratuita (ad esempio, alcune offerte in cui la partecipazione a 3 webcast invierà una copia di vs2008 edizione standard, gruppi di utenti, ecc.).

Answer 5

IDE. Tendo a restare con uno che so crescerà e supporto la mia lingua. Nel mio ambiente di sviluppo è vim. È attivamente sviluppato e ha molti script (tipo plugin) e documentazione per il fai da te. Anche l'inclusione di un IDE richiede tempo, e diventare bravi a farlo, usarlo in modo efficiente richiede più tempo.

Controllo revisione. Cerco di stare appena sotto il bordo sanguinante. I vantaggi delle nuove funzionalità sono importanti. Ad esempio Subversion 1.4, supporta solo l'unione rudimentale. Subversion 1.5 ha revisionato il loro sistema di fusione e ha aggiunto new features.

Gestione attività e progetti. Io tendo a farlo solo ogni due anni, e solo se c'è un buon beneficio percepito. Altrimenti continuerò ad aggiornare il mio attuale sistema all'attuale versione stabile ogni due mesi.

Librerie. Sono un sorso. Poiché la maggior parte di tutto ciò che faccio non finisce in un prodotto spedito. Mi sento più libero di aggiornare spesso, ma tendiamo a rifuggire dall'aggiornamento quando la comparabilità al passato è interrotta.

Spero che il mio $ 0.02 sia stato utile.

Answer 6

IDE: può essere complicato, ma nel corso degli anni ho avuto alcune progressioni diverse. A volte essere su un progetto o una funzione specifica può innescare un aggiornamento. Ad esempio, qualcuno ha implementato una funzionalità utilizzando LINQ, quindi ciò che è stato un progetto ASP.Net 2.0 è diventato un progetto di 3,5 durante la notte. Altre volte, è proprio quello che è attualmente in uso. Un punto qui è che un cambiamento può avere un impatto su tutta la squadra, quindi non è un cambiamento da fare alla leggera.

Strumenti per il tracciamento dei bug - Questo è anche in quella terra di materiale centralizzato che deve essere gestito con attenzione. Dato che si tratta di uno strumento di controllo qualità, mi auguro che abbiano le loro politiche su quanto spesso cercare gli aggiornamenti e quando installarli, perché a volte le nuove funzionalità possono essere interessanti. L'equivalente del team di sviluppo sarebbe quando aggiornare il wiki.

Controllo versione - Questi sono gestiti individualmente poiché la maggior parte di noi utilizza SVN Tortoise in modo che ognuno di noi abbia una copia client locale. Quindi, gli aggiornamenti sono fatti quando qualcuno vuole farlo. Mi piace rimanere aggiornato il più possibile, personalmente.

SO: Mentre una parte di questo può essere controllata su base dipartimentale, ci sono abbastanza pezzi diversi da aggiornare che a volte eseguirò un aggiornamento per conto mio. Non sono sicuro quando passeremo a Windows 7 perché so che non stiamo andando a Vista e penserei che ad un certo punto avremmo perso XP come sono stato su XP ora per circa 5 anni come prima ero su Windows 2000 Professional per alcuni anni e NT 4.0 prima.

PC - C'è una politica che ogni 3 anni riceviamo nuove macchine credo. Quando ho iniziato dove sono ora, ero su una scatola P4, quindi l'aggiornamento a una scatola dual-core è stato molto bello così come una buona spinta RAM da 2 GB a 4 GB.