Programmazione orientata agli oggetti in WordPress: analisi, parte 2
Nel primo post di questa serie, ho parlato di come volevo affrontare un’introduzione alla programmazione orientata agli oggetti nel contesto di WordPress.
Ci sono alcune grandi risorse per la programmazione orientata agli oggetti, ma possono usare esempi inventati o possono spostarsi troppo velocemente per coloro che stanno solo cercando di iniziare.
Nel tentativo di evitare che ciò accada, penso che parlare di OOP in WordPress ci ancori a solide fondamenta e utilizzare esempi pratici sarà sempre meglio che usare esempi generici difficili da tradurre nel dominio in cui stiamo lavorando.
Per coloro che devono ancora aderire o che non hanno ancora raggiunto, il primo post tocca i seguenti argomenti:
- Analisi orientata agli oggetti,
- Determinazione dei must-have e dei piacevoli da avere,
- E perché è difficile?
Ed è qui che riprenderà questo post.
Programmazione orientata agli oggetti: più analisi
Lo so: quando si tratta di scrivere codice, la prima cosa che vogliamo fare è sederci e iniziare a scrivere codice. Cosa c’è di meglio che far succedere qualcosa sullo schermo?
E quando lo fai per te stesso, non è un grosso problema, ma quando scrivi il codice sarà:
- gestito da un team di persone,
- in vendita,
- o per tutto quanto sopra
Fa la differenza. Perché una buona analisi può portare a una buona organizzazione che può portare a una buona manutenibilità.
Altrimenti, stai mettendo insieme qualcosa da spedire e non si adatterà bene con le versioni future. E questo è qualcosa di cui parleremo in modo approfondito per tutta la serie.
Ma qual è un buon modo per riassumere facendo una buona analisi in tre semplici passaggi? Questa non è necessariamente una risposta a prova di proiettile, ma è ciò che cerchiamo di fare ogni volta che lavoriamo su progetti:
- Assicurati che il codice faccia ciò che il cliente vuole,
- Applicare buone pratiche orientate agli oggetti,
- Obiettivo per un design manutenibile.
Tutto questo suona bene in teoria, ma senza approfondire ciascuno di essi, come facciamo a sapere se lo stiamo facendo bene? In altre parole, è qui che troviamo spesso libri, risorse e altre utilità che rendono difficile diventare un migliore programmatore orientato agli oggetti.
Questo è esattamente ciò che voglio evitare, quindi approfondirò ogni punto un po’ più a fondo.
1 Cosa vuole il cliente
Questo può essere spesso uno degli aspetti più impegnativi dell’intero progetto perché noi, come sviluppatori, parliamo una lingua diversa dal cliente.
Non solo useranno spesso una terminologia che non useremmo, ma spesso pensano che quello che vogliono sullo schermo sia il modo migliore per farlo. Questo fa sembrare davvero condiscendente e sbagliato cercare di correggerli, vero?
Voglio dire, immagina di provare a dire a qualcuno che sai cosa vuoi, e lui ti corregge. Gestire questo con cura è qualcosa che può ottenere una grande equità relazionale, ma ci vuole un certo lasso di tempo per "scavare" ciò che vogliono veramente rispetto a ciò che dicono di volere.
E ci addentreremo maggiormente in questo in un prossimo post.
2 Pratiche orientate agli oggetti
Ovviamente, questo deriva dal sapere quali sono le buone pratiche orientate agli oggetti ed è qualcosa che ho intenzione di coprire.
Molte persone diranno cose usando cose come:
- i SOLID principi,
- eredità,
- codice DRY,
- iniezione di dipendenza,
- e così via
Sono tutti importanti per seguire buone pratiche orientate agli oggetti.
E forse questa non è una cosa popolare da dire, ma sono della mentalità che cercare di usare tutte le cose tutto il tempo non è sempre una buona idea. Cioè, sicuramente non vuoi che il codice venga ripetuto in tutta la tua base di codice, ma devi avere ereditarietà nella tua base di codice?
No.
Ci sono momenti in cui i principi dovrebbero essere applicati e in cui possono essere ignorati. Ma conoscerli, quando sono utilizzati al meglio e quando usarli sono la chiave per utilizzare correttamente tali pratiche.
3 Design manutenibile
In poche parole, l’applicazione di schemi e principi al tuo software durante la scrittura è ciò che renderà molto più facile l’uso e la manutenzione in futuro.
Ma, ancora una volta, questo dipende da:
- comprendere appieno ciò che il cliente desidera,
- sapere quali pratiche esistono, quando applicarle e quando evitarle.
E per fare tutto quanto sopra, dobbiamo guardare ogni punto all’interno del suo contesto prima di fare un passo indietro per guardare al quadro più ampio.
Cosa vuole il cliente?
Ovviamente, c’è molto terreno da coprire quando si tratta dei tre punti precedenti. Ma se vuoi scrivere un buon software gestibile all’interno dell’economia di WordPress, è importante capire come tutto questo si adatta insieme.
Quindi, piuttosto che saltare avanti nella scrittura di codice o andare avanti nel lavorare su un progetto, la prossima cosa che esamineremo è come prendere ciò che il cliente vuole e quindi decifrarlo in una serie di requisiti che ci consentano di creare un dichiarazione di lavoro.
In questo modo, alla fine avremo un documento di lavoro su ciò che il cliente desidera e ciò che costruiremo, e saremo tutti sulla stessa pagina.