Riscrittura da Java a Clojure

La mia azienda mi ha appena chiesto di riscrivere un'applicazione Java di grandi dimensioni (50.000 singole righe di codice) (un'app Web che utilizza JSP e servlet) in Clojure. Qualcun altro ha suggerimenti su cosa dovrei fare attenzione?

Tieni presente che conosco abbastanza bene sia Java che Clojure.

Aggiornare

Ho riscritto ed è entrato in produzione. È abbastanza strano visto che la riscrittura è andata così veloce che è stata fatta in circa 6 settimane. Poiché molte funzionalità non erano ancora necessarie, sono finite più come 3000 linee di Clojure.

Ho sentito che sono contenti del sistema e sta facendo esattamente quello che volevano. L'unico svantaggio è che il tizio che mantiene il sistema ha dovuto imparare Clojure da zero, ed è stato trascinato dentro scalciando e urlando. Ho ricevuto una sua chiamata l'altro giorno che diceva che ora amava il Lisp .. divertente :)

Inoltre, dovrei fare una buona menzione a Vaadin. L'uso di Vaadin ha probabilmente rappresentato la maggior parte del tempo risparmiato e della brevità del codice rispetto a Clojure .. Vaadin è ancora il miglior framework web che abbia mai usato, anche se ora sto imparando ClojureScript con rabbia! (Si noti che sia Vaadin che ClojureScript utilizzano i framework GUI di Google sotto il cofano.)

Il più grande "problema di traduzione" sarà probabilmente il passaggio da una metodologia Java / OOP a un paradigma di programmazione Clojure / funzionale.

In particolare, invece di avere uno stato mutabile all'interno degli oggetti, il "modo clojure" consiste nel separare chiaramente lo stato mutabile e sviluppare funzioni pure (prive di effetti collaterali). Probabilmente sai già tutto questo :-)

Ad ogni modo, questa filosofia tende a condurre verso uno stile di sviluppo "dal basso verso l'alto" in cui si concentra gli sforzi iniziali sulla costruzione del giusto set di strumenti per risolvere il problema, per poi collegarli insieme alla fine. Potrebbe assomigliare a questo

1. Identifica le strutture di dati chiave e trasformale in una mappa Clojure immutabile o in definizioni di record. Non aver paura di annidare molte mappe immutabili: sono molto efficienti grazie alle strutture dati persistenti di Clojure. Vale la pena guardare questo video per saperne di più.

2. Sviluppa piccole librerie di funzioni pure, orientate alla logica di business che operano su queste strutture immutabili (es. "Aggiungi un articolo al carrello"). Non è necessario eseguire tutte queste operazioni in una volta poiché è facile aggiungerne altre in seguito, ma aiuta a farne alcune all'inizio per facilitare i test e dimostrare che le strutture dei dati funzionano ..... in entrambi i casi in questo punto puoi effettivamente iniziare a scrivere cose utili in modo interattivo su REPL

3. Sviluppare separatamente routine di accesso ai dati in grado di rendere persistenti queste strutture al / dal database o dalla rete o dal codice Java legacy secondo necessità. Il motivo per mantenerlo molto separato è che non si desidera che la logica di persistenza sia legata alle funzioni di "logica aziendale". Potresti voler guardare ClojureQL per questo, anche se è anche abbastanza facile avvolgere qualsiasi codice di persistenza Java che ti piace.

4. Scrivi test unitari (ad esempio con clojure.test ) che coprano tutto quanto sopra. Questo è particolarmente importante in un linguaggio dinamico come Clojure poiché a) non hai molta rete di sicurezza dal controllo del tipo statico eb) aiuta ad essere sicuro che i tuoi costrutti di livello inferiore funzionino bene prima di costruire troppo sopra di loro

5. Decidi come desideri utilizzare i tipi di riferimento di Clojure (vars, refs, agent e atoms) per gestire ogni parte mutabile dello stato a livello di applicazione. Funzionano tutti in modo simile ma hanno una semantica transazionale / concorrenziale diversa a seconda di ciò che si sta tentando di fare. I ref probabilmente saranno la tua scelta predefinita - ti permettono di implementare un comportamento transazionale STM "normale" avvolgendo qualsiasi codice in un blocco (dosync ...).

6. Seleziona il framework web generale corretto - Clojure ne ha già un bel po ', ma ti consiglio caldamente Ring - guarda questo eccellente video " One Ring To Bind Them " più Fleet o Enlive o Hiccup a seconda della tua filosofia di template. Quindi usalo per scrivere il tuo livello di presentazione (con funzioni come "traduci questo carrello della spesa in un frammento HTML appropriato")

7. Infine, scrivi la tua applicazione utilizzando gli strumenti sopra. Se hai eseguito correttamente i passaggi precedenti, questa sarà effettivamente la parte più facile perché sarai in grado di costruire l'intera applicazione mediante la composizione appropriata dei vari componenti con un boilerplate molto piccolo.

Questa è più o meno la sequenza in cui attaccherei il problema poiché rappresenta ampiamente l'ordine delle dipendenze nel codice e quindi è adatta per uno sforzo di sviluppo "dal basso verso l'alto". Anche se, naturalmente, in un buon stile agile / iterativo, probabilmente ti ritroveresti a spingere in avanti in anticipo verso un prodotto finale dimostrabile e poi tornare ai passaggi precedenti abbastanza frequentemente per estendere la funzionalità o il refactoring secondo necessità.

ps Se segui l'approccio di cui sopra, sarei affascinato nel sentire quante righe di Clojure servono per abbinare la funzionalità di 50.000 righe di Java

Aggiornamento : da quando questo post è stato scritto originariamente, sono emersi un paio di strumenti / librerie extra che si trovano nella categoria "check out":

• Noir - framework web che si basa su Ring.
• Korma - un DSL molto carino per l'accesso ai database SQL.

Quali aspetti di Java include il tuo progetto attuale? Registrazione, transazioni di database, transazioni dichiarative / EJB, livello web (hai menzionato JSP, servlet) ecc. Ho notato che l'ecosistema Clojure ha vari micro-framework e librerie con l'obiettivo di svolgere un'attività e farlo bene. Suggerirei di valutare le biblioteche in base alle tue necessità (e se scalare in progetti di grandi dimensioni) e prendere una decisione informata. (Dichiarazione di non responsabilità: sono l'autore di bitumenframework ) Un'altra cosa da notare è il processo di costruzione: se hai bisogno di una configurazione complessa (dev, testing, staging, prod) potresti dover dividere il progetto in moduli e avere il processo di build programmato per facilità.

Ho scoperto che la parte più difficile era pensare al database. Esegui alcuni test per trovare gli strumenti giusti che desideri utilizzare lì.