Strati di confusione (astrazione)

Question

Strati di confusione (astrazione)

#1 da (7 voti)

1

Sono stato assegnato a un progetto in cui il prodotto finale è un sito Web come comunità musicale. Quindi è il caricamento di musica, la condivisione tra gli altri utenti, l'ascolto di musica dal sito Web e così via. È un progetto che non supererà i confini di questa nazione, questo è certo, quindi la parte di scaling non è davvero interessante.

Al momento abbiamo ~ 12.000 utenti in totale, quindi quasi nulla.

Detto questo, per me è un prodotto davvero semplice e diretto. Ma sappiamo tutti che il semplice può essere rovinato da un sacco di cose.

Il mio problema con il codebase sono i molti livelli oscuri. Iniziamo caricando una "shell" e da lì facciamo così:

HTML / AngularJs - > TypeScript - > Breeze - > WebApi / OData - > Entity Framwork

Quindi, in realtà, la mia domanda è se sono solo io o se ho ragione nella mia mente quando penso che questo sia totalmente sovradimensionato. E qualcun altro ha visto un'architettura come questa e sei d'accordo sul fatto che tagliare l'astrazione di dattiloscritto + brezza sarebbe il modo di ottimizzare l'architettura?

Dopo aver visto qualcosa di simile ho perso fiducia in TypeScript, perché è davvero difficile per me non vederlo solo un'astrazione tra il collegamento di alcuni framework di frontend e qualche framework di backend, invece di "parlare insieme" con TypeScript nel mezzo.

architecture web-development web-applications asp.net front-end

posta frostings 17.03.2015 - 09:26

fonte

1 risposta

Leggi altre domande sui tag architecture web-development web-applications asp.net front-end

Laravel usando i modelli Che cosa devo fornire sotto GPL come sviluppatore di siti Web?

score 7 · Answer 1

È estremamente facile come programmatore iniziare a pensare che ogni progetto che incontri potrebbe e dovrebbe essere fatto migliore (leggi: riscritto) perché non corrisponde alla tua visione. Siamo stati tutti lì.

Guardi il codice e la tua mente si limita a "cosa c'è di sbagliato in questa" modalità, invece di concentrarsi su ciò che è giusto al riguardo.

Se inizi a strappare i componenti, quanto tempo perderai ? Tempo a cui sei stato assegnato a spendere per il compito effettivo.

Hai una garanzia che rimuove i componenti X o li sostituisci con la tecnologia Y aumenta le prestazioni, la scalabilità, la manutenibilità?

Mi sembra che un'applicazione web di questo tipo possa sicuramente trarre vantaggio dalla maggior parte, se non da tutte, delle componenti che sembra avere: O / RM, strategia di caching, strong tipizzazione, funzionalità REST, alcune funzionalità predisposte per il mobile,. ..
La domanda pertinente non è "dovrebbe questo progetto essere composto da componenti X, Y e Z, ma piuttosto: è stato scritto bene? Fa un uso corretto di tali componenti?

Non hai menzionato per quanto tempo sei stato e continuerai a lavorare su questo progetto, ma per me una riprogettazione architettonica o uno scambio di componenti dovrebbe essere l'ultima risorsa dopo aver esaminato attentamente l'applicazione, fatta la tua proverbiale casa (e questo preferibilmente richiede molto tempo e ricerche), mentre tende tristemente ad uscire con il vecchio, con il nuovo.

Quindi, alla fine, non dipende da noi decidere ma da te. Fai attenzione che se decidi di andare avanti e riprogettare / scambiare / riscrivere, lo fai per i giusti motivi .