Come spiegare al mio manager l'importanza della separazione delle preoccupazioni?

Question

Come spiegare al mio manager l'importanza della separazione delle preoccupazioni?

#1 da (2 voti)
#2 da (2 voti)

0

Sono un programmatore web estremamente novizio che lavora in un sito web di costruzione di negozi per 2 persone e stiamo scrivendo da zero un semplice sistema di template per siti web in PHP. Il mio manager è completamente autodidatta. Ha insistito sul fatto che abbiamo inserito il nostro codice HTML direttamente in variabili, mescolando il nostro codice di back-end con quello di front end.

$foo = "<html>
        <body>
            <div class=\"bar\">" . $bar . "</div>
        </body>
        </html>";

echo $foo;

Afferma che è più facile lavorare in questo modo. Ho insistito sul fatto che dovremmo almeno usare i tag PHP nel nostro codice HTML, piuttosto che l'HTML nel PHP.

<html>
<body>
    <div class="bar"><?php echo $bar; ?></div>
</body>
</html>

Mi sembra che questo sia un vero rompicoglioni da leggere e sembra proprio un casino. Penso che sarebbe molto più facile separare la logica dalla presentazione, ma è certo che la sua strada è la migliore. Come posso spiegare l'importanza di questo in modo che capisca? Non riesco a metterlo in parole, esattamente.

EDIT: Pensi che potreste lasciare un commento quando non mi voti? Non ho idea di come risolvere la mia domanda se hai appena votato e parti senza suggerire miglioramenti.

html php front-end separation-of-concerns

posta ohiock 15.11.2013 - 02:39

fonte

2 risposte

2

Mi avvicinerei a questo come segue: hai due problemi separati, la vista e la logica dell'applicazione. Ricordiamoci semplicemente che, dal momento che il codice di visualizzazione e il codice dell'applicazione sono tutti mescolati insieme, le modifiche alla vista potrebbero (suggerire: a un certo punto) di infrangere la logica dell'applicazione. Allo stesso modo, le modifiche alla logica dell'applicazione potrebbero rovinare la vista. Questa è probabilmente la migliore motivazione per la separazione delle preoccupazioni: l'isolamento del codice.

Un'altra possibile argomentazione è che, ad un certo punto, le applicazioni web che stai sviluppando potrebbero necessitare di ulteriori front-end (pensa sito mobile personalizzato, interfaccia REST / XML, ecc.) Con logica di applicazione e codice di visualizzazione tutti raggruppati (uniti e insieme), aggiungendo le ulteriori tecnologie di visualizzazione diventa un incubo.

Infine, come intende testare il codice dell'applicazione separato dalla vista (o vede la necessità di test delle unità)? Con il codice separato, il test diventa molto più semplice. Questo è tutto ciò che posso pensare in cima alla mia testa. Spero che tutto funzioni per te.

risposta data 15.11.2013 - 04:30

fonte

Leggi altre domande sui tag html php front-end separation-of-concerns

Quando devono essere refactati i overload di metodo? Scegliere le risorse giuste [duplicare]

score 2 · Accepted Answer

I motivi:

Il programmatore e il programmatore PHP non possono lavorare contemporaneamente alle rispettive preoccupazioni. Ciò significa un alto potenziale per gli scenari in cui una persona dovrà aspettare che l'altro venga eseguito o se si sta effettivamente utilizzando il controllo della versione in un conflitto di merge che richiede inutilmente tempo, il che costa $$$ s
Limita le opzioni per un approccio di etichettatura bianca in cui i front-end simili vengono offerti principalmente dallo stesso back-end. Ciò potrebbe inaspettatamente ridurre il valore dell'app a un determinato cliente che decide di dividere il proprio brand in una decisione di non utilizzarla nuovamente che costa $ s
Allo stesso modo potresti scoprire che il tuo markup è quasi perfetto per un altro progetto che richiede solo nuovi CSS e alcuni ritocchi minori e trova sostituti ma orsi brutti, è perfettamente unito e intrecciato con il tuo codice lato server piuttosto che solo nei punti in cui il server aggiunge effettivamente conent in modo da non avere quell'opzione che ti costa più tempo che, come sappiamo, si trasforma in $$$ s
Vola di fronte a una convenzione quasi universale, il che significa che anche se sei sicuro di avere ragione e tutti gli altri hanno torto, penseranno ancora che la tua azienda sia inetta quando sono sviluppatori o gli sviluppatori futuri vedono quel codice che ti costa $$$ s
Sembra terribile. Sul lato client, dove è possibile avere diverse lingue e il padrone sa quante cose stupide dalle dipendenze di template e down-compiling / help-you-not-suck-at-css, le teniamo separate per leggibilità / sanità mentale. Fermati nella chat room di JavaScript su SE e chiedi alla gente quanti ne hanno ADD. Facciamo tutti impazzire. Tenerlo pulito in modo che le nostre teste non esplodano. Altrimenti ci vorrebbe più tempo per ricordare quali sono le 3-5 lingue che stavamo cercando di elaborare simultaneamente e capire cosa stiamo guardando, il che significa che ci impiega più tempo a costare $ s
Non sei solo tra gli sviluppatori di interfacce utente. Pochissimi di noi prenderebbero in considerazione il fatto che non ci siano grossi problemi. Mi incazzo quando aprire e chiudere i tag non si trovano nello stesso dannato modello. Più difficile attirare e mantenere un talento entusiasta quando decidi che la tua strada è meglio della convenzione ampiamente riconosciuta che sì, costa davvero di più $ s

Nota il modello. Metti in relazione le cose che ti interessano di come si traducono in costi. Probabilmente non gliene frega niente se si è opposto alla conoscenza accidentale delle migliori pratiche come ha nel processo di apprendimento su come costruire un sito web con PHP, ma di solito è il migliore / unico modo se ce n'è uno.