Qual è la cosa più importante, utile o illuminante che hai appreso negli ultimi 12 mesi? [chiuso]

Ho appreso che basta un solo manager corrotto per rovinare l'intero progetto, ma in seguito ci vogliono molti buoni programmatori per ripulire il caos.

Dopo aver appreso alcuni Clojure , ho iniziato a rendermi conto dell'utilità della programmazione funzionale e il mio stile di codifica Java ha stato pesantemente influenzato da questo. Contrariamente alla credenza popolare, una programmazione funzionale lingua non è un prerequisito assoluto per fare qualche programmazione funzionale.

È possibile incorporare alcuni elementi della programmazione funzionale in un linguaggio imperativo come Java, e anche se non è sempre un linguaggio idiomatico, può essere estremamente utile in alcuni problemi. Ad esempio, le classi anonime sono approssimativamente uguali alle chiusure, come descritto in wikipedia . La valutazione pigra dovrebbe essere una norma piuttosto che qualcosa di insolito. L'immutabilità non può essere abusata. Basta superare l'idea (quasi) obsoleta che la costruzione di nuovi oggetti anziché la modifica di quelli esistenti sia costosa a causa del consumo di GC e dell'heap - nel 99,9% dei casi semplicemente non è rilevante. In effetti, l'elaborazione parallela può capovolgere anche l'argomento dell'efficienza in senso inverso: la creazione di nuovi oggetti immutabili può essere più economica di quella esistente, perché si elimina il blocco.

Maggiori informazioni su come fare FP in puro Java qui , qui , qui e qui .

Anche se hai una squadra superba e una gestione competente per quella squadra, il tuo lavoro non è ancora sicuro. Il management superiore può ancora fare cose sciocche, come sciogliere l'intera direzione.

In breve: la politica conta, e a volte la politica che ti riguarda, non puoi controllare.

Ho appreso che lo scopo del test del software è trovare i bug . È non per verificare che il sistema sia corretto.

Ci sono importanti fattori psicologici in gioco: se il tuo obiettivo è quello di mostrare che il programma è "corretto", ti attirerai verso i test che sai passeranno. Ma se il tuo obiettivo è trovare bug, ti attirerai verso test che spingono davvero il tuo sistema al limite.

C'è persino un cambiamento importante nella lingua che usi. Se un test rileva un bug, lo chiami riuscito . Se il test non [cioè, il programma passa], lo chiami non riuscito . Mi sono sorpreso a seguire le linee del pensiero di "verifica", e fa una grande differenza.

Questo effetto psicologico è discusso di più in The Art of Software Testing , un libro classico che consiglio vivamente. L'autore, Myers, raccomanda anche che chiunque stia testando un programma non dovrebbe essere l'autore, e nemmeno nella stessa catena di gestione. Puoi farlo se stai programmando da solo, quindi ci vuole disciplina.

Realizzare lo sviluppo guidato dai test dall'inizio alla consegna di un cliente per vedere come avrebbe influito sulla qualità del codice e solo eseguendo dall'interno del launcher JUnit in Eclipse. Ha prodotto un prodotto migliore.

Il vero valore della programmazione senza ego

Ad un certo livello ho sempre saputo che l'ego e la programmazione non si mescolano, ma non hanno mai chiarito le conseguenze. L'idea che devi rivedere attivamente e trovare difetti nelle tue pratiche è qualcosa che ho iniziato a realizzare solo l'anno scorso. Sto anche imparando a cercare attivamente critiche ai miei progetti (sia in UI che in codice).

Ad essere onesti, tuttavia, sto ancora imparando come abbandonare l'ego, e probabilmente imparerò come farlo per il resto della mia carriera di programmatore.

Ecco la mia risposta alla mia stessa domanda:

Circa un anno fa ha fatto clic sul fatto che i test di accettazione automatici non dovevano essere versioni automatiche dei test che i nostri tester avrebbero fatto manualmente. Concentrarsi sui test rispetto alle singole specifiche piuttosto che cercare di colpire il più possibile in una singola passata ha reso i test molto più semplici, più facili da leggere e aiuta anche a incoraggiare la consegna incrementale.

Ho imparato come un concetto matematico come Semirings si applica agli algoritmi. Con questo puoi mostrare come alcuni algoritmi sono gli stessi tranne che per usare un semiring diverso. Questo non dovrebbe essere strano per me come programmatore, ma la mia testa è saltata.

Oltre alla politica Frank Shearar ha menzionato , ho scoperto di recente QUnit e JSCoverage che ha reso la mia giornata. E mese Non avrei mai pensato di testare il codice JavaScript con di copertura del codice, ma eccolo ...: -)

I miei primi tre ringraziamenti per l'ultimo anno di programmazione sarebbero andati al seguente (in ordine decrescente di importanza e gratitudine):

• il paradigma di programmazione funzionale per aprire la mente ad altri modi, spesso più eleganti e concisi, di esprimere idee e algoritmi nel codice. Sento che la mia capacità di programmazione generale è migliorata molto in un tempo molto breve, grazie a idee di programmazione funzionale.

  (I miei ringraziamenti personali vanno a Tomáš Petříček per il suo eccellente libro Programmazione funzionale del mondo reale .)

• sia Iniezione delle dipendenze che test delle unità mi hanno insegnato che la composizione degli oggetti è probabilmente il modo migliore per creare sistemi complessi (orientati agli oggetti) e che l'ereditarietà delle classi non è È quasi importante quanto pensavo). Entrambi mi hanno insegnato e mi hanno fatto riflettere su come comporre al meglio i sistemi e su come scrivere componenti facili da usare, ma comunque abbastanza flessibili da poter essere riutilizzati.

  (Se dovessi menzionare una buona risorsa didattica, direi il Art of Unit Testing di Roy Osherove .)

Tutti questi risultati hanno portato a scrivere codice che in genere ha meno bug di prima, perché ora sto scrivendo un codice che è molto più facile da comprendere e da sbagliare rispetto a quello che ho precedentemente messo fuori.

Ciò che cambia nel settore del software in rapida evoluzione, la curva di apprendimento è sempre qui. "Se c'era solo un modo per imparare senza perdere tempo a imparare."

Ho imparato che il fatto di essere venduto a una nuova azienda può davvero migliorare il tuo lavoro. La mia organizzazione è stata acquistata dalla nostra vecchia società a maggio, e le cose sembrano continuare a migliorare. La nuova azienda ha risparmiato poco o nessun costo con il nostro nuovo ufficio, sostituito le nostre obsolete macchine di sviluppo con attrezzature del 21 ° secolo, ha mostrato flessibilità nella gestione dei nostri progetti e in generale ci ha fatto sentire tutti più che benvenuti.

Si sente un po 'deprimente essere venduto (un po' come un servo con un nuovo signore feudale perché è legato alla terra che ha cambiato le mani), ma il risultato finale è stato molto meglio di quanto mi aspettassi.

Direi di utilizzare i test delle unità Microsoft all'interno di Visual Studio 2010.

Ho trovato davvero facile eseguire il debug di un metodo di test specifico.

Potrei eseguire in qualsiasi momento il mio progetto di test per vedere se l'applicazione del livello aziendale funziona correttamente. Il processo di test garantisce che il mio team non dovrebbe avere problemi durante l'implementazione della soluzione completa per i visitatori del nostro sito Web.

• Basic Python appreso (usandolo per scrivere script veloci a volte)

• ArchLinux installato in VM (aveva Ubuntu in VM in precedenza, il mio PC è veloce ora!)

• Iniziato con MATLAB (specialmente per il tracciamento di grafici e controlli numerici rapidi)

• Passato a Mercurial (da SVN) (ramificazione e fusione!)

L'apprendimento del modello MVVM mi ha aiutato a diventare molto meno incisivo.

Ho dovuto iniziare a mantenere un'applicazione web Python - quindi ho deciso che era un buon momento per imparare Vim . Ora sto usando il plugin IdeaVim per Intellij per il mio sviluppo Java e Flex e credo fermamente che abbia reso la mia digitazione più veloce ed efficiente.