La paura dell'app web non è "a prova di futuro"

Perfetto è il nemico del bene.

O metti un altro modo, non ti preoccupare oggi. Se la tua app fa ciò che deve fare, allora va bene. È non una brutta cosa per riscrivere parti del software più avanti; a quel punto tu 1) sai più chiaramente cosa stai cercando di costruire e 2) conosci quali bit sono in realtà il collo di bottiglia. Potresti dedicare un'enorme quantità di tempo a scrivere un'app che potrebbe scalare a un milione di utenti, ma non sarebbe meglio per i tuoi attuali sei clienti rispetto a quello che hai oggi .

Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?

Il nocciolo del problema non è la scalabilità. Il nocciolo della questione è pensando che la prima volta ti capiterà .

Dovresti concentrarti sulla scrittura di codice pulito. Perché il codice pulito massimizza la convenienza 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 problemi di comunicazione?

Non puoi evitare di commettere 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 modificare in futuro.

Having grown attached to the project and the code I've already written,

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 il problema è solo una preoccupazione secondaria.

Se domani viene rilasciato un nuovo strumento che riduce il numero di codice dell'80%, sarai sconvolto dal fatto che il tuo codice non viene più utilizzato; o sarai felice che il tuo codebase sia diventato più piccolo e molto più pulito / più gestibile?

Se il primo, hai un problema: sei non vedere 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).

I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.

Questo è un problema diverso per un giorno diverso.

In primo luogo, costruisci qualcosa che funzioni. In secondo luogo , migliori il codice per correggere eventuali difetti che potrebbero ancora mostrare. Quello che stai facendo attualmente è trattenendo il primo compito per paura di dover eseguire il secondo compito.

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

Invece, crea l'applicazione e prova che esiste effettivamente un problema. E una volta che il problema è chiaro, inizierai ad affrontarlo.

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

I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.

La parte importante qui non è quale struttura stai usando (qualsiasi datore di lavoro che ti giudichi 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 facendolo prima nel modo più difficile. Oppure potresti provare a creare il tuo framework.

L'unica cattiva risposta qui è "Non so", poiché mostra la mancanza di prendere decisioni informate. Che è una bandiera rossa per un datore di lavoro.

I simply don't know any web frameworks, and don't know which one to start using.

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

• Smetti di riflettere sulla risposta perfetta .
• Scegli un framework. A meno che tu non abbia una preferenza, sceglierne una a caso. Usa un bersaglio, tira un dado, lancia una moneta, prendi una carta.
• Usalo.
• Ti è piaciuto usarlo? C'è qualcosa che hai trovato fastidioso?
• Cerca come prevenire questi elementi negativi. Hai abusato del framework, o è proprio così che dovrebbe funzionare il framework?
• Una volta che senti di avere una presa sul framework (indipendentemente dal fatto che ti piaccia o meno), scegli un nuovo framework e ripeti il ciclo.

Per saperne di più, leggi Il mindset che fai > la mentalità del pensiero . L'autore lo spiega meglio di me.

but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over

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

Lanciare il codice e partire da zero è come rimanere bloccati nel traffico mentre ti rechi al lavoro, preoccupandoti che sarai in ritardo al lavoro (salta la scadenza), e invece guidi a casa e prova ancora a percorrere la stessa strada. Non ha senso. Potresti essere bloccato nel traffico, ma sei ancora più vicino al lavoro rispetto a quando eri a casa.

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

• In primo luogo, scaricare le richieste hardware / di rete per le operazioni lato client inserendo lo stato e la 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 stipare il codice di altre persone in una pagina senza interrompere nulla.

Probabilmente hai bisogno solo di raggiungere un framework per risolvere questi problemi se la tua applicazione è intrinsecamente statica, se la quantità di stato dell'applicazione che stai salvando lato client è piuttosto complessa, se ti aspetti un gran numero di client con una cattiva latenza di rete (mobile o distante dal server) o se c'è una strong esigenza aziendale di supportare CSS particolarmente avanzati o la creazione di elementi dinamici.

Il marketing quadro vuole farti credere che il loro particolare metodo di architettura aumenti la velocità di sviluppo e faciliti la manutenzione. Questo è palesemente falso per i piccoli team che lavorano su progetti semplici. Isolare il codice e organizzare le importazioni può aiutare un grande team a portare più rapidamente sul mercato un prodotto. Fornisce molto meno per un team di sviluppo di una sola persona che lavora su un progetto già funzionante.

Trascorrerai più tempo a imparare come inserire nel framework il codice funzionale esistente rispetto a quello che effettivamente implementerai, e ci sono buone probabilità che qualcuno da qualche parte aggiorni qualcosa, e il codice scritto in quel framework cesserà di funzionare all'interno di 18 mesi a meno che qualcuno non sia lì per mantenerlo costantemente.

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

I framework sono ottimi per le tipiche startup che supportano applicazioni web complesse e rivolte al pubblico. Consentono ai grandi team di coordinarsi bene insieme, si integrano piacevolmente con i framework di aggiunta dei fornitori e supportano nuovi e appariscenti widget e paradigmi di progettazione per aiutarti a rimanere competitivo.

Niente di tutto questo è importante per un piccolo strumento software con un pubblico fisso che stai per abbandonare. L'adozione di un framework rallenta la velocità di sviluppo mentre si adatta a un nuovo paradigma e introduce inutili rischi di compatibilità. Mantenere il codice lato client semplice (e idealmente auto-ospitato) significa che la superficie del rischio di compatibilità scende in modo significativo. I browser cambieranno, gli URL CDN smetteranno di funzionare, le dipendenze diventeranno obsolete. Ma nessuno sta toccando quel server e continuerà a funzionare bene.

Non adottare un framework a meno che non risolva un problema architettonico specifico che hai oggi o che possa prevedere presto, e considera strongmente di affrontare tale problema con altri mezzi, se invece è del tutto sostenibile.

La cosa migliore che puoi fare per "future proof" è che la tua app segua le migliori pratiche nella progettazione del tuo sistema per massimizzare l'accoppiamento e la separazione dei problemi. Non c'è nessuna parte della tua app che sia sicura di diventare obsoleta, ma puoi fare molto per isolare il codice che diventa obsoleto per la ragione X dal codice che necessariamente deve essere influenzato da X.

Tuttavia, ritengo che la tua preoccupazione debba essere minore per la crescita / scalabilità della tua app rispetto al tasso di crescita della tua esperienza e capacità. Il blocco mentale che descrivi mi sembra sia una stagnazione dell'apprendimento sia la consapevolezza di molti sconosciuti noti senza la strategia o gli strumenti per affrontarli.

I framework non sono particolarmente adatti per risolvere la sfida di "future-proofing", sebbene possano fornire una guida di iniziale per inesperti, solitamente attraverso modelli di design di alto livello come MVC. Piuttosto, tendono ad essere più utili come modi per accelerare lo sviluppo fornendo una strong coesione e spesso alla spesa dell'accoppiamento più stretto. Ad esempio, supponiamo di utilizzare un sistema di mapping relazionale a oggetti fornito dal framework in tutta l'app per interagire con il database, completo di integrazione del caching-system. Forse in seguito è necessario passare a un archivio dati non relazionale e ora tutto che lo utilizza è interessato.

Il pasticcio ora non è venuto da che hai usato, ma dove lo hai usato (probabilmente praticamente ovunque sul back-end). Quanto meglio starai se il codice che esegue il rendering di una pagina non recupera mai i dati che esegue il rendering.

Supponiamo di voler aggiungere qualche piccolo widget a una pagina che richiede che script e risorse extra funzionino correttamente. Se stai usando un framework, puoi chiedere "Come vuoi che aggiunga le dipendenze a una pagina per questa cosa?" Se non lo sei, la domanda è più aperta: "Quali problemi tecnici sto toccando dovrebbero essere in qualche modo separati?" Questa domanda richiede più esperienza per rispondere, ma qui ci sono alcuni suggerimenti:

• Che cosa succederebbe se domani avessi spostato tutte le risorse statiche (script, immagini, ecc.) su un server separato, rete di distribuzione del contenuto, ecc. o avessi iniziato a provare a comprimerle tutte insieme per migliorare le prestazioni?
• Che cosa accadrebbe se avessi iniziato a posizionare questo widget su pagine diverse o più istanze di esso sulla stessa pagina?
• Come potresti iniziare a eseguire test A-B su diverse versioni del widget?

Se qualcuno di questi suoni sembra travolgente, ti suggerisco di dovrebbe utilizzare un framework per ora, non tanto per la tua app, ma per il tuo personale sviluppo. Tuttavia, non ricominciare da capo. Usa invece i framework come curriculum per guidare l'evoluzione della tua app.

Ci sono solo due modi per imparare. Uno è per 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 faccia qualcosa di nuovo o diverso è per definizione inutile. (Usa invece il codice che è già stato scritto.)

Il trucco è minimizzarlo ricercando proattivamente le conoscenze preesistenti (strategie, best practice e codice / librerie / framework) in ogni fase del processo di sviluppo in modo da non ritrovarti costantemente a reinventare 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 lo sviluppo processi). Data la natura dell'apprendimento umano, il modo più veloce per ottenere un'alta qualità è iniziare con qualcosa . È molto più facile capire l'obiettivo quando puoi modellarlo criticando qualcosa che già possiedi.

Se puoi accettare che gran parte del codice che scrivi è un processo di apprendimento usa e getta e necessario per trovare buoni progetti, che ti motiveranno utilmente per mantenerti. Dopotutto, è la sfida del problem solving che rende lo sviluppo del software coinvolgente, e questa sfida è sempre presente se quello che stai facendo è utile (vedi la dichiarazione "apprendimento continuo" sopra).

Soprattutto, "eliminare la cosa e ricominciare" è mai un'opzione ... dopotutto, non hai detto di avere "una mezza dozzina di clienti?" Ti sei ancora fermato a considerare cosa loro potrebbero pensare al tuo pronunciamento, dato che sono in questo momento (presumibilmente) " perfettamente soddisfatto del tuo lavoro?! "

Ecco un'analogia che mi piace usare:

• "Il mio lavoro è costruire case in cui le persone possano vivere, affinché le persone costruiscano attività commerciali e così via." Il mio compito è fare "quei piccoli bit di sabbia" così incredibilmente piccoli e troppo gloriosi per fare un lavoro utile. (Proprio come costruttori di case costruiscono case da pannelli di gesso, piastrelle di ceramica, blocchi di cemento e 2x4.)

• Tuttavia, mentre i "chiodi" che usano i costruttori di case in realtà non sono cambiati molto in duecento anni (tranne che per passare da "quadrato" a "rotondo", e quindi per essere resi utili con le chiodatrici pneumatiche), la tecnologia che utilizziamo è in continua evoluzione e talvolta subisce profondi cambiamenti. ("Così va.")

• "Ciononostante, ogni casa, una volta costruita, rimarrà per sempre essere vissuta in." Non puoi sfrattarli. Una volta costruito e consegnato le chiavi, "non è più la tua casa". È ciò che è giusto, ora è, e durerà a lungo.

Gran parte della mia attività in questi giorni è quella di aiutare i clienti a far fronte a software che è stato costruito dieci, venti, trenta o più anni fa, usando le tecnologie "state-of-the-art" che esistevano in quei giorni - (e che, ahem, ricordo) - e che sono ancora in servizio (!) oggi.

Garantire qualcosa è una prova del futuro è quasi impossibile. Tuttavia, verificare che l'app sia scalabile non è troppo difficile. Hai solo bisogno di 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'applicazione dopo aver implementato più modifiche in essa.

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

Ho iniziato a scrivere un commento sull'apprendimento dei framework, ma alla fine è diventato qualcosa di più simile a una risposta, quindi eccolo qui.

Non conoscere alcun framework sembra un problema. In pratica qualsiasi lavoro di webdev dovrai lavorare con il framework alcuni . Imparare un'altra struttura dopo aver saputo che uno non è tale un grosso problema, ma imparare il primo potrebbe richiedere un po 'di tempo - ecco perché i datori di lavoro potrebbero interessarsene. Evitare i quadri può indicare la sindrome non inventata qui , che è un approccio ampiamente poco pratico.

Dato che il punto principale per conoscere i tuoi primi quadri è imparare una lingua comune, forse prova semplicemente a imparare qualcosa di popolare tra i tuoi colleghi. Puoi provare a modificare qualche semplice progetto scritto in un framework. Avviare un progetto da zero in un framework che non conosci è un modo di apprendimento molto inefficace.

Ora, la tua vera domanda riguardava un progetto specifico e il porting a un framework. Per questo, la risposta sembra essere: dipende, e non possiamo davvero dirlo. Tuttavia, trasferire materiale su un framework che non conosci è quasi certamente una cattiva idea, dato che non puoi nemmeno sapere se ha senso . Quindi, sembra che dovresti lasciarlo così com'è, e rivisitare questa decisione ad un certo punto, una volta che conosci e ti piace un quadro. Altre risposte contengono buoni punti su ciò che dovresti cercare quando prendi questa decisione.

Questo articolo ha ricevuto molta attenzione su Hacker News 2,5 anni fa: "Scrivere codice che è facile da eliminare, non facile da estendere. Questa prospettiva può o non può aiutarti ad affrontare il tuo codice attuale, ma in futuro potrebbe aiutare a prevenire la frustrazione derivante dal perfezionismo / over-engineering.

If we see ‘lines of code’ as ‘lines spent’, then when we delete lines of code, we are lowering the cost of maintenance. Instead of building re-usable software, we should try to build disposable software.

I don’t need to tell you that deleting code is more fun than writing it.

(sottolineatura mia)

Il thread dell'articolo su Hacker News potrebbe anche valere la pena di essere letto.

Per quanto riguarda la sua futura dimostrazione e applicazione di scale & principi quadro, è un compito difficile da svolgere da solo, probabilmente non mi preoccuperei, ma se è necessario:

Mantieni pulito il tuo codice, segui i principi SOLIDI, ASCIUTTI > google.

Applicare un load balancer il prima possibile.

Alza almeno due server web, gestisci gli scenari di bilanciamento del carico nel codice.

E per 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, vedi: link Il punto è valido, ma 10gb è banale come soggetto di prova.