Come valuto un IDE? [chiuso]

Un IDE dovrebbe aumentare la produttività . Questo dovrebbe essere il tuo criterio.

Qualunque IDE tu abbia voluto provare, scarica e installa prima di tutto. Prova a programmare in ognuno di essi, uno per uno. Oppure provane uno al giorno. Alla fine, sono sicuro che scoprirai da solo quali potrebbero renderti più produttivo.

Ogni IDE ha le proprie impostazioni, scorciatoie da tastiera, comportamenti, ecc. e se continui a usarli regolarmente, ti troverai a loro agio e ti abituerai. Ecco alcuni altri fattori che potresti prendere in considerazione durante la valutazione degli IDE:

1. Se è in sviluppo attivo
2. Se ha un buon supporto per la community (e anche un'ampia adozione)
3. Se ha un numero buono e crescente di plug-in / estensioni
4. Potrebbe non essere pertinente, ma se è gratuito o pagato

Uso eclipse da 3 anni fino a quando il mio collega mi ha chiesto di provare IntelliJ IDEA. Sono stato molto a mio agio con Eclipse per 3 anni. Tuttavia, mi è piaciuto IntelliJ meglio come è stato pubblicizzato, più intelligente. Inoltre, hanno una community edition che è open source e gratuita. Così, sono passato a IntelliJ perché ha migliorato la mia produttività, ma ogni volta che aiuto altri colleghi che usano Eclipse, non avrò problemi con quello.

Personalmente mi trovo a provare ogni IDE che ho incontrato, perché gli IDE hanno molte possibilità di miglioramento e continueranno a essere sempre più intelligenti.

Provale!

Hai detto che sei un utente vim. Supponendo che tu non voglia rinunciare ai tuoi superpoteri, probabilmente vorrai vedere quali IDE hanno migliori modalità vim.

Pensa se vuoi un IDE che funzioni con molte lingue o più che sono fantastici nella lingua in cui sono specializzati.

È solo una questione di opinione.

Ok, sembra più una di quelle domande in cui qualcuno ha bisogno di approfondire e trovare la vera domanda, che in base ai tuoi commenti, sospetto sia:

"Is it okay that I hate IDEs?"

La mia risposta sarebbe "Bravo, sì. L'eccessivo affidamento sugli IDE per gestire troppe cose può renderti debole e perdere il contatto con il valore di un'architettura attentamente progettata che alla fine rende un codice base più mantenibile con o senza la stampella Inoltre, per gli sviluppatori che hanno padroneggiato strumenti meno complessi / più leggeri come VIM, possono fare di più per intralciarti che effettivamente aiutarti. "

Ma non essere troppo soddisfatto. Anche se il tuo codice è pulito e abbastanza accurato da poter essere trattato più facilmente in modo non IDE, ciò non significa che lo è o che il tuo sarà sempre se ti trovi a dover aggiungere continuamente dei livelli a qualcosa che avevi intenzione di refactoring prima ancora di prenderlo, ma oops, ora ci sono soldi e impiegati coinvolti e devi solo essere fatto in tempo per vedere se la gente ottiene i bonus di Natale quest'anno. (disclaimer: no, ho lavorato solo per quel ragazzo)

Ci sono voluti esattamente un codice base legacy dall'Inferno per convincermi che no, gli IDE hanno i loro usi. Questi sono:

• Rendere il illeggibile meno illeggibile - Non è possibile comprendere il codice in un codebase in cui ogni singola classe ha un minimo di 1 interfaccia e una super-classe o una sotto-classe classe semplicemente guardando il codice. Non è così. Almeno aiuta ad avere qualcosa che puoi trovare rapidamente dove inizia e finisce effettivamente.

• Debug dei lupi crap-procedurali nell'abbigliamento ovino di OOP - A volte devi solo rinunciare e rendersi conto che tutta l'architettura OOP è davvero solo una schifezza che offusca ulteriormente quello che sta succedendo. Quando occorrono 30 chiamate di metodo per effettuare una chiamata al servizio web di base per alcuni dati statici in un DB, ti servirà un po 'di aiuto per capire dove è andato male.

• Aiutarti con una lingua che non conosci molto bene : la semplice presenza di auto-completamento e suggerimento param può essere di grande aiuto su questo fronte. Digitare a 70-80WPM quando è intossicato in una tempesta di neve non ti aiuta quando devi Google a modo tuo attraverso la documentazione di Microsoft o J2EE per fare le cose più semplici.

• Gestione della complessità - Devo ammettere. Una volta che il numero effettivo dei file di codice cresce oltre 20 o giù di lì, è davvero bello poter semplicemente fare clic con il pulsante destro del mouse su qualcosa e vedere dove diavolo è stato definito o rinominarlo in 6 diversi file contemporaneamente. Soprattutto quando si lavora con qualcosa non si è scritto il grosso di quando si ha a che fare con un team.

Quindi, se forse sei abbastanza convinto come sono sempre stato che gli IDE sono spesso un sintomo di una malattia, non penso che tu abbia completamente torto. Ma io sono un dev di JavaScript e devo ammettere che WebStorm è abbastanza pulito. Apro ancora Scite il più delle volte, ma una volta che ci sono molte dipendenze da gestire e un codice stupido nel mix, prenderò l'opzione IDE.

Se non sbaglio e tu sei almeno simile a me nella prospettiva storica degli IDE, andrei con le quattro cose in cui le ho trovate utili per le cose per classificare il valore di un IDE.

Non ha molto senso definire i criteri di valutazione. Anche se ne definisci alcuni, dovrai giocare con l'IDE per decidere se li soddisfa, ma poi di nuovo giocando con l'IDE incontrerà comunque cose che ti piacciono o che non ti piacciono, indipendentemente da se hai stabilito criteri o meno.

Il mio algoritmo è: scelgo lo standard defacto per la lingua / SDK che sto usando e aspetto e vedo. Se dovessi incontrare troppi problemi, prenderò in considerazione il passaggio a un IDE promesso (tramite pubblicità o passaparola) per non avere questi problemi specifici.

Come altri hanno menzionato, dato che sei un utente Vim, una cosa facile che puoi fare è esaminare i plugin di emulazione vim disponibili.

Provare è ovvio.

Creerei un elenco di show stoppers: cose che non possono essere vere su un IDE che utilizzo. Alcuni esempi:

• Non funziona su alcune macchine che i miei sviluppatori usano?
• L'azienda sta facendo (o è sostenuta dalla comunità) morta o morente?
• È soggetto a crash? Se si è arrestato in modo anomalo (o bloccato e ucciso), ha problemi ad iniziare?
• Ti fa aspettare a caso?
• Ha riscontrato gravi bug o mancanze nelle aree che mi interessano?

Questo può essere riassunto:

• Ti fa maledire spesso?
• Ti fa passare spesso ad altri strumenti?

Se lo fa, probabilmente non volerà.

Ma non dimenticare di utilizzare impara come utilizzare prima ciascun IDE. Seguire fedelmente testi o video introduttivi, per quanto ovvio possa sembrare il materiale; i tuoi stereotipi potrebbero impedirti di utilizzare un modo eccezionale ma non convenzionale per fare qualcosa.

Come sviluppatore, considero qualsiasi cosa mi aiuti a svolgere il lavoro nel modo più rapido e con la minima frustrazione. Inoltre, uno che è popolare perché so che posso trovare supporto per qualsiasi cosa tramite google se questo è il caso. Come compagno vine tendo a sceglierne uno con plug-in vim (ad esempio, eclipse e visual studio hanno entrambi plug-in vim). Quindi è il meglio di entrambi i mondi:)