Non spieghi MVC.

Quello che fai è spiegare che si tratta di una ristrutturazione del codice base.

Una ristrutturazione che semplifica la base di codice e consente quindi agli sviluppatori di apportare modifiche più rapide e migliori ai bug report e alle richieste di funzionalità, con meno errori.

Non hanno bisogno di conoscere i dettagli tecnici, solo il motivo per cui è stato fatto, ciò che è stato ottenuto facendo ciò e il modo in cui i benefici aziendali.

In altre parole: parla loro la loro lingua.

Pur approvando l'essenza della risposta di Oded , dovresti spiegare i progetti tecnici ai manager aziendali in "loro lingua, "Mi preoccupo molto" non hanno bisogno di conoscere i dettagli tecnici, solo perché è stato fatto. "

Se ti trovi in un progetto o in una riunione di revisione degli investimenti con capi dipartimento e dichiari "questo è ciò che stiamo facendo", potrebbero voler chiedere "Umm ... perché? Sembra un grande investimento di tempo ed energia Potresti darci un po 'di più in comprensione di quello che stai facendo e perché? " Sembra una domanda eminentemente ragionevole. Non vuoi essere scoperto in una posizione di "Beh ... è complicato". oppure "No, non posso davvero spiegarlo". o "Non ti preoccupare per questo". Più alto è il personale per il quale si sta facendo la revisione del progetto, meno è probabile che lascino volare "è solo roba che non riesco a spiegare bene". Meglio se puoi andare almeno ad un livello più profondo per far sentire gli altri a tuo agio che 1) sai cosa stai facendo e 2) questo è davvero uno sforzo / investimento ragionevolmente considerato.

Quindi, avere uno schizzo di MVC nella tasca posteriore, pronto per partire. Qualcosa come:

"È un po 'tecnico, ma ... MVC divide il codice in Modelli (responsabili dei dati di base e della logica aziendale), Views (che visualizza i dati) e Controller (che gestiscono le interazioni e gli aggiornamenti degli utenti). architettura collaudata - probabilmente il "design pattern" di maggior successo dell'ingegneria del software. So che potrebbe sembrare come "solo un impianto idraulico", ma per gestire tutte le richieste in arrivo, abbiamo bisogno di una base più solida. Questo ci metterà sulla giusta strada per creare nuove funzionalità e risolvere i bug più velocemente. "

Anche se non capiscono perfettamente MVC alla fine di esso, e anche se si dovesse semplificare eccessivamente per renderlo comprensibile ("rompere alcune uova per fare una frittata"), scommetto che lo troverete molto più comodo avere una spiegazione pronta che dover dire "non posso spiegarlo" o "non sei qualificato per capirlo" ai senior manager.

in order to improve flexibility of making changes to the software

I manager sono interessati al risultato finale. Meno sono tecnici e meno è probabile che siano interessati a come ci si arriva. MVC è molto comune, popolare e provato.

Quando le richieste di modifica vengono apportate in futuro, puoi far sapere al management che possono essere rese più semplici e veloci. A tutti piace sentire questo.

È una strategia comune, quindi assumere nuovi sviluppatori non dovrebbe presentare un problema. In effetti, puoi attirare sviluppatori migliori che sono forti sostenitori.

Tutto ciò sarà molto difficile se ci sono molti problemi urgenti in questo particolare progetto. Potrebbero non voler fare un passo indietro in modo da poter fare due passi avanti. Sulla soluzione potrebbe essere attendere o implementare in parti più piccole.

• Modello - Fili / elettricità
• Visualizza - Light Fixture
• Controller - Interruttore luce

Relativamente facile da spegnere i componenti (lampada, interruttore / dimmer). Forse non tanto il cablaggio, ma può ancora essere fatto senza influenzare altri componenti. Ognuno dovrebbe essere in grado di visualizzare quello nel loro capo, anche i tipi di marketing / vendite. (Separazione chiara, ecc.)

Ora dì al tuo capo / collaboratori che nella nostra applicazione / sistema l'interruttore è incorporato all'interno del corpo illuminante e la lampada è avvolta in un filo di rame. Ora immagina di provare ad aggiornare la lampada, l'interruttore o il cavo. Molto costoso, impatto su altri componenti molto alto e forse pericoloso da fare senza rompere qualcos'altro.

MVC applica un pattern al codice base che trasforma il caos confuso (ma funzionante) in qualcosa in cui le modifiche possono accadere più velocemente e più facilmente con meno errori.

Un modo semplice per capire MVC: il modello è i dati , la vista è la finestra sullo schermo e > controller è la colla tra i due .

The best rubric ever: "We need SMART Models, THIN Controllers, and DUMB Views"

Come per altri modelli di progettazione software, MVC esprime il " nucleo della soluzione " a un problema consentendo al tempo stesso di adattarlo a ciascun sistema. È meglio visto come un concetto invece di una specifica implementazione. Ci sono molte implementazioni del concetto.

Tutte le varianti MVC utilizzano la stessa divisione di componenti, ma di solito differiscono nel modo in cui tali componenti interagiscono.

Forthoseofyouwhoarenotaware,MVCwasoriginallydescribedintermsofadesignpatternforusewithSmalltalkbyTrygveReenskaugin1979.Hispaperwaspublishedunderthetitle"Applications Programming in Smalltalk-80: How to use Model-View-Controller", and paved the groundwork for most future MVC implementations.

Sono a metà strada - sono d'accordo con Oded - sto imparando a convincere i tuoi colleghi e manager non tecnici che quello che stai facendo è importante e utile, senza spiegare i dettagli grintosi, è un'abilità necessaria che sarebbe saggio sviluppare.

Tuttavia, credo che avere la capacità di spiegare concetti complessi in termini semplici ci aiuti effettivamente - un problema che spesso i manager non tecnici hanno è che, poiché hanno difficoltà a capire esattamente di cosa si tratta la gente di tecnologia sta facendo, hanno la tendenza a diffidare di loro. È solo la natura umana: è più facile credere che qualcosa che non capisci sia inutile o sbagliato di quanto non lo sia. Pertanto, se puoi rendere i concetti facili da capire a piacimento, puoi utilizzarli ogni volta che ne hai bisogno e, nel tempo, i tuoi manager non tecnici apprenderanno che possono capire se vogliono - non ne fai uno su di loro - stai solo risparmiando loro i dettagli per la loro sanità mentale. Si fideranno di te di più.

A parte questo, rispondiamo alla domanda:

Trovo utile utilizzare le analogie che gli uomini d'affari comprendono. Per MVC, lo descrivo come un business.

• I modelli sono responsabili della logica e dei dati aziendali: sono le cose che definiscono ciò che fa il programma e i dettagli di come lo fa. Se il programma fosse un business, i modelli sarebbero i magazzini, le fabbriche, i lavoratori e le attrezzature capitali. Sarebbero anche i manager di livello inferiore che assicurano che le regole siano seguite e che la politica sia applicata.
• Viste sono il livello di presentazione: mostrano agli utenti cosa sta succedendo nel sistema e forniscono un mezzo per interagire con il programma. Se il nostro programma fosse una società, le visualizzazioni sarebbero come il pavimento dello showroom, lo stand di vendita alla convention commerciale o i rappresentanti di vendita. Visualizzano opzioni, forniscono informazioni e feedback user-friendly e rispondono alle richieste della società.
• I controller sono il livello di coordinamento: assicurano che le informazioni arrivino dai modelli alle viste e viceversa e che tutto funzioni insieme per svolgere il loro lavoro. Se il programma fosse una società, i controllori sarebbero la gestione di medio e alto livello. Non sono troppo coinvolti nei dettagli, ma si assicurano che le persone giuste abbiano gli strumenti giusti per svolgere il loro lavoro e approvano o negano le decisioni ad alto livello. Forniscono la direzione generale in modo che le cose possano lavorare insieme.

Il vantaggio di spiegarlo con questa analogia è che un buon manager vedrà la saggezza nel separare le preoccupazioni in questo modo, e potrebbe decidere che dovrebbero essere più controllati, e non essere troppo coinvolti nei dettagli in futuro!

Spero che risponda al "cosa", il "perché" è anche facile con questa analogia:

Immagina un'azienda ideale, in cui ogni dipartimento è responsabile di una serie di compiti e sa che avrà sempre le risorse di cui ha bisogno senza doversi preoccupare di ciò che fanno gli altri. Un rappresentante di vendita trova un cliente, riceve l'ordine, lo restituisce alla direzione che lo approva, e quindi lo inoltra al magazzino / produzione / ingegneria per l'adempimento. Il feedback è diretto - nessun altro ha bisogno di essere coinvolto a meno che non ci sia un problema. È un buon design MVC: ogni parte ha un lavoro e non deve preoccuparsi di altre parti. In questo modo, è facile cambiare se necessario. In un design non MVC, le responsabilità non sono chiare. Il rappresentante di vendita può provare a modificare il prodotto quando il cliente richiede qualcosa di diverso. Oppure potrebbero dare prezzi diversi a seconda di come si sono sentiti quel giorno. L'amministratore delegato potrebbe trovarsi sul pavimento della fabbrica a pasticciare con la linea di produzione, quando dovrebbe essere preoccupato di come ottenere una catena di approvvigionamento più affidabile. Gli addetti al magazzino potrebbero essere fuori dal piano di vendita a parlare con i clienti quando devono soddisfare gli ordini già effettuati.

In altre parole, il buon design MVC consente a ciascuna parte di concentrarsi su una cosa, in modo che possa farlo correttamente, proprio come una società ben organizzata.

** Disclaimer: se la tua azienda è mal organizzata, potrebbe essere offesa da questo. In tal caso, avrai bisogno di un'altra analogia. Potrebbe anche essere necessario un lavoro diverso.

I vantaggi di MVC riguardano principalmente la separazione delle preoccupazioni:

Permette alle persone di concentrarsi su ciò che sanno fare meglio.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

Riduce i costi perché i sistemi intrecciati richiedono che il personale sia esperto in tutte queste aree o è più probabile che si verifichino problemi quando un cambiamento in un'area influisce sugli altri.

Fornire esempi reali di architetture MVC: telefoni cellulari, telefoni desktop, Skype, ecc. Cambiare la vista (tipo di tastiera, altoparlanti, microfoni) non influenza il modello (il segnale audio), il controller è il circuito nel telefono che traduce le onde sonore in segnali audio.

Direi loro che MVC separa le mie preoccupazioni.

La mia prima preoccupazione è la logica del codice: cosa faccio dietro le quinte per fare in modo che il sito web esegua le azioni che vogliono.

La mia seconda preoccupazione è la logica aziendale: ciò che (l'utente) vuole che l'applicazione faccia.

La mia terza preoccupazione è come appare il sito: la pagina che visitano fa ciò che vuole.

(Non dirò loro la prossima parte) Quindi, in ordine, le mie spiegazioni erano per il modello, il controller e la vista.

Spiega i vantaggi

Spiegherei MVC in termini di vantaggi aziendali. I tuoi manager saranno in grado di capirlo e saliranno a bordo se i vantaggi sono convincenti.

MVC ti consente di suddividere la tua applicazione in unità sensibili, ognuna delle quali esiste indipendentemente dalle altre. Ottieni codice pulito, manutenibile, verificabile e potenzialmente riutilizzo del codice tra i sistemi.

Il modello

Ogni modello incapsula un singolo tipo di informazioni aziendali, ad esempio un record cliente o un prodotto, insieme a tutte le logiche aziendali correlate.

La separazione di questa funzionalità ti consente di testare facilmente la logica di business in isolamento da altre parti della tua applicazione.

Puoi anche estendere facilmente l'applicazione aggiungendo altri modelli, è molto modulare e pulita.

Ogni modello in teoria può esistere indipendentemente dagli altri. Potresti considerare di imporlo utilizzando gli oggetti di servizio per gestire le relazioni tra i modelli. Puoi sostituire i modelli senza influire sul resto del sistema.

La vista

Separare la vista consente di aggiornare facilmente il front end senza rompere il backend sottostante.

Puoi dare il tuo front-end a un altro sviluppatore senza dover necessariamente accedere a tutto il sistema.

Sei anche libero di creare front-end alternativi che funzionano con il sistema esistente. Puoi mostrare i tuoi dati come un'app mobile, un'API, un PDF o un foglio di calcolo Excel. Puoi farlo senza hacking nel resto del sistema. Hai meno probabilità di rompere le cose per errore. È possibile creare prontamente punti di integrazione per i sistemi esistenti in cui connettersi.

Il controller

Il controller collega i modelli alla vista. Mantiene tutto separato. Puoi collegare molto facilmente una vista diversa. Se cambi il tuo codice modello, la vista non ha nemmeno bisogno di sapere.

Altri vantaggi

È un modello comune. Altri sviluppatori saranno in grado di capire il tuo codice e lavorarci sopra. Se torni al tuo codice anni dopo, probabilmente sarai in grado di capirlo e apportare modifiche. Il tuo codice avrà meno probabilità di diventare un altro mal di testa legacy per uno sviluppatore futuro.

Perché tutto ha un posto, è molto più facile produrre codice pulito. Il rischio di spaghettificazione è drasticamente ridotto (anche se non eliminato). Il tuo codice diventa manutenibile.

Poiché tutto è modulare, puoi testarne alcune parti isolate. Il tuo codice è testabile e meno probabilità di ospitare bug o buchi di sicurezza. Gli aggiornamenti futuri saranno molto più semplici in quanto sarà possibile testare facilmente l'intero sistema.