Come gestire un'applicazione web esistente?

Crea un giocattolo. Dimostra, solo a te stesso, che puoi fare qualcosa qui dentro. Anche qualcosa che non ha nulla a che fare con ciò che vogliono. Se riesci a farlo senza rompere tutto ciò che sei sulla strada del successo. Ho detto ai datori di lavoro che non mi impegno nemmeno a fare il lavoro finché non vedrò che questo accadrà.

Seriamente, sei in cultura shock mode in questo momento. Tutto sembra indietro e sbagliato. Benvenuto nella codifica legacy. È la cosa più difficile del mondo che ti faccia entrare in una base di codice che ti chiede di fare le cose in un modo che sai essere sbagliato. Succhialo. Non puoi schioccare le dita e sistemarlo tutto in modo da accontentarti di miglioramenti incrementali quando aggiungi nuove funzionalità.

Ciò che rende davvero difficile codificare legacy è che fa diventare vecchi e nuovi la guerra in testa. È come cercare di pensare in due lingue diverse contemporaneamente. Continua a tornare alle tue fonti della migliore saggezza del giorno. In caso contrario, il codice errato inizierà a farti credere che sia OK.

Come già accennato, lascia le vecchie cose così come è, per quanto possibile, semplicemente modificandolo se necessario.

Per il database, se possibile, basta aggiungere alcune nuove colonne per supportare qualsiasi nuova funzionalità, lasciando le righe / cols esistenti così com'è in modo che tutte le query esistenti continuino a funzionare, in modo completamente trasparente senza alcun tweaking o con il minimo ritocco possibile. Se ciò comporta ridondanza, ecc., Non preoccuparti affatto (a meno che l'hardware non sia davvero in grado di gestirlo).

Ripeti: non preoccuparti della ridondanza. Non preoccuparti del vecchio quadro. Etc. Preoccupati di cosa penserà il tuo cliente alla fine dei tuoi tre mesi. Le tue preoccupazioni espresse sembrano dominate dall'idea sbagliata che stai "dipingendo te stesso in un angolo". Indovina cosa ??? ... ti stai sempre dipingendo in un angolo. Il codice / design esistente potrebbe essere l'angolo dell'ultimo decennio. Qualunque cosa tu faccia oggi, e fai a modo tuo (i tuoi strumenti preferiti, ecc.) Sarà solo in questo angolo del decennio.

Evitare l'ossessione è in definitiva impossibile. Che sia il design o l'implementazione che diventa obsoleto per primo è in palio. Se hai una profonda conoscenza del business e delle sue esigenze, forse puoi sviluppare un design davvero robusto. Parla di legacy: alcune banche stanno ancora eseguendo alcuni programmi Cobol mainframe.

Basta eseguire il lavoro in modo che il cliente possa digitare ciò che vuole digitare, leggere ciò che vuole leggere e in modo che funzioni prima di partire e funzioni correttamente. Una volta che hai diversi (forse cinque +) anni di esperienza reale, allora forse puoi iniziare a lasciare che un angolo del tuo cervello si preoccupi delle ramificazioni a lungo termine delle decisioni prese sulla base delle esigenze e degli orari odierni. Ma per il futuro prevedibile, ripeti: basta fare il lavoro. Un cliente felice è il sine qua non unico per uno sviluppatore di successo.

... application (with legacy code) uses an old framework (cakephp 2.0) and is just too old and has too many redundancy code (like a lot!).

Solo perché non ti "piace" qualcosa è non un buon motivo per riscriverlo.

My best guess is to rewrite everything in django.

Qualcuno altro in questa compagnia conosce il Django? Altrimenti, li stai sellando con qualcosa che non possono mantenere dopo che te ne sei andato. Probabilmente non andrebbe molto bene.

To finish everything correctly it would take me about 3 months of full time work. My employer wants to increase functionality. For that I also need to change the database.

Hai una lista di requisiti che devi consegnare? Se non hai questi [ampiamente] d'accordo su questo punto, allora hai poca, se non nessuna, possibilità di successo.

So my request/question is: Does anyone have any advice in how I should approach this? And is it possible to work this way at all ?

La codebase esistente ha un insieme completo di test di unità e di integrazione in modo che tu possa riscrivere tutto o parte del codice e garanzia che non hai rotto qualcosa che non significa a? Se non li hai, allora probabilmente non dovresti nemmeno considerarti avviarli (e ci vorrebbe la maggior parte, se non tutti, di quei tre mesi per creare quelle prove).