Migliorare la velocità di scrittura del codice in C #

4

Ridi se vuoi, ma sviluppavo solide applicazioni line-of-business in VB6, molto prima che arrivasse il framework .NET. Perché, quando avevo la tua età, camminavamo per due chilometri sulla neve, in salita. Entrambi i modi ...

Lo ami o lo odi, VB6 aveva una sensazione REPL -like, e uno sviluppo molto rapido ciclo. Mi piacerebbe sapere come avvicinarmi a quel processo in C #. In VB6, potrei scrivere una funzione, eseguirla, eseguirne il debug e renderla pienamente funzionante in pochi minuti. Mi è stato detto che è così che funziona la folla Lisp. È uno stile di programmazione molto rapido.

In C # scrivo una funzione, quindi scrivo un unit test per quella funzione (che è OK, ne capisco il valore), poi faccio clic con il pulsante destro del mouse, eseguo test, attendo che il progetto compili (richiede circa 10 secondi in questo momento, che sarebbe un'eternità per un loop REPL), e ottenere un'eccezione. Onestamente, questo mi sembra più simile ai miei giorni da junior college, quando davo da mangiare a schede perforate in una tramoggia e aspettavo una stampa (esagerando solo leggermente per effetto).

Inoltre, la mia tendenza al giorno d'oggi è di rendere tutto public mentre lo sto testando. Il test delle unità con accessors privati funziona correttamente, ma non è possibile rintracciare il codice (a meno che, naturalmente, non stia facendo qualcosa di sbagliato) mentre lo si sta utilizzando.

Quindi quello che mi piacerebbe sapere è, quali modifiche hai apportato al tuo processo di sviluppo in C # per semplificarlo e rendere possibile scrivere e verificare il tuo codice molto rapidamente?

    
posta Robert Harvey 01.07.2011 - 18:05
fonte

2 risposte

2

Linqpad ora ha tre diverse modalità per C #:

  1. Espressione C # (l'originale)
  2. C # Statement (s)
  3. Programma C #

Sebbene non sia un ambiente REPL "reale", si avvicina molto, e personalmente non ho mai dovuto affrontare un problema troppo complicato per Linqpad, ma non abbastanza complicato da giustificare un corretto design e test delle unità. Nella modalità "programma" è possibile dichiarare i tipi e in tutte le modalità è possibile aggiungere riferimenti esterni allo spazio dei nomi e all'assembly.

Nel corso del tempo ho semplicemente adottato questo come metodo predefinito per le idee spitballing, assicurandomi che il codice faccia quello che penso che faccia (invece di fare ciò che è supposto fare, che è il dominio dei test automatici).

Se ciò non funziona per te, il progetto Mono ha CSharpRepl . È necessario installare effettivamente Mono, e ci sono alcuni capricci da affrontare, ma le persone lo hanno fatto .

(PS Non è necessario rendere pubblici tipi o membri per testarli unitamente. Una soluzione migliore, che non richiede di ricordare di "aggiustarlo in seguito", è di renderli internal e utilizzare l'attributo assembly:InternalsVisibleTo con il nome dell'assembly test dell'unità. Visual Studio è a conoscenza di questo attributo in modo da ottenere pieno Intellisense e tutto. E si può sicuramente tracciare l'esecuzione.)

    
risposta data 01.07.2011 - 18:16
fonte
2

Non è un confronto equo per confrontare VB senza test unitari con C # con test unitari. Se vuoi un rapido turnaround non scrivere test unitari. Personalmente penso che siano sopravvalutati, specialmente per problemi di business.

L'altra opzione che potresti prendere in considerazione è quella di avere un server CI che esegue test lì, quindi non sono nel tuo ciclo di sviluppo.

Infine mi piace rendere pubbliche anche le variabili. Soprattutto se l'alternativa è solo per scrivere le funzioni get / set di boilerplate. Un aspetto positivo di C # è che puoi modificare in un secondo momento senza influire sul codice che utilizza la proprietà.

    
risposta data 01.07.2011 - 21:11
fonte

Leggi altre domande sui tag