Paura che l'app Web non sia "a prova di futuro"

Sono uno sviluppatore web di una piccola applicazione Web SaaS locale. Attualmente ha circa una mezza dozzina di clienti.

Mentre continuo a progettare l'applicazione, diventa sempre più difficile per me convincermi a impegnarmi in qualsiasi momento nel progetto, che è accaduto nella fase iniziale. Dopo essermi affezionato al progetto e al codice che ho già scritto, ho paura che tutto il lavoro aggiuntivo che commetto venga annullato nel prossimo futuro, quando l'app si rivelerà non ridimensionarsi man mano che l'azienda cresce.

Come studente universitario che fa domanda per uno stage, ho avuto dubbi sui datori di lavoro sulla mia scelta di non utilizzare alcun framework web durante le interviste, il che mi ha solo fatto dubitare ulteriormente del mio lavoro precedente. Semplicemente non conosco alcun framework web e non so quale iniziare a usare.

Ho fatto uno stage come sviluppatore full-stack a gennaio, dove inizierò a imparare i framework front-end, ma la pressione per finire l'app sta aumentando e sto pensando di demolire completamente l'app e ricominciare da capo, che è qualcosa che ho fatto prima. L'app attualmente è costruita in PHP e jQuery (per chiamate AJAX) e utilizza MySQL per il suo database. Qualche idea su come posso superare questo blocco mentale e per garantire che la mia app sia scalabile? Grazie in anticipo.

Perfetto è il nemico del bene.

O in altri termini, non preoccuparti oggi. Se la tua app fa quello che deve fare, va bene. E ' non è una brutta cosa per riscrivere parti del software, più in basso la linea; a quel punto 1) sai più chiaramente cosa stai cercando di costruire e 2) sai quali bit sono in realtà il collo di bottiglia. Potresti trascorrere un'enorme quantità di tempo a scrivere un'app che si ridimensionerebbe a un milione di utenti, ma non sarebbe meglio per i tuoi attuali sei clienti di quello che hai oggi .

Qualche idea su come posso superare questo blocco mentale e per garantire che la mia app sia scalabile?

Il nocciolo del problema non è la scalabilità. Il nocciolo del problema è pensare che la prima volta lo otterrai correttamente .

Dovresti concentrarti sulla scrittura di codice pulito. Perché il codice pulito massimizza la comodità quando (inevitabilmente) devi cambiare qualcosa in futuro. E questo è il vero obiettivo che dovresti avere.

Quello che stai cercando di fare ora è provare a pensare al codice perfetto da scrivere. Ma anche se riesci a farlo, chi dice che i requisiti non cambieranno o forse hai preso le tue decisioni sulla base di informazioni errate o comunicazioni errate?

Non puoi evitare di fare errori, anche se non sono colpa tua. Concentrati sulla scrittura di codice in cui è facile cambiare le cose in seguito, invece di sperare di scrivere codice che non dovrai cambiare in futuro.

Essendo cresciuto attaccato al progetto e al codice che ho già scritto,

Sono assolutamente d'accordo con questo sentimento. Ma attaccarti al codice che hai scritto è un problema.

L'unica cosa che dovrebbe essere una costante è il tuo desiderio di risolvere un problema specifico . Il modo in cui risolvi questo problema è solo una preoccupazione secondaria.

Se domani verrà rilasciato un nuovo strumento che riduce la tua base di codice dell'80%, sarai sconvolto dal fatto che il tuo codice non sarà più utilizzato; o sarai felice che la tua base di codice sia diventata più piccola e molto più pulita / più gestibile?

Se il primo, hai un problema: non vedi la soluzione per il codice . In altre parole, ti stai concentrando sul codice e non vedi l'immagine più grande (la soluzione che mira a fornire).

Ho paura che tutto il lavoro aggiuntivo che commetto sarà annullato nel prossimo futuro, quando l'app non si ridimensionerà bene man mano che l'azienda cresce.

Questo è un problema diverso per un giorno diverso.

Innanzitutto, costruisci qualcosa che funzioni. In secondo luogo , si migliora il codice per correggere eventuali difetti che può ancora mostrare. Quello che stai facendo attualmente è trattenere il primo compito per paura di dover fare il secondo compito.

Ma quale altra opzione c'è? Non puoi dire al futuro . Se passi il tuo tempo a meditare sulle possibilità future, finirai comunque per indovinare . Un'ipotesi è sempre incline a essere completamente sbagliata.

Invece, crea l'applicazione e dimostra che c'è davvero un problema. E una volta che il problema è chiaro, allora inizi a risolverlo.

Per dirla in altro modo: Henry Ford non ha mai costruito un'auto conforme agli standard / aspettative del 2018. Ma se non avesse costruito la Model T, un'auto difettosa secondo gli standard moderni, nessuno avrebbe iniziato a usare le auto, non ci sarebbe l'industria automobilistica e nessuno avrebbe avuto un'auto che avrebbe potuto quindi provare a migliorare.

Ho avuto dubbi da parte dei datori di lavoro sulla mia scelta di non utilizzare alcun framework web durante le interviste, il che mi ha solo fatto dubitare ulteriormente del mio lavoro precedente.

La parte importante qui non è quale struttura stai usando (qualsiasi datore di lavoro che ti giudica che non sta facendo il proprio lavoro correttamente). La parte importante qui è sapere cosa stai facendo e perché lo stai facendo .

Ad esempio, potresti evitare il framework esistente in particolare perché vuoi imparare perché un framework è utile eseguendolo prima nel modo più difficile. Oppure potresti provare a creare il tuo framework.

L'unica risposta negativa qui è "Non lo so", in quanto mostra una mancanza di decisioni informate. Questa è una bandiera rossa per un datore di lavoro.

Semplicemente non conosco alcun framework web e non so quale iniziare a usare.

Lo stesso problema sorge qui. La soluzione non è pensare di più, ma piuttosto agire:

• Smetti di meditare sulla risposta perfetta .
• Scegli un quadro. A meno che tu non abbia una preferenza, scegline una casuale. Usa un bersaglio, tira un dado, lancia una moneta, scegli una carta.
• Usalo
• Ti è piaciuto usarlo? Hai trovato qualcosa di fastidioso?
• Cerca come prevenire questi elementi cattivi. Hai utilizzato in modo improprio il framework o è solo così che dovrebbe funzionare il framework?
• Una volta che senti di avere una presa sul framework (indipendentemente dal fatto che ti piaccia o no), scegli un nuovo framework e ripeti il ​​ciclo.

Per saperne di più, leggi La mentalità che fa> la mentalità che pensa . L'autore lo spiega meglio di me.

ma la pressione per completare l'app sta aumentando e sto pensando di demolire completamente l'app e ricominciare da capo

A meno che l'attuale base di codice non sia assolutamente disordinabile; stai prendendo la decisione opposta.
Gli sviluppatori pensano spesso che buttare le cose sarebbe la scelta migliore. È una sensazione molto comune. Ma raramente è la scelta giusta.

Lanciare il codice e ricominciare da zero è come rimanere bloccati nel traffico mentre vai al lavoro, preoccupandoti di arrivare tardi al lavoro (manchi la scadenza), e invece guida a casa e prova a guidare di nuovo lungo la stessa strada. Non ha senso. Potresti essere bloccato nel traffico, ma sei ancora più vicino al lavoro di quando eri a casa.

Nonostante l'enorme quantità di denaro che Facebook e Google hanno investito nel marketing per convincerti del contrario, i framework front-end esistono per due motivi principali:

• Innanzitutto, scaricare le richieste hardware / di rete alle operazioni lato client inserendo stato e logica nel client
• In secondo luogo, pertinenti alla logica client aggiuntiva necessaria per supportare il primo punto, forniscono contesti di esecuzione isolati in modo da poter inserire il codice di altre persone in una pagina senza interrompere nulla.

Probabilmente devi solo cercare un framework per risolvere questi problemi se la tua applicazione è intrinsecamente stateful, se la quantità di stato dell'applicazione che stai salvando sul lato client è piuttosto complessa, se ti aspetti molti client con una latenza di rete scadente (mobile, o distante dal server) o in caso di forte necessità aziendale di supportare CSS particolarmente avanzati o la creazione di elementi dinamici.

Il framework marketing vuole farti credere che il loro speciale metodo di architettura aumenta la velocità di sviluppo e semplifica la manutenzione. Ciò è palesemente falso per i piccoli team che lavorano su progetti semplici. L'isolamento del codice e l'organizzazione delle importazioni possono aiutare una grande squadra a immettere più rapidamente un prodotto sul mercato. Fornisce molto meno a un team di sviluppo di una sola persona che lavora su un progetto già funzionale.

Trascorrerai più tempo a imparare come adattare il codice funzionale esistente al framework di quanto non implementerai effettivamente le funzionalità, e è abbastanza probabile che qualcuno da qualche parte aggiorni qualcosa, e il codice scritto in quel framework cesserà di funzionare entro 18 mesi a meno che qualcuno è lì per mantenerlo costantemente.

Vanilla JS, e in misura minore ma comunque significativa JQuery, non soffrono di questi problemi. Con alcune notevoli eccezioni, le applicazioni JQuery + AJAX che non si basano su comportamenti specifici del browser e che rinunciano a dipendenze esterne laddove sensate, continuano a funzionare 10-15 anni dopo che sono state originariamente scritte con modifiche molto lievi.

I frame sono ideali per le startup tipiche che supportano applicazioni Web continue, complesse e rivolte al pubblico. Consentono ai grandi team di coordinarsi bene insieme, si integrano perfettamente con i framework di aggiunta del fornitore e supportano nuovi appariscenti widget e paradigmi di progettazione per aiutarti a rimanere competitivo.

Niente di tutto ciò conta per un piccolo strumento software con un pubblico fisso che stai per abbandonare. Assumere un framework rallenta la velocità di sviluppo mentre ti adatti a un nuovo paradigma e introduce inutili rischi di compatibilità. Mantenere semplice il codice lato client (e idealmente ospitato autonomamente) significa che la superficie del rischio di compatibilità diminuisce in modo significativo. I browser cambieranno, gli URL CDN smetteranno di funzionare, le dipendenze non saranno aggiornate - Ma nessuno sta toccando quel server e continuerà a funzionare bene.

Non adottare una struttura a meno che non risolva un problema architettonico specifico che hai oggi o che puoi prevedere presto, e considera fortemente di affrontare tale preoccupazione con un altro mezzo, se ciò è assolutamente sostenibile.

La cosa migliore che puoi fare per "proteggere il futuro" dalla tua app è seguire le migliori pratiche nella progettazione del tuo sistema per massimizzare l'accoppiamento libero e la separazione delle preoccupazioni. Non c'è parte della tua app che sia sicura da diventare obsoleta, ma molto puoi fare per isolare il codice che diventa obsoleto per il motivo X dal codice che non deve necessariamente essere influenzato da X.

Tuttavia, direi che la tua preoccupazione dovrebbe essere inferiore per la crescita / scalabilità della tua app rispetto al tasso di crescita della tua esperienza e capacità. Il blocco mentale che descrivi mi suona come l'apprendimento della stagnazione o la consapevolezza di molte incognite conosciute senza la strategia o gli strumenti per affrontarle.

I frame non sono particolarmente adatti a risolvere la sfida "a prova di futuro", sebbene possano fornire una guida iniziale pertinente agli inesperti, di solito tramite schemi di progettazione di alto livello come MVC. Piuttosto, tendono ad essere più utili come modi per accelerare lo sviluppo fornendo una forte coesione e spesso a scapito di un accoppiamento più stretto. Ad esempio, supponiamo di utilizzare un sistema di mappatura relazionale degli oggetti fornito dal framework in tutta l'app per interagire con il database, completo di integrazione del sistema di memorizzazione nella cache. Forse in seguito è necessario passare a un archivio dati non relazionale e ora tutto ciò che lo utilizza è interessato.

Il pasticcio che ora non proviene da quello che hai usato, ma da dove l' hai usato (probabilmente praticamente ovunque nel back-end). Quanto sarà meglio se il codice che esegue il rendering di una pagina non recupera mai i dati che esso visualizza.

Supponiamo di voler aggiungere un piccolo widget a una pagina che richiede script e risorse extra per funzionare correttamente. Se stai usando un framework, puoi chiedere "Come vuole che io aggiunga le dipendenze a una pagina per questa cosa?" In caso contrario, la domanda è più aperta: "Quali sono le preoccupazioni tecniche che sto toccando che dovrebbero essere in qualche modo separate?" Questa domanda richiede più esperienza per rispondere, ma ecco alcuni suggerimenti:

• Cosa succederebbe se domani trasferissi tutte le tue risorse statiche (script, immagini, ecc.) Su un server separato, una rete di distribuzione dei contenuti, ecc., O iniziassi a provare a raggrupparle tutte insieme per migliorare le prestazioni?
• Cosa succederebbe se iniziassi a posizionare questo widget su pagine diverse o più istanze di esso sulla stessa pagina?
• Come potresti iniziare a eseguire test AB su diverse versioni del widget?

Se qualcuno di questi suoni sembra travolgente, suggerirei che dovresti usare un framework per ora, non tanto per il bene della tua app, ma per il bene della tua crescita personale. Non necessariamente ricominciare però. Utilizza invece i framework come curriculum per guidare l'evoluzione della tua app.

Ci sono solo due modi per imparare. Uno è basato su tentativi ed errori, e l'altro è imparando dall'esperienza degli altri. Prova ed errore non possono essere eliminati. Lo sviluppo del software è per sua natura un campo di apprendimento continuo e qualsiasi codice che non fa qualcosa di nuovo o diverso è per definizione superfluo. (Usa invece il codice già scritto.)

Il trucco è minimizzarlo cercando in modo proattivo conoscenze preesistenti (strategie, best practice e codice / librerie / framework) in ogni fase del processo di sviluppo in modo da non ritrovarti a reinventare costantemente la ruota.

Per quanto riguarda l'app che stai scrivendo, tuttavia, la tua prima preoccupazione dovrebbe essere semplicemente quella di farlo con un minimo di sforzo banale (che è un po 'come l'odore del codice, ma per il processo di sviluppo). Data la natura dell'apprendimento umano, il modo più veloce per raggiungere un'alta qualità è iniziare con qualcosa . È molto più facile capire l'obiettivo quando puoi modellarlo criticando qualcosa che hai già.

Se riesci ad accettare che gran parte del codice che scrivi è un processo di apprendimento usa e getta e necessario per trovare buoni progetti, ciò ti motiverà in modo utile a mantenerlo. Dopotutto, è la sfida della risoluzione dei problemi che rende coinvolgente lo sviluppo del software e tale sfida è sempre presente se ciò che stai facendo è utile (vedi la dichiarazione "apprendimento continuo" sopra).

Soprattutto, "demolire la cosa e ricominciare" non è mai un'opzione ... dopotutto, non hai detto di avere "una mezza dozzina di clienti?" Non sei ancora pausa di prendere in considerazione ciò che potrebbero pensare del pronunciamento, dato che sono in questo momento (presumibilmente) "perfettamente felice con il vostro lavoro ?!"

Ecco un'analogia che mi piace usare:

• "Il mio lavoro è costruire case in cui le persone possano vivere, persone in cui costruire attività commerciali e così via". Il mio compito è quello di fare "quei frammenti di sabbia incredibilmente piccoli e troppo glorificati " per fare un lavoro utile. (Proprio come i costruttori di case costruiscono case da cartongesso, piastrelle di ceramica, blocchi di cemento e 2x4.)

• Tuttavia, mentre i "chiodi" utilizzati dai costruttori di case in realtà non sono cambiati molto in duecento anni (tranne che per passare da "quadrati" a "rotondi", per poi essere resi utili con le chiodatrici pneumatiche), la tecnologia che usiamo è in continua evoluzione e talvolta subisce un cambiamento molto profondo. ("Così è andata.")

• "Tuttavia, ogni casa, una volta costruita, sarà per sempre dopo essere vissuto in." Non puoi sfrattarli. Una volta costruito e consegnato le chiavi, "non è più la 'tua' casa." È quello che è adesso e durerà a lungo.

Oggi gran parte della mia attività è di aiutare i clienti a far fronte al software che è stato costruito dieci, venti, trenta o più anni fa, utilizzando le tecnologie "allo stato dell'arte" esistenti a quei tempi - (e che, ahem, Ricordo) - e che sono ancora in servizio (!) Oggi.

Garantire che qualcosa sia una prova futura è quasi impossibile. Controllare che l'app sia scalabile non è troppo difficile. Devi solo scrivere un test delle prestazioni per l'app e vedere quanti client può gestire. Scrivere test renderà sicuramente la tua app più a prova di futuro perché sarai in grado di valutare come si comporta l'app dopo aver implementato più modifiche in essa.

Wrt Framework, non sarei troppo preoccupato per prestazioni / scalabilità. Questo è qualcosa che puoi facilmente controllare e molto probabilmente risolvere. Il problema più grande è la sicurezza. I framework Web di solito ti aiutano a scrivere il codice di autenticazione, i cookie, la protezione CSRF, ecc. Soprattutto data la tua mancanza di esperienza, una maggiore attenzione in quell'area.

Ho iniziato a scrivere un commento sui framework di apprendimento, ma alla fine si è trasformato in qualcosa di più simile a una risposta, quindi eccolo qui.

Non conoscere alcun framework sembra un problema. Praticamente in qualsiasi lavoro webdev dovrai lavorare con qualche framework. Imparare un'altra quadro dopo si conosce uno non è che un grosso problema, ma imparare il primo può richiedere del tempo - che è il motivo per cui i datori di lavoro possono preoccuparsi di questo. Evitare quadri può indicare qui la sindrome non inventata , che è un approccio ampiamente poco pratico.

Poiché il punto principale della conoscenza dei tuoi primi quadri è imparare una lingua comune, forse prova a imparare qualcosa di popolare tra i tuoi coetanei. Puoi provare a modificare alcuni semplici progetti scritti in un framework. Iniziare un progetto da zero in un framework che non conosci è un metodo di apprendimento molto inefficace.

Ora, la tua vera domanda era su un progetto specifico e portarlo su un framework. Per questo, la risposta sembra essere: dipende, e non possiamo davvero dirtelo. Tuttavia, il porting di roba su un framework che non conosci è quasi sicuramente una cattiva idea, dato che non puoi nemmeno sapere se abbia senso . Quindi, sembra che dovresti lasciarlo così com'è, e rivisitare questa decisione ad un certo punto, una volta che conosci e ti piace un po 'di quadro. Altre risposte contengono buoni punti su cosa dovresti cercare quando prendi tale decisione.

Questo articolo ha attirato molta attenzione su Hacker News 2,5 anni fa: scrivere codice facile da eliminare, non facile da estendere. Questa prospettiva può aiutarti o meno a gestire la tua base di codice attuale, ma in futuro potrebbe aiutare a prevenire la frustrazione derivante dal perfezionismo / eccesso di ingegneria.

Se vediamo "righe di codice" come "righe spese", quando eliminiamo righe di codice, stiamo riducendo i costi di manutenzione. Invece di creare software riutilizzabile, dovremmo cercare di creare software usa e getta.

Non ho bisogno di dirti che cancellare il codice è più divertente che scriverlo.

(enfatizzare il mio)

Anche il thread dell'articolo su Hacker News potrebbe valere la pena di essere letto.

Per quanto riguarda la realizzazione di prove future e l'applicazione di principi di scala e quadro, è un compito arduo da svolgere da soli, probabilmente non me ne preoccuperei, ma se devi:

Mantieni pulito il tuo codice, segui i principi SOLID, DRY> google.

Applicare un bilanciamento del carico il prima possibile.

Stand up almeno due server Web, gestire scenari di bilanciamento del carico nel codice.

E, ultimo ma non meno importante, ci sono stack migliori per la gestione di un milione di utenti rispetto a LAMP, ma sono sicuro che sia totalmente fattibile.

Caso e punto, vedere: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance- startts-to-degrade Il punto è valido, ma 10 GB è banale come soggetto di prova.