Mai come in questo periodo mi sono trovato a scrivere codice e leggere codice (il mio e quello degli altri). Ho dovuto rimettere mano a vecchio codice prodotto, a piccole librerie create in passato (che a distanza di anni non valuto certo con voti altissimi). Mi sono ritrovato a confrontare un vecchio lavoro con quelli attuali, notando incredibili differenze in fatto di qualità del codice, prima ancora delle qualità delle conosocenze. A quel punto è stato facile derivare un paio di fattori chiave che potrebbero distinguere un buon programmatore da un ottimo programmatore, in attesa di capire la categoria nella quale sistemarmi. Sperando di poter regalare al lettore qualche utile consiglio.

1. Documentare il codice

Scrivere chiari e precisi commenti è impagabile. Permettono di leggere più facilmente il codice senza impazzire dietro ad algoritmi o funzioni o parametri conditi di mistero e di cui se ne disconosce la funzione, il significato e il motivo della loro esistenza. Gli stessi commenti devono essere scritti con coscienza, senza badare troppo alla forma magari, ma senza rinunciare a una certa formalità e un certo stile. Bisogna cercare di essere sempre chiari nelle spiegazioni e di non dare nulla per scontato. Prolissi e completi quando è rischiesto dal contesto, concisi quando è inutile divagare o spiegare cose ovvie e facilmente deducibili. Quando a distanza di tempo ci toccherà rimettere mano a un codice che abbiamo scritto di nostro pugno e di cui non ricordiamo molto, una veloce lettura dei commenti ci permette in pochi secondi di ritornare nella dimensione di quel progetto. Una buona documentazione del codice permette un alto livello di maintainability dello stesso. Nel caso, poi, ci fosse la necessità di collaborare con altri sviluppatori, il non dover chiedere costantemente chiarimenti su una funzione o un parametro permette di velocizzare il lavoro e migliorarlo sotto tutti i punti di vista, in quanto troveremo tutte le risposte dentro i commenti.

E’ possibile, in ultimo, estrarre dal codice sorgente i commenti formattati in un certo modo e produrre così un manuale per gli sviluppatori o una reference. Tutto in modo automatico ed evitando un doppio e tedioso lavoro. Uno strumento molto apprezzato, in tale contesto, è phpDoc (facile immagine per quale linguaggio).

Ultima raccomandazione, che a molti potrà suonare strana o esagerata. Se pensate che il vostro codice possa essere degno del panorama internazionale, cioè di un pubblico non solo italiano, allora è bene cominciare a prendere confidenza con l’inglese-scritto e commentare il codice in questa lingua.

2. Scrivere buon codice

E’ difficile in poche righe capire cosa significa “scrivere buon codice”, ma ci provo. Fra l’altro è una delle prime cose che uno studente si sente dire da un buon professore. Il pieno significato di un simile avvertimento dal sapore di consiglio lo si coglie solo quando si lavora seriamente a qualche progetto. O quando ci si confronterà con altri sviluppatori. Scrivere buon codice significa scrivere i nomi delle funzioni scegliendo i migliori termini, i più espressivi in assoluto. Conviene eliminare inutili abbreviazioni, solo per risparmiare qualche carattere e guadagnare qualche decimo di secondo in più sulla digitazione. Significa scrivere un codice la cui sola lettura è bastevole per capirne l’implementazione. Generalmente una funzione chilometrica è sintomo di scarsa progettazione del codice, il che non vuol dire che poi le cose non funzionano. La migliore palestra, in tal senso, è la lettura di codice dei migliori programmatori che potete trovare in rete e l’analisi di progetti dal codice aperto.

3. Framework e librerie

Spesso ci si trova a riscrivere del codice che in realtà esiste già e probabilmente risulta più completo del nostro, oltre che più efficace. Pertanto prima di buttarsi a capofitto nella scrittura di nuove classi occorre capire cosa offre Internet. Esistono diversi utilissimi siti dove poter trovare del buon codice (citiamo su tutti Sourceforge). Ed esiste Google per cercare eventuali librerie già pronte per essere usate nei nostri progetti. Se nulla ci soddisfa allora non resta che scrivere quanto abbiamo di bisogno. Se abbiamo intrapreso quest’ultima strada è buona cosa pensare non al progetto in sé, quanto piuttosto ai problemi generali che intendiamo risolvere. E’ questo infatti il caso migliore per pensare a una libreria riutilizzabile pure in altri progetti. Se poi siamo soliti lavorare su applicazioni che in qualche modo hanno molte somiglianze fra di loro, beh allora conviene pensare a qualche framework. Generalmente una grande società di software ne progetta uno e provvede a usarlo nei vari lavori. Uno sviluppatore indipendente può lanciare a se stesso la stuzzicante sfida di costruirne uno nuovo, o studiare per bene un framework esistente.

In tal senso un buon framework (Rails per i programmatori Ruby, Zend o Symfony per i programmatori PHP, Django per gli appassionati di Python) potrebbe essere una ottima base per sviluppare una grande applicazione. Ma occorre valutare per bene ogni fattore. Spesso un framework rischia di appesantire lo sviluppo e se non riusciamo ad ottimizzarne la configurazione rischiamo pure di ottenere un prodotto dalle scarse performance. E’ opportuno inoltre non focalizzarsi soltanto su un prodotto, ma studiarne più di uno per capire realmente benefici e svantaggi di ognuno di loro. A quel punto, e solo a quel punto, conviene sceglierne uno e provare a padroneggiarlo al meglio. In altre parole: non limitarsi a leggere qualche articolo su Internet (raramente ho scovato delle analisi pienamente oggettive sui software e sui framework), ma sperimentare le soluzioni. Quindi specializzarsi su un prodotto.

4. Standard e best practices

I design pattern vanno studiati, compresi e quindi usati. Spesso ci si accorge che bravi programmatori li disconoscono ed è un male. Pattern quali MVC offrono una potenza incredibile. E numerosi altri pattern offrono una soluzione ottimale a ricorrenti problemi per quanto riguarda la programmazione (che è poi la definizione di Design Pattern).

Quando parliamo di best practices ci riferiamo a delle esperienze che altri hanno già maturato in qualche settore professionale e nelle quali hanno raggiunto ottimi risultati. Potete pensare a delle regole generali, più o meno formalizzate, o a degli esempi opportunamente descritti e commentati. Per quanto mi riguarda mi sono stati utilissimi i libri di ingegneria del software che ho letto e sui quali ho trovato diversi riferimenti a ulteriori libri e articoli. Potete recuperare su internet diverse interviste a eminenti sviluppatori che raccontano le loro esperienze e le loro idee.

5. Pensare. Poi scrivere codice

Lontano da una schermo e una tastiera si riesce meglio a programmare. Sembra un paradosso, invece è la pura realtà. Provate a pensare alla vostra architettura fuori da una finestra di Mac o di Windows o di Linux. Fogli di carta, penna, matita e idee. Non è tempo sprecato, anzi tutto il contrario. Uno schermo con icone e testo, una tastiera e un mouse possono risultare degli elementi destabilizzanti e di distrazione. Si è tentati di scrivere subito del codice funzionante, salvo poi scoprire che una funzione poteva essere scritta meglio, o un insieme di classi poteva essere progettato in modo più intelligente. A quel punto tornare indietro è complicato. Rifattorizzare equivale a partire da zero (e a un livello iniziale non si parla certo di refactoring) e, si realizzerà con estremo rammarico, di aver buttato via preziose ore di lavoro.

Ponderare bene le scelte: tracciare diagrammi, appuntare note e idee, provare a scrivere un piano di sviluppo. Anche senza badare alla forma, una sorta di brainstorming solitario. Fate una lista dei problemi da risolvere, delle possibili soluzioni cui avete pensato e, dopo una pausa lontano da tutti e tutto, rileggete con attenzione quanto avete scritto e cercate di capire se è l’ora di mettersi a scrivere codice o conviene dedicare ancora qualche minuto a questa meditazione pre-sviluppo.

Non esiste un libro delle soluzioni in informatica. Esiste però una quantità smisurata di handle di soluzioni. Queste maniglie altro non sono che il codice e gli applicativi che altri programmatori hanno già realizzato e rilasciato. Dare uno sguardo all’interno del codice scritto da terzi (e dovete ovviamente scegliere i migliori terzi, perché conviene imparare soltanto dai migliori) si rivelerà presto preziosa lettura e fonte di soluzioni. Il che non vuol dire che dovete copiare, ma certamente ispirarvi. O, più umilmente, imparare.

Uno degli strumenti importanti per raccogliere traffico interno al blog è mostrare gli articoli collegati a quello che il visitatore ha appena letto. In WordPress esistono molti plugin che permettono di ottenere un simile risultato. Ne esistono veramente diversi: qualcuno presenta buone caratteristiche, qualcuno ottime funzionalità lato amministrazione. Ma può non essere la soluzione migliore.

Per certi compiti usare un plugin è una forzatura e rende il tutto leggermente più lento, in quanto il l’engine di WordPress deve provvedere a caricare ed eseguire tutti i plugin. Meglio eseguire codice scritto apposta. Il file functions.php potrebbe essere il posto ideale per piazzare lì alcune utili funzioni da utilizzare in lungo e in largo nel nostro tema.

Rispondiamo allora, in questo piccolo articolo, alla domanda del titolo: si può ottenere una lista di articoli related senza usare plugin? Certo. Nel mio blog uso il seguente codice.

L’idea è di partire dalle categorie in cui è inserito il post. Quindi estrarre da ogni categoria gli articoli collegati. La mia soluzione prevede il recupero a ritroso degli articoli più recenti, questo per evitare di doppiare gli articoli più letti che mostro in un apposito widget (test che ho effettuato!), a meno di casuale coincidenza. Ora gli approcci sono due:

1. inserire il codice all’interno del vostro file functions.php e richiamarlo nel punto esatto del vostro tema;
2. inserire il codice all’interno del file single.php.

L’opzione numero 2 mi è sembrata nel mio caso la più logica. Ecco il codice:

$_cats = get_the_category($post->ID);
if ($_cats) {
	$_catid = array();
	foreach($_cats as $_item) $_catid[] = $_item->term_id;

	$args=array(
		'showposts'=>5,
		'category__in' => $_catid,
		'post__not_in' => array($post->ID),
		'caller_get_posts'=>1
	);
	$_relposts_query = new wp_query($args);
	if( $_relposts_query->have_posts() ) {
		echo '<h3>Related Posts</h3><ul>';
		while ($_relposts_query->have_posts()) {
			$_relposts_query->the_post();
		?>
			<li><?php if(has_post_thumbnail()) echo get_the_post_thumbnail(get_the_id(), array(50,50)); ?><a href="<?php the_permalink() ?>" rel="bookmark" title="Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a></li>
		<?php
		}
		echo "</ul>";
	}
}

Come potete notare uso la nuova funzione di WordPress relativa ai thumbnails. Per modificare il numero di articoli da mostrare settate il parametro showposts secondo vostre necessità (riferimento wp_query). Per il resto è davvero tutto molto semplice e risulterà chiaro a chi ha un pò d’esperienza con i temi di WordPress.

P.S.

Simile risultato può essere ottenuto giocando con i tag. Anzicchè prendere a riferimento le categorie, come nel mio caso, è possibile recuperare i tag con cui è stato postato un articolo e da lì recuperare i related posts. In tal caso date un’occhiata all’idea di Jean Baptiste Jung.

Nemmeno il tempo di gustarsi il lancio di questo nuovo blog che mi ritrovo col primo indisponente problema. Agganciando a FeedBurner il mio flusso RSS noto immediatamente che Google mi rigetta indietro il link. Il sorgente non è ok, ci sono problemi sulla validazione del formato. Molto strano visto che l’installazione è praticamente nuova e non ho messo mano al codice del core di WordPress. Con molta pazienza leggo i risultati della validazione, meglio gli errori. Problema banale e riassunto in una semplicissima e maledetta frase in inglese:

XML Parsing Error: XML or text declaration not at start of entity

In effetti aprendo il flusso con un programma esterno danno noia a me al validatore le righe bianche, quindi vuote, all’inizio del notiziario. Cioè è proprio WordPress a creare casino e il motivo è che gli ingegneri della piattaforma hanno leggermente complicato la creazione dell’RSS. Qual è la soluzione, allora?

Apriamo con gentilezza il file feed-rss2.php che si trova nella directory wp-includes, partendo dalla root della nostra installazione di WordPress. Nelle primissime righe troviamo le due istruzioni seguenti:

header('Content-Type: text/xml; charset=' . get_option('blog_charset'), true);
$more = 1;

La loro funzione è importante ai fini della creazione dell’RSS. Immediatamente dopo questa coppia di istruzioni inseriamo il seguente trick che sistema tutte le cose:

$out = ob_get_contents();
$out = str_replace(array("\n", "\r", "\t", " "), "", $input);
ob_end_clean();

In particolare prende i caratteri bianchi (sostanzialmente i caratteri di tabulazione che vedete inseriti nell’array-parametro) iniziali e li pulisce, così come da formato XML. Salviamo tutto quanto e il nostro formato sarà ora valido.

La stessa identica operazione dovremmo farla sul file feed-rss2-comments.php che si trova sempre nella directory cui prima accennavo. E se utilizzate gli altri formati il consiglio è quello di ripetere la stessa operazione per i file feed-rdf.php, feed-rss.php, feed-atom.php, feed-atom-comments.php.

Fatto ciò FeedBurner non ci distuberà più e noi potremo iniziare a raccogliere statistiche utili per far crescere il nostro blog.

Durante lo sviluppo di un tema per WordPress capita sovente di aver bisogno di alcune piccole utili statistiche. Ad esempio il numero totale di post pubblicati. Oppure quante categorie l’autore sta usando. E ancora quanti tag, quanti commenti. Molti propongono come soluzione il ricorso a query. Dobbiamo in qualche modo eseguire il collegamento al database e lanciare un’interrogazione. Esercizio per nulla semplice, ma complicazione del tutto inutile. Perchè non ricorrere a funzioni già preconfezionate?

WordPress mette a disposizione dello sviluppatore il set di funzioni che hanno in comune il prefisso wp_count_. Il set che a noi interessa è allora il seguente:

• wp_count_posts('posts')
• wp_count_terms('category')
• wp_count_terms('post_tag')
• get_comment_count()

Trovare il numero totale degli articoli

Supponiamo allora di voler mostrare il numero totale degli articoli pubblicati. Per comodità vi consiglio di creare delle piccole funzioni che poi possiamo richiamare liberamente e comodamente in ogni punto dei nostri temi. Il posto migliore dove riunire queste funzioni è il file functions.php. Ricorriamo allora ad un codice simile:

	function get_total_posts() {

		$___posts = wp_count_posts('post');            

		return $___posts->publish;

	}

Commentiamo quel poco che c’è da commentare. Secondo una mia personalissima convenzione amo chiamare tutti gli oggetti che uso in modo indiscriminato anteponendo al loro nome tre caratteri di undescore. Facili da cercare, facili da riconoscere proprio visivamente. La funzione ci restituisce un oggetto dal quale preleviamo il numero di post effettivamente pubblicati, quindi scartando i draft. In realtà il parametro post potrebbe essere anche omesso, in quanto parametro di default, ma per leggibilità io preferisco sempre inserirlo.

Se vogliamo viceversa fare il conteggio degli articoli in bozza allora modifichiamo leggermente il codice:

	function get_total_drafts() {

		$___posts = wp_count_posts('post');            

		return $___posts->draft;

	}

In questo modo è possibile richiamare le due funzioni come segue:

        echo get_total_posts();
        echo get_total_drafts();

Trovare il numero di categorie e il numero di tag

In modo del tutto analogo presentiamo brevemente il codice per recuperare il numero delle categorie e il numero dei tag:

	function get_total_categories() {

		$___cats  = wp_count_terms('category');

		return $___cats;	

	}

	function get_total_tags() {

		$___tags  = wp_count_terms('post_tag');

		return $___tags;		

	}

La chiamata delle due funzioni avviene nel modo canonico. In più vi propongo una semplice funzione che ho scritto per conoscere il numero di articoli pubblicati in una determinata categoria:

	function get_posts_in_category($cat) {

		$___catid = get_cat_id($cat);

		$___catobj = get_category($___catid);

		return $___catobj->category_count;

	}

Da notare che il parametro che passate alla funzione è esattamente il nome della categoria di cui volete conoscere il conteggio degli articoli, senza perciò passare dal recupero dell’ID.

Trovare il numero di commenti

Ultima funzione. Recuperiamo il numero di commenti registrati nel nostro blog:

	function get_total_comments() {

		$___comm  = get_comment_count();                                             

		return $___comm['approved'];

	}

Dall’array possiamo estrarre i seguenti valori:

• awaiting_moderation per i commenti in attesa di moderazione;
• spam per il totale dei commenti spam;
• tot per recuperare il numero totale dei commenti (informazione sulla cui utilità ho qualche dubbio).

Per consultare la documentazione ufficiale vi rimando al seguente link. Suggerimenti per migliorare il codice o per velocizzarlo? Alternative alle funzioni proposte?