Sviluppatori WordPress: inizia da qui!

Pubblicato: 2017-10-14

Benvenuto nella nostra guida introduttiva per gli sviluppatori di WordPress! Che tu lavori come libero professionista o come parte di un'agenzia di media. In questo articolo tratteremo una varietà di argomenti relativi allo sviluppo di WordPress insieme ad alcune delle risorse e degli strumenti disponibili.
Il testo è organizzato attorno alle diverse fasi che scorrono tra la generazione dell'idea e la spedizione. Parleremo di brainstorming, prototipazione, sviluppo e infine di implementazione. Tutto questo, nell'ambito dello sviluppo del prodotto. Crediamo che tra i primi sentori di un'idea e la sua esecuzione finale ci siano molte aree sottili. Alcuni sono lasciati indiscussi nel migliore dei casi e altri sono completamente inesplorati nel peggiore dei casi, nell'attuale letteratura di WordPress.

Se sei un cliente di Pressidium, puoi iniziare immediatamente a utilizzare gli strumenti che abbiamo costruito attorno alla nostra piattaforma, in modo da poter godere dei vantaggi di un alto livello di integrazione. Parleremo anche di cosa sono questi strumenti. Ricorda che questo è un documento attivo e dovrebbe essere trattato come tale.

Innanzitutto il nostro obiettivo è che questo documento sia utile per la tua pratica come sviluppatore di WordPress e, in secondo luogo, per mostrarti un paio di cose interessanti che abbiamo creato apposta per te.

Dall'idea alla realizzazione

Indipendentemente dal fatto che tu lavori su un nuovo prodotto o abbia intrapreso il lavoro del cliente, il processo di passaggio dall'idea alla distribuzione consiste in 4 fasi. Sebbene queste fasi siano discrete, si sovrappongono in modo significativo e non sono lineari. Ne parleremo più avanti nel testo:

Brainstorming ed elicitazione dei requisiti.
Prototipazione.
Sviluppo.
Distribuzione.

Il processo di brainstorming liberamente associativo viene utilizzato quando vuoi iniziare a costruire un prodotto, o un progetto e hai bisogno di idee. La raccolta dei requisiti, tuttavia, si verifica quando si ha il compito di costruire un progetto per un cliente o di concludere un'idea dopo una sessione di brainstorming. Puoi comunque impostare sessioni di brainstorming in seguito per risolvere problemi particolari, ma quelle sessioni saranno più vincolate.

I principi fondamentali del brainstorming sono due. Scegli la quantità e rimanda il giudizio per dopo. Abbiamo scritto in passato su come puoi facilitare una tale sessione, come costruire la giusta mentalità e alcuni strumenti originali per aiutarti.

Esigenze richieste

Esistono diverse metodologie utilizzate per ottenere i requisiti e tradizionalmente questo è sempre stato il lavoro di un analista aziendale. Sebbene sia responsabilità del cliente fornire informazioni sui requisiti del progetto, è necessario stabilire una comprensione condivisa per tutte le parti interessate. L'elicitazione dei requisiti è un processo diverso dalla raccolta dei requisiti. Si tratta più di far emergere le informazioni necessarie attraverso la partecipazione attiva. E si tratta meno di raccogliere passivamente in un documento ciò che il cliente ti sta dicendo e trasmetterlo al team di sviluppo.

A seconda dell'ambito e della natura del progetto, i casi d'uso sono un ottimo modo per acquisire funzionalità. I casi d'uso sono una tecnica utilizzata nei diagrammi UML come modo per descrivere le interazioni tra le parti interessate di un sistema e il sistema stesso. Poiché sono una raccolta di scenari scritti in un inglese semplice ma strutturato, non solo sono meno complicati, ma rappresentano un modo rapido ed efficiente per iniziare a discutere e disegnare le funzionalità del sistema.

Probabilmente dovrai impostare interviste strutturate con tutte le parti interessate se desideri acquisire i requisiti per prodotti complessi. Per questo, le storie degli utenti sono un modo perfetto per andare. Fanno parte della mentalità Agile e sono un modo informale per iniziare a parlare dei requisiti, al fine di costruire una comprensione condivisa. Brevi descrizioni delle funzionalità sono scritte in schede cartacee, di solito Post-It Notes, e vengono mescolate su una lavagna per creare narrazioni dei viaggi degli utenti. Le storie degli utenti vengono generate sul posto, partecipando, discutendo e manipolando le schede sulla lavagna. I dettagli vengono lentamente arricchiti e infine aggiunti come funzionalità nel backlog del prodotto. Jeff Patton ha scritto un eccellente libro sulla User Story Mapping che consigliamo vivamente se desideri saperne di più sull'argomento e iniziare a usarlo nei tuoi progetti.

Le storie degli utenti non sono una cosa statica che una volta creata viene dimenticata per sempre. Al contrario, sono una mappa dinamica, alla quale il team di sviluppo e prodotto può tornare ancora e ancora, man mano che segue la fase di prototipazione e il prodotto inizia a prendere forma.

L'importanza di un prototipo è rispondere alle domande. Sebbene esistano diverse metodologie di prototipazione, riteniamo che quella evolutiva sia la più adatta ai nostri scopi e quella che può essere adattata alle moderne pipeline di sviluppo software Agile. Nella metodologia del prototipo evolutivo, il processo è ciclico, in cui il prototipo diventa progressivamente più raffinato attraverso ogni ciclo.

Ogni iterazione del prototipo passa dalla fase di progettazione alla fase di sviluppo e valutazione. Fa emergere i primi problemi di progettazione e fornisce qualcosa di tangibile su cui le persone possono indicare e parlare di ciò che può essere migliorato. Le informazioni raccolte dalla fase di valutazione vengono utilizzate nella successiva iterazione del prototipo e il ciclo si ripete ancora una volta. Pertanto, il prototipo evolve lentamente verso il sistema finale fino a raggiungere la maturità come prodotto finito.

La prototipazione di solito avviene a ritmi di sviluppo rapidi e l'utilizzo di sistemi standard come Bedrock, Sage e Bootstrap può ridurre notevolmente i tempi di sviluppo. Sistemi come quelli sopra menzionati forniscono uno scheletro applicativo completo e la toolchain necessaria in modo da non dover ricominciare da zero ogni volta. I prototipi evolutivi non sono la stessa cosa dei prototipi usa e getta. Questi ultimi sono prototipi che vengono costruiti una sola volta come proof of concept e poi buttati via. Se dedichi molto tempo alla costruzione di un prototipo di e-commerce, perché non astrarre le funzionalità comuni e riutilizzarle in futuro invece di buttare via tutto e ricominciare da zero?

È qui che la clonazione del pressidio torna utile. Ti consente di clonare rapidamente un sito Web con un solo clic e iniziare a sviluppare. In questo modo puoi preparare più modelli di siti Web utilizzando boilerplate, precaricarli con i plug-in, i temi e la configurazione necessari e clonarli ogni volta che ne hai bisogno in un progetto. Puoi anche clonarli su un account Pressidium diverso, ad esempio su quello del tuo cliente, allo stesso modo. Non preoccuparti se i tuoi prototipi si trovano su un provider di hosting WordPress gestito diverso. Basta usare il nostro strumento Migrazione guidata e importarli nel tuo account Pressidium!

Non importa se sviluppi progetti WordPress da solo o collabori con altri sviluppatori e designer di WordPress, i due punti più importanti che contribuiscono alla sostenibilità del tuo mestiere a lungo termine sono i seguenti:

Praticare buone abitudini software.
E sapere cos'è tutto, dov'è e perché è lì.

Le procedure consigliate variano dal seguire costantemente una guida allo stile del software all'esercitazione sulla scrittura di codice pulito anziché intelligente e fino a scelte di progettazione di software e interfaccia utente di alto livello. Il secondo punto è semplicemente la documentazione, e le molte forme che può assumere all'interno di un progetto.

Seguire una guida allo stile del software è semplice. Studia le risorse ufficiali di WordPress.org sull'argomento e poi decidi quali linee guida hanno senso per te in modo da includerle nel tuo stile di codifica. Cambiare le abitudini è un processo lento e dovresti iniziare facendo piccoli cambiamenti all'inizio. In definitiva, avere una serie di linee guida a cui il tuo codice deve aderire, significa introdurre revisioni del codice a un certo punto.

Le revisioni del codice sono un modo sistematico di leggere ed esaminare il codice che cerca di eliminare gli errori, chiarire parti del codice che sono astruse e garantire che il codice aderisca a standard e convenzioni. È anche meglio essere fatto da qualcun altro nella tua squadra e non da te.

Preferire il codice pulito a quello intelligente è una "perla di saggezza" di sviluppo software che purtroppo può essere apprezzata solo dopo essere caduto nelle trappole del codice intelligente. Il punto è questo: sebbene in alcuni casi un codice intelligente possa farti guadagnare punti "hacker" e una pacca sulla spalla, e persino aumentare le prestazioni in alcuni casi, alla fine perdi a lungo termine. Il codice "hackish" e di difficile lettura diventerà incomprensibile in futuro. E potrebbe costarti quando devi risolvere un bug particolarmente sfuggente. Trovare l'equilibrio tra la scrittura di codice ottimizzato e pulito è qualcosa che dovrai scoprire da solo, ma è sempre meglio sbagliare sul lato pulito delle cose.

Inoltre, poiché le prestazioni dei siti WordPress dipendono fortemente dall'uso corretto della cache del browser, è importante sapere in che modo il provider di hosting WordPress gestito utilizza la memorizzazione nella cache. Il tuo codice poi lavorerà in sinergia con la tua piattaforma di hosting, così da avere le migliori prestazioni possibili. Tuttavia, tieni presente che misurare la velocità del tuo sito web in modo corretto non è così facile come si potrebbe pensare e contiene diversi trucchi!

Quindi, parlando di best practice di alto livello, la decisione che ha portato WordPress a disaccoppiare le sue funzionalità principali e fornire un'API REST potrebbe sicuramente essere considerata un esempio di tali pratiche. Questa decisione ha segnato il passaggio verso una nuova era, verso i sistemi di gestione dei contenuti programmatici e lo sviluppo di applicazioni WordPress "senza testa".

Abbiamo scritto una breve introduzione e un tutorial sull'API REST di WordPress e un modo semplice per iniziare ad armeggiare con esso utilizzando plug-in del browser come Postman.

Questa decisione di progettazione del software è stata ingannevolmente semplice ma potente. Uno sviluppatore WordPress può ora utilizzare WordPress per implementare applicazioni e funzionalità che superano di gran lunga quelle di siti Web o blog. Un esempio particolarmente azzeccato è il nostro prototipo Kanban.

Abbiamo utilizzato entità WordPress come categorie e post per modellare una scheda Kanban con attività, colonne e un flusso di valore. Abbiamo disegnato un'API Kanban Columns and Cards, che legava tutto insieme.

Documentazione

Si potrebbe sostenere che le migliori pratiche software sono favorevoli alla scrittura di una documentazione migliore, dai semplici commenti al codice, ai risultati del progetto e al culmine della copia del prodotto.

Non importa come la guardi, la documentazione è una risorsa.

Quando si parla di documentazione tecnica il linguaggio usato per iscritto è decisamente diverso da quello che usi quando comunichi quotidianamente, o da quello che usi al lavoro. Questa forma di scrittura è chiamata scrittura tecnica e non viene utilizzata solo nei computer o nell'ingegneria del software. Viene infatti utilizzato in tutte le professioni che necessitano di comunicare concetti tecnici a un pubblico specializzato, come diritto, medicina, aeronautica e così via. È un argomento importante e ci sono persino alcuni college che offrono certificazioni di scrittura tecnica. La sua ragion d'essere è comunicare le informazioni tecniche utilizzando un linguaggio chiaro e conciso. La voce attiva è preferita a quella passiva, con quest'ultima utilizzata nei casi in cui è necessario un testo descrittivo per spiegare i concetti.

Uno scrittore tecnico deve tenere a mente che il lettore è qualcuno, che è spesso frustrato mentre cerca una particolare informazione. Di conseguenza, la tua scrittura non deve ostacolare. Il suo obiettivo è rendere questo processo facile, diretto e persino divertente!

Anche se non è necessario avere una laurea o essere uno scrittore tecnico professionista, sapere come comunicare concetti in modo conciso e semplice è molto importante per la tua carriera di sviluppatore WordPress. Pertanto, ogni volta che devi scrivere documentazione per un plugin, un tema o un'API che hai creato (e di cui sei orgoglioso!) devi avere le basi in basso. Per questo motivo, abbiamo scritto una guida rapida per documentare i tuoi plugin e temi WordPress, che copre anche i 5 principi di base della scrittura tecnica.

Ma la documentazione non si ferma qui. Nei casi in cui il tuo tema o plug-in fa parte di un progetto più ampio, o quando sono di per sé sufficientemente complessi, dovresti iniziare a pensare in termini di documentazione del prodotto. Aggiungendo alla verità che la documentazione è una risorsa, la documentazione del prodotto a sua volta è una risorsa di marketing. Questo è giustamente sintetizzato nella seguente citazione di Mike PuterBaugh, VP Marketing di MindTouch, in un articolo di Mashable sull'importanza della documentazione del prodotto:

Non è un'impresa sexy, ma ti farà guadagnare il rispetto dei tuoi colleghi, una gestione aziendale più efficace e un team più collaborativo. Perché non si tratta di questo trimestre o di quest'anno, ma piuttosto di influenzare il vantaggio competitivo e la crescita a lungo termine.

Quando si parla di prodotto, oltre alle forme più comuni di documentazione scritta, ce ne sono molte altre, come la guida in linea, le guide di stile, i microcontenuti e così via. La documentazione del prodotto viene solitamente scritta in collaborazione da molte persone diverse, il che aggiunge un ulteriore livello di complessità. Abbiamo scritto un'ampia guida che ti aiuta anche a iniziare a pensare e pianificare in questo modo.

Infine, mentre passiamo all'ultima fase del processo, che è la distribuzione, posizioniamo l'ultimo pezzo del puzzle della documentazione: i diagrammi di distribuzione. Questi ti aiutano ad avere un'idea chiara e sferica di cosa sia tutto e dove dovrebbe essere.

Sebbene la maggior parte delle persone scapperebbe urlando inorridita dopo aver sentito parlare di UML (e abbastanza comprensibilmente, la specifica completa di UML è terribile), a sua difesa, UML contiene un sottoinsieme di strumenti di notazione che possono aggiungere valore a un progetto. I diagrammi di distribuzione sono una notazione sorprendentemente semplice composta solo da nodi e percorsi di comunicazione che possono mostrarti in un colpo d'occhio i diversi ambienti che esistono nel tuo progetto e dove ogni componente deve essere distribuito.

Approfondiremo maggiormente l'UML in futuro, in particolare un'altra utile notazione chiamata Sequence Diagrams, nonché esempi più dettagliati di diagrammi di scenario Use Case per arricchire i requisiti del progetto e costruire prototipi.

La maggior parte, se non tutto lo sviluppo e la distribuzione moderni utilizzano una qualche forma di controllo della versione, come git e SVN. I repository di codice sorgente non sono essenziali solo per i team da soli, poiché i loro vantaggi sono ampi anche se sei uno sviluppatore WordPress solitario.

Se sei un cliente di Pressidium puoi integrare il tuo repository con il tuo account tramite SFTP, utilizzando un servizio esterno come deploybot. In alternativa puoi utilizzare SFTP per trasferire i tuoi file sul tuo account, poiché questo è il metodo più semplice e diretto. Puoi anche creare più utenti SFTP e assegnarli a siti Web e ambienti specifici. A proposito, avere un ambiente di gestione temporanea per il tuo sito Web garantisce che il processo di sviluppo e distribuzione sia più snello e che il tuo sito Web di produzione sia protetto da modifiche indesiderate. Ad esempio, dopo aver abilitato lo staging per il tuo sito web, puoi estrarre una copia dalla produzione e quindi creare un account SFTP per il tuo sviluppatore che ha accesso solo nell'ambiente di staging.

L'impostazione di una pipeline di sviluppo semplificata che passa attraverso più ambienti è una delle modifiche apportate dal movimento DevOps agli ambienti IT. L'adozione di una disciplina di distribuzione continua e l'invio di modifiche software in modo incrementale e frequente si traduce in cicli di distribuzione più rapidi e meno errori. Non è più necessario mantenere archivi ZIP con versioni diverse dell'applicazione. In questo modo potresti facilmente perdere le tracce e distribuire l'insieme sbagliato di modifiche che potrebbero danneggiare i tuoi sistemi di produzione. C'era anche il pericolo di avere problemi con i permessi dei file alterati che, nella migliore delle ipotesi, potrebbero causare il malfunzionamento dell'applicazione e, nella peggiore delle ipotesi, introdurre problemi di sicurezza.

Epilogo

Sappiamo che il tuo tempo libero come sviluppatore WordPress è piuttosto limitato. Ecco perché abbiamo consolidato tutto in un unico documento poiché il sovraccarico di informazioni è reale e sembra avere un impatto su tutti i knowledge worker e non solo sugli sviluppatori di WordPress. Abbiamo accennato all'inizio che il nostro obiettivo è in primo luogo fornire informazioni utili e, in secondo luogo, affrontare argomenti che riteniamo siano sottorappresentati nell'attuale letteratura di WordPress. Diventare uno sviluppatore WordPress è una cosa, rimanere pertinenti e competitivi è un'altra . E per farlo, devi avere una visione a tutto tondo dell'ingegneria del software come disciplina e acquisire buone abitudini, metodologie e tecniche che serviranno alla tua carriera a lungo termine.