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

Molte persone nella comunità dei programmatori parlano di miglioramento continuo, pratica deliberata e così via - ma quando parlano delle loro pratiche attuali è quasi come se fossero "completamente formati dai lombi di Zeus" perché non si sente parlare di come le loro opinioni sono cambiate nel tempo o ciò che hanno imparato di recente.

Di tanto in tanto vado a parlare, o leggo un libro, o parlo con qualcuno e si aprono un po 'di più e trovo che imparo molto da queste intuizioni.

Quindi, se dovessi scegliere una cosa negli ultimi 12 mesi che hai imparato quale sarebbe?

Ho imparato che basta un solo manager marcio per rovinare l'intero progetto, ma ci vogliono molti bravi programmatori per ripulire il disordine in seguito.

Dopo aver appreso Clojure , ho iniziato a rendermi conto dell'utilità della programmazione funzionale e il mio stile di programmazione Java ne è stato fortemente influenzato. Contrariamente alla credenza popolare, un linguaggio di programmazione funzionale non è un prerequisito assoluto per eseguire una programmazione funzionale.

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

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

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

In breve: la politica conta, e talvolta la politica che ti riguarda, non puoi controllarla.

Ho imparato che lo scopo del test del software è trovare bug . E ' non è per verificare che il sistema sia corretta.

Ci sono importanti fattori psicologici in gioco: se il tuo obiettivo è dimostrare che il programma è "corretto", graviterai verso test che sai che passeranno. Ma se il tuo obiettivo è trovare dei bug, graviterai su test che spingono davvero il tuo sistema al limite.

C'è anche un cambiamento importante nella lingua che usi. Se un test rileva un bug, lo chiami successo . Se il test non [vale a dire, il programma passa], lo si chiama 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 inoltre a chiunque stia testando un programma di non essere l'autore, e neppure nella stessa catena di gestione. Puoi farlo se stai programmando da solo, quindi ci vuole disciplina.

Effettuare test guidati dallo sviluppo fin dalla consegna di un cliente per vedere come ciò influirebbe sulla qualità del codice e funzionando solo all'interno del programma di avvio di 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 ne ho mai del tutto discusso 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 le critiche ai miei progetti (sia nell'interfaccia utente che nel codice).

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

Ecco la mia risposta alla mia domanda:

Circa un anno fa ha fatto clic sul fatto che i test di accettazione automatizzati non dovevano essere versioni automatizzate dei test che i nostri tester avrebbero effettuato manualmente. Concentrarsi sui test rispetto alle singole specifiche anziché cercare di colpirli il più possibile in un singolo passaggio 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 uguali tranne che per l'utilizzo di un diverso semiring. Questo non dovrebbe essere così strano per me come programmatore, ma la mia testa era scoppiata.

Oltre alla politica di cui parla Frank Shearar , ho scoperto di recente QUnit e JSCoverage che hanno reso la mia giornata. E mese. Non avrei mai pensato che sarebbe stato possibile testare l'unità JavaScript con copertura del codice, ma eccolo ... :-)

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

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

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

• sia la dipendenza iniezione e unit test mi hanno insegnato che la composizione oggetto è probabilmente il modo migliore per realizzare sistemi complessi (orientati agli oggetti) (e che l'ereditarietà classe non è così importante come pensavo). Entrambi mi hanno insegnato e mi hanno fatto riflettere su come comporre meglio i sistemi e su come scrivere componenti che siano facili da usare, ma ancora abbastanza flessibili per essere riutilizzati.

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

Tutti questi insieme mi hanno portato a scrivere codice che generalmente ha meno bug rispetto a prima, perché ora sto scrivendo codice che è molto più facile da capire e sbagliare rispetto a quello che ho precedentemente pubblicato.

Qualunque cosa cambi nel settore del software in rapida evoluzione, la curva di apprendimento è sempre qui. "Se ci fosse solo un modo per imparare senza prendere tempo per imparare."

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

È un po 'deprimente essere venduto (un po' come un servo che ha 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 usare i test unitari di Microsoft in Visual Studio 2010.

Ho trovato davvero facile eseguire il debug di un metodo di prova 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.

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

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

• Iniziato con MATLAB (in particolare per la stampa di grafici e rapidi controlli numerici)

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

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

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