Convincenti colleghi di utilizzare MVC

Question

Sto per iniziare a lavorare su un nuovo progetto in un lavoro un po 'nuovo, e ho incontrato un po' di problemi. Non sono grandi fan di MVC.

Il motivo per cui questo mi infastidisce è che affermano che attualmente stanno utilizzando Zend Framework quando in realtà non lo sono. Stanno usando a malapena le classi del modello DB, e questo è tutto. Nessun MVC, nessuna estensione delle classi Zend per raggiungere i loro obiettivi.

L'ultimo progetto su cui ho lavorato ha utilizzato molto Zend. Una volta terminato il progetto, ci è rimasto un bel framework MVC. Controllori molto puliti, la maggior parte della logica pesante era nei modelli a cui apparteneva, e un bel sistema di gateway di modelli per l'avvio. Passare da quello al codice sphagetti con SQL scritto a mano è una specie di shock.

Quindi, vi chiedo, comunità StackOverflow. Come convinco i miei colleghi a passare a un framework MVC? Ho la sensazione che abbiano paura di usare MVC perché significherebbe una curva di apprendimento per i due programmatori affermati (è un piccolo avvio). Stavo pensando di fare una copia del progetto corrente usando MVC e tutta la bontà di Zend in un repository SVN separato (nel mio tempo libero), e mostrarlo a loro in poche settimane per vedere cosa pensano.

Qualche idea su come convertire i colleghi in MVC?

Answer 1

C'è un buon post che dovresti leggere "qual è la cosa più importante che non hanno insegnato a scuola". Uno di questi sono le abilità sociali. Mi sembra che tu stia cadendo sul tuo viso qui.

In primo luogo, sei il principiante della squadra. Chi sei tu per dire loro cosa fare o come farlo? Se riscrivi il codice, se è peggio sei un idiota. Se ci riesci, sei un asino. In entrambi i casi, sei la risata o mentre esci.

Quello che devi fare è risolvere il seguente problema: "Come posso imparare ad inserirmi in questo team, aiutare il progetto ad avere successo e contribuire?" Da questa prospettiva, mostrare agli altri che conosci più di loro e che sono idioti non è la soluzione.

Amplia la tua prospettiva: il tuo problema qui è probabilmente del 10% tecnico, il 40% apprende come funzionare come parte di un team, il 30% di comunicazione sociale e il 20%.

Dal punto di vista del progetto, cosa pensi sia più importante? Cosa pensi che il progetto sarà completato in tempo?

a) Tutti lavorano insieme in modo produttivo e armonioso nel quadro sbagliato. b) La squadra si è divisa con 1 persona che lavora in 1 struttura, l'altra 2 che lo ignora e tutti si fanno l'un l'altro male al manager/alla gestione del team.

Hai parlato il tuo pezzo, ora stai zitto e fai il lavoro che ti dicono di fare, fallo bene, fallo velocemente e, se vuoi, metti dentro tanto MVC (la tua parte) quanto tu vuoi che tu non dica a nessun altro come scrivere il loro codice :) Se sei così bravo, fai in modo che sia più veloce, quindi chiedi loro altro lavoro da fare e ripeti i passaggi precedenti.

Una volta guadagnato il rispetto e, idealmente, l'amicizia, prova a sollevare di nuovo l'argomento.

Answer 2

Se si tratta di una "piccola startup" senza personale tecnico nello staff, probabilmente non si otterrà più tempo dalla direzione per rielaborare la maggior parte delle cose già finite. "Time to market" è la parola chiave che possono usare come spiegazione -> "Falla funzionare prima, veloce".

Non mi piace neanche, ma questa potrebbe essere la vostra realtà.

Answer 3

Si potrebbe provare e ottenere una comprensione delle loro priorità.

Se vogliono portare a termine il lavoro in fretta, esiste un motivo per cui le strutture sono in grado di svolgere gran parte del lavoro di stagnino, risparmiando il tempo che dovresti dedicare a scriverlo.

Se desiderano codice gestibile, ci sono ovvi vantaggi nell'avere codice disposto in una struttura regolare, in schemi di progettazione regolari.

Se desiderano codice verificabile (non conosco troppo la testabilità in PHP) sicuramente estendere le classi in modelli noti porta maggiore testabilità.

Se si tratta solo di incompetenza, l'istruzione è l'unica risposta (e quale modo migliore per farlo rispetto all'utilizzo di una struttura ben progettata?).

Answer 4

Cercare di convincerli a utilizzare il modello preferito non è probabile che funzioni, soprattutto perché, molto probabilmente, non si vedono gli stessi vantaggi che si ottengono.

I piccoli passi funzionano meglio. Non uscire e riscrivere 2 settimane di lavoro in un giorno, ti farai solo sembrare un culo.

Invece, fai solo ciò che è meglio, pur rimanendo in stretto contatto con i tuoi colleghi. A meno che non credano di sapere tutto (nel qual caso, semplicemente non c'è speranza per te), prima o poi, chiederanno il tuo consiglio in merito. Basta spiegare loro come e, cosa ancora più importante, perché così, risolverai quel particolare problema.

Cerca di non imbattersi in un tuttuno, invece, prepara sempre argomenti. E non aspettarti il ​​successo in poche settimane. Ci vuole tempo, ma se i tuoi colleghi valgono il loro lavoro, scopriranno i benefici alla fine.

Naturalmente, se hanno argomenti molto specifici contro l'utilizzo di qualsiasi modello, o MVC in particolare, dovrai solo onorare questo sentimento.

Answer 5

Fondamentalmente, quello che vuoi fare è introdurre un cambiamento piuttosto profondo nel tuo ambiente di lavoro. Questa è una cosa molto difficile da fare anche per le persone con eccellenti capacità sociali. Dovrai fare piccoli passi che si verificano per un lungo periodo di tempo, essere acutamente consapevoli di ego, convincere le persone e infine concretizzare le tue promesse che i cambiamenti saranno per il meglio.

Ho sentito un podcast/intervista piuttosto piacevole su questo argomento non molto tempo fa: link. Un sacco di informazioni utili in là. La cosa più scioccante è che molte persone semplicemente NON AMANO cambiare e NON LO FANNO. Devi renderli parte del processo e farli investire.

Answer 6

Questa è una delle "cose ​​che non dovresti mai fare".

http://www.joelonsoftware.com/articles/fog0000000069.html

si sta muovendo per MVC il miglior uso delle risorse in questo momento?

Non è possibile contare le ore nel proprio tempo come "libere" perché questo è un imbroglio. Puoi fare qualsiasi cosa in 0 ore di tempo in azienda se tutto è stato fatto nel tuo tempo libero - riscriverlo RoR, scriverlo in Lisp, ecc.

Quindi, diciamo che ci vorranno N ore per scriverlo . Hai anche aggiunto le ore richieste al test di regressione per assicurarti che funzioni perfettamente? No? quindi aggiungere altre 2 ore. Che ne dici di familiarizzare gli altri sviluppatori con il nuovo codice? No?quindi aggiungere altre 2 ore.

Quindi, siamo probabilmente fino a 5 N ora. Quali sono le altre cose che devono essere fatte prima della tua prossima data di spedizione? Riesci anche ad adattarti a queste 5 ore in più e ad effettuare comunque quella data? Se sì, quali sono gli articoli per la data della nave dopo? Gli articoli che potrebbero essere completati in 5 ore vale più della riscrittura in MVC?

Quali saranno i vantaggi, in termini di tempo e manutenzione per la riscrittura?

Probabilmente non stai pensando a questo da una prospettiva di gestione del progetto. Da quella prospettiva, personalmente dubito che una riscrittura sia il miglior uso del tuo tempo.

Answer 7

Probabilmente non sarai in grado di convincerli, ma hai il diritto di esprimere la tua opinione - dopotutto fai parte del team. È irrilevante che tu sia nuovo o no.