Come convincere il mio capo a passare a OOP PHP? [chiuso]

Il tuo capo sta scrivendo il codice?

Se sì: devi essere in grado di gestire il fatto che non tutti i membri del tuo team sanno quanto te. La manutenibilità è la cosa più importante, e il codice che non può essere mantenuto dalla metà della squadra perché non capiscono che non andrà mai bene. Insegna le tecniche a tutti i membri del team e perché sono preziosi e alla fine li useranno.

Se No: il problema reale qui sta convincendo il tuo capo ad abbandonare le decisioni del team tecnico. I programmatori dovrebbero possedere il codice e dovrebbero avere la responsabilità di decidere quali norme applicare. Se ci sono requisiti tecnici, falli definire. ("Non utilizzare OOP" non è un requisito tecnico. "I clienti possono modificare i modelli" è.)

Prestazioni: le prestazioni dovrebbero essere misurate e le prestazioni inaccettabili dovrebbero essere corrette. "Questo costrutto di codice è più lento di quel costrutto di codice" non è una misura. (Voglio dire, se rallenta l'avvio del server di un decimo di secondo, a chi importa? D'altra parte, se rallenta il rendering della pagina di un decimo di secondo, potrebbe essere un grosso problema. p>     

Poiché la sua argomentazione è che le prestazioni sono influenzate da OOP, penso che dovresti iniziare dimostrando che ha torto. Non sarà troppo difficile fare un benchmark per dimostrare che la performance è la stessa o quasi la stessa quando usi OOP rispetto all'approccio procedurale.

Inoltre, l'ultima parte dell'argomento mi fa pensare che il tuo capo non sappia troppo sullo sviluppo in generale. Dal momento che non è un programmatore e non ha una solida esperienza nello sviluppo, sarebbe facile convincerlo che le cose che ha imparato da alcuni siti Web sconosciuti o da alcune conferenze che ha assistito nel 1998 sono semplicemente false o non più vere. A volte, può anche essere una buona idea inventare alcuni argomenti di fantasia, come:

We really must move to OOP quickly, since in PHP 6, it will be impossible to use procedural programming any longer.

Ovviamente, dovresti usare tali argomenti fantasiosi a tuo rischio e solo quando il tuo capo non sa nulla sull'argomento e se i suoi argomenti non sono dimostrati.

Esiste una linea guida nella tua azienda che ti obbliga a non utilizzare mai OOP in PHP?

• Se sì, beh, è un peccato. Spesso è difficile discutere delle linee guida, specialmente quando l'avversario dice che, in primo luogo, non dobbiamo discuterle perché sono qui per assicurare l'uniformità del codice base. Puoi ancora provare a convincere almeno i tuoi colleghi a iniziare a violare le linee guida, o provare a fare tutto il possibile per vedere rimossa questa linea guida.
• Se no, allora non vedo qual è il problema. Scrivi codice, decidi di usare OOP, lo usi. Se il tuo collega vuole riscrivere migliaia di righe di codice per rimuovere OOP, è libero di farlo.

Mostrare esempi del mondo (progetti di grandi dimensioni scritti da sviluppatori professionisti in cui viene effettivamente utilizzato OOP) può anche essere utile per convincere il tuo capo.

Infine, se il capo non ascolta nessuno dei tuoi argomenti tecnici, c'è l'ultimo:

I've done the estimate of the change you requested the last Friday. It will give us four weeks to do it, since the actual code is a mess and it's nearly impossible to find where to put what. Ah, FYI, if the source code was refactored correctly and if we used OOP from the beginning, it would take us only three days.

Abbastanza semplice - se non è OOP, non può trarre vantaggio da alcun framework moderno, né alcuna soluzione ORM.

L'alternativa è sviluppare quadri interni, che richiedono molto impegno e molta manutenzione.

Buona fortuna!

Per la maggior parte, avrai bisogno di avere una risposta per ciascuna delle preoccupazioni. Come con l'esempio di connessione al database, è possibile indicare che è possibile utilizzare lo stesso oggetto o persino consentire un'istanza dell'oggetto (cioè il controverso singleton). Dovrai discutere sul punto che OOP renderà il codice flessibile e più facile da mantenere. Anche più testabile, che rende più facile il refactoring.

Cerca di evitare di essere scontento a riguardo però. Poni domande sull'approccio e offri soluzioni OOP alternative. Sii educato però. Attaccare può causare il tuo capo sulla difensiva.

Hai mai lavorato in vendite di qualsiasi tipo? Se è così, sei mai stato addestrato a "superare le obiezioni" o comunque convincere il cliente che ciò che stavi vendendo è una buona cosa?

Lo stesso vale qui.

Raccogli le sue obiezioni e cerca i controsensi su di esso. Il tuo attuale metodo è effettivamente più veloce di OOP PHP? Probabilmente no, ma nel caso in cui lo sia, concentrati sui tempi di sviluppo più rapidi offerti da OOP. Ci vorrà troppo tempo per riscrivere il codebase? Probabilmente, se fatto in una volta, spiega così i benefici del refactoring nel tempo o i benefici a lungo termine di spendere un paio di settimane per farlo tutto in una volta.

Ricorda, stai vendendo qualcosa di "nuovo" al tuo capo, il che significa che non può essere buono come il familiare, deve essere migliore , e deve essere ovvio che è meglio.