Ereditare progetti WordPress: suggerimenti per lo sviluppo

Se gestisci un’azienda che si concentra sia sullo sviluppo di soluzioni da zero sia sull’implementazione di una soluzione personalizzata nel contesto di progetti preesistenti (o forse entrambi), allora è probabile che, a un certo punto, stato nella situazione di ereditare progetti WordPress.

Affrontare i progetti da entrambe le maniglie comporta una serie di sfide – la maggior parte delle quali benvenute – ma sembra essere molto più comune per le persone lamentarsi di lavorare con una base di codice preesistente.

Non è che non provo quella sensazione, ma penso che ci sia un livello di immaturità nel farlo. Da un lato, sì, alcune basi di codice sono assolutamente terribili. Ma poi alcune basi di codice non sono così male. In effetti, direi che sono solo un po’ diversi da come lo sviluppereste.

Questo è un caso in cui entrano in gioco gli standard, ma per ora divago su questo.

Diciamo quindi che stai ereditando progetti WordPress e non sei particolarmente entusiasta della base di codice con cui stai lavorando. Com’è che puoi ancora goderti il ​​lavoro che stai facendo senza sentire il bisogno di criticare ogni aspetto di qualunque cosa tu abbia a che fare?

Ereditare progetti WordPress

In primo luogo, questa nozione di lamentarsi del lavoro altrui è l’acqua proverbiale in cui non mi piace calpestare.

• Non conosco lo sfondo che porta la base di codice a essere nel suo stato,
• Non so perché certe cose sono state sviluppate come erano (limiti di tempo, mancanza di familiarità con un progetto, ecc.),
• Ho il compito di fare qualcosa nel contesto del progetto, quindi perché dedicare del tempo a concentrarmi su cose che non fanno parte della mia responsabilità?

Ho capito: ci sono momenti in cui il codice che scriviamo deve comunicare con un codice che già esiste. E questo può essere difficile. Ci sono modelli di progettazione che non sono specifici per questa situazione.

Ma piuttosto che coprirlo, ho pensato di condividere tre cose che penso mostrino maturità quando si tratta di sviluppo quando si ereditano progetti WordPress che potrebbero irritarci.

1 Non rifattorizzare tutto

Come ha affermato Martin Fowler :

Questo refactoring opportunistico viene definito da zio Bob come se seguisse la regola del boy-scout: lascia sempre il codice in uno stato migliore di quello che hai trovato.

In generale, mi piace questa regola, ma a seconda dei requisiti del progetto questo può essere al di là delle nostre responsabilità.

Quindi, ogni volta che ci imbattiamo in qualcosa che sappiamo necessita di refactoring, ma il progetto procede senza intoppi. Se apporti una modifica a qualcosa perché ritieni che debba essere fatto, non sai come questo si verificherà a cascata nel corso del progetto.

Se hai tempo per fare un controllo completo del codice, questa è una cosa, ma in caso contrario, il tuo compito è introdurre ciò che hai accettato di fare.

2 Concentrati su ciò che hai accettato di fare

E questo porta a questo punto: quando si ereditano progetti WordPress, ti viene assegnata una certa quantità di lavoro e nient’altro (ecco perché abbiamo una dichiarazione di lavoro, giusto?).

Quindi, nonostante tu voglia cambiare l’ambiente in cui ti trovi, non farlo. Concentrati su ciò che puoi fare, su ciò che solo tu puoi fare e su ciò che hai accettato di fare.

Penso che sia giusto prendere appunti sui problemi, e penso che questo possa anche essere utile (e ne parlerò momentaneamente), ma non perdere la concentrazione su ciò che hai accettato di fare. Fare qualsiasi cosa ma non è professionale.

3 Non giudicare lo sviluppatore precedente

Un’altra cosa comune, specialmente nell’open source, è giudicare lo sviluppatore che ha scritto il set iniziale di codice con cui stai lavorando.

Cos’è questo? Non lo scriverei mai in quel modo.

Voglio dire, quante volte l’abbiamo pensato a noi stessi? Ma non conosciamo il tempo, i vincoli, l’esperienza o il contesto in cui lo sviluppatore stava lavorando.

Il codice che pubblichiamo non è necessariamente rappresentativo del nostro livello di abilità. È spesso dettato da variabili di terze parti che influiscono sul modo in cui implementiamo una soluzione.

E sappiamo com’è, giusto? Quante volte abbiamo voluto fare qualcosa in un modo, ma i vincoli e il programma in base ai quali stiamo lavorando determinano ciò che stiamo facendo?

Allora perché dovremmo aspettarci che quegli sviluppatori siano diversi?

Facoltativo: offrire supporto futuro

Come accennato in precedenza, se ti imbatti in aree problematiche nella base di codice, ciò non significa che sia una causa persa.

Invece, quando incontri questo tipo di problemi, penso che sia una buona idea:

• prendere appunti sulle cose che hai visto,
• annota cosa faresti per risolverlo e perché,
• parla con il cliente di ciò che hai visto e dei vantaggi dell’aggiornamento.

Questo ovviamente porta a un lavoro futuro ma, forse soprattutto, ti consente di offrire soluzioni per creare software migliori e più ben architettati e ti consente di assicurarti di rendere Internet un posto migliore per un CMS così popolare.

No, questo lavoro non è mai garantito, ma è utile.

Sono sicuro che c’è di più

Questi sono solo tre suggerimenti che offro in base all’esperienza che ho durante l’ereditarietà di progetti WordPress. Non è pensato per essere onnicomprensivo.

Invece, ha lo scopo di fornire alcuni suggerimenti che ti consentono di essere più rispettoso del lavoro degli altri in relazione al tuo lavoro, di pensare più chiaramente a ciò che potresti fare di fronte a situazioni simili e di raccogliere più lavoro migliorando l’esistente soluzione potenzialmente.

Ma so che le cose che ho citato sono solo alcune delle mie osservazioni. Hai il tuo? Menzionateli nei commenti.