Le problème

La fonction fadeIn() de jQuery et les animations css3 ne font pas bon ménage si l’élément sur lequel est appelé fadeIn() contient un autre élément animé via une animation css3.
Un overlay avec un spinner (pour indiquer à l’utilisateur le chargement de quelquechose) pourrait être une bon exemple :

Du html :

<div id="overlay">
	<div id="spinner"></div>
</div>

Des css :

#overlay{
...
}

#spinner{
	animation: rotation 3s infinite linear;
}

@keyframes rotation{
	from {transform: rotate(0deg);}
	to {transform: rotate(359deg);}
}

Du javascript :

$('#overlay').fadeIn();

Et la c’est le drame… pas de joli fadeIn, juste une apparition sèche :(

La solution

La solution consiste simplement à appliquer l’animation css3 après le fadeIn() dans le callback de la fonction. Pour se faire, l’animation est déclenchée par l’ajout d’une classe à l’élément animé… on modifie les css en conséquence :

#spinner{
	/* suppression de l'animation qu'on déporte dans une classe */
}

#spinner.animated{
	animation: rotation 3s infinite linear;
}

et on modifie le javascript :

$('#overlay').fadeIn(function(){
	$('#spinner').addClass('animated');
});

Et hop tout rentre dans l’ordre :)

Happy coding !

Un exemple rapide

<a href="https://twitter.com/share" data-lang="fr" data-hashtags="monHastag" data-url="http://bit.ly/fAkEurL" data-counturl="http://www.mavraieurl.com/" data-text="Mon texte de tweet par défaut">Tweeter</a>

Happy coding !

Le problème

La documentation de CodeIgniter propose de faire cette séparation en créant autant de sous-dossiers qu’il y a d’applications dans le répertoire « application » et d’y dupliquer tous les répertoires nécessaires. Le problème avec cette approche vient du fait qu’il y a un risque de duplication de code puisque chaque application est totalement indépendente. Par exemple il faudra plusieurs fichiers de configuration, plusieurs fichiers de routes… Pire encore : si vous souhaitez partager des librairies, helpers, models, etc… ça ne sera pas possible et il faudra également les dupliquer.
Sur ce dernier point, depuis la version 2 de CodeIgniter ce n’est plus tout à fait exact : on peut utiliser le dossier « third_party » pour y partager configurations, helpers, models et librairies – mais il n’y a toujours pas de séparation des applications et l’on ne peut pas interagir avec le router.

Une solution

En effet il n’y a pas une seule et unique solution au problème mais je vous une présente une que je trouve assez astucieuse, relativement simple à mettre en place et qui ne nécessite aucune librairie ni overload de classes. Elle se résume en deux mots : liens symboliques.

Mise en œuvre

Pour cette article nous partirons du postulat que nous voulons créer un site web en local (pour le développer bien sûr^^) et séparant le front-office (ce que voit le visiteur) du back-office (ce qu’utilise le(s) gestionnaire(s) du site).

Pour commencer il faut choisir une stratégie de différenciation des applications : adresse IP, sous-domaine, URI, session… ou, vraisemblablement, une combinaison de ces possibilités. Pour l’example nous utiliserons un sous-domaine « admin » pour le back-office, le front-office étant sur « www ».

Configuration hosts

En développement local j’utilise toujours des hôtes virtuels et comme je travaille sur un Mac utilisant MAMP, j’explicite les réglages pour cette plateforme – mais c’est à peu de choses près la même chose sous Windows et Linux. Bref :
On édite le fichier /private/etc/hosts en y ajoutant à la fin deux lignes :

127.0.0.1 www.montest.local
127.0.0.1 admin.montest.local

Sous Lion faites bien attention à ce qu’il y ait une ligne vierge à la fin du fichier, comme je l’explique dans cet article.

Configuration Apache

Les serveurs de MAMP doivent être arrêtés et l’on édite le fichier /Applications/MAMP/conf/apache/httpd.conf en y ajoutant les deux serveurs virtuels correspondants à ce que nous avons ajouté dans le fichier hosts :

<VirtualHost *:80>
DocumentRoot /Applications/MAMP/htdocs/montest/www/
ServerName www.montest.local
</VirtualHost>

<VirtualHost *:80>
DocumentRoot /Applications/MAMP/htdocs/montest/www/
ServerName admin.montest.local
</VirtualHost>

Vous noterez que le document root est « www » et non la racine du site, ceci pour des raisons de sécurité : le serveur apache ne permettra que d’accéder aux fichiers nécessaires à l’application : le bootstrap (index.php) et les ressources (javascript, images, css).

Arborescence du projet CodeIgniter

Nous allons modifier l’arborescence de base de CodeIgniter pour prendre en compte la séparation d’applications et le déplacement des fichiers d’application et du framework :

Les modifs sont les suivantes :

• Le répertoire « application » à été renommé « applications »
• Les répertoires « bo » et « fo » ont été créés
• Le contenu originel du répertoire « application » a été déplacé dans « bo »
• Un répertoire « www » a été créé au même niveau que « applications » et index.php y a été déplacé

Dans le répertoire « fo » nous rajouterons les répertoires « controllers » et « views » et c’est là que la séparation aura effectivement lieu : le front-office aura ses propres controlleurs et vues. Tout le reste proviendra du répertoire « bo ».

L’astuce pour que ça marche

Comment le framework va-t’il trouver les modèles, librairies, etc… dans la partie front alors qu’il n’y sont pas ? Tout simplement en utilisant des liens symboliques de Linux. Pour les créer, un petit tour dans le Terminal, en se plaçant dans le répertoire « fo » il n’y plus qu’a tapper les lignes suivantes (en validant ligne par ligne) :

ln -s ../bo/cache cache
ln -s ../bo/config config
ln -s ../bo/core core
ln -s ../bo/errors errors
ln -s ../bo/helpers helpers
ln -s ../bo/hooks hooks
ln -s ../bo/language language
ln -s ../bo/librairies librairies
ln -s ../bo/logs logs
ln -s ../bo/models models
ln -s ../bo/third_party third_party

Et le tour est joué ! Ou presque…

Configurer index.php

Comme nous avons modifié l’arborescence du framework il faut lui indiquer où trouver ses fichiers, mais aussi lui indiquer quelle application utiliser. Nous modifions donc /www/index.php :

[...]
$system_path = '../system'; // on a sorti le framework du webroot (sécurité)
[...]
// changement application en fonction du sous-domaine
// a modifier en fonction de la stratégie de différenciation choisie
if( preg_match('/admin\.*/', $_SERVER['SERVER_NAME']) ) {
	$app_folder = '/bo';
} else {
	$app_folder = '/fo';
}

$application_folder = '../applications' . $app_folder; // les applications sont également en dehors du webroot (sécurité)

A noter qu’il s’agit là d’une partie du fichier index.php de la version 2.0.3 du framework – le reste n’étant pas intéressant pour cet article. Pour les versions précédentes du framework, ce fichier est similaire.

Dorénavant tous les models, librairies, configs etc… seront stockés dans un lieu commun (le répertoire « bo ») et seront disponibles pour toutes les applications.

Conclusion

Cette technique permet de simuler un système de modules qui manque à CodeIgniter (bien qu’il existe des librairies le permettant, par exemple HMVC). Elle a l’avantage de fonctionner sur les versions antérieures à la 2.X du framework, alors qu’à partir de la version 2 on pourrait utiliser le système de « third_party » bien qu’il faille encore les charger « à la main ».

Happy coding !

Faut-il tout transférer ?

La réponse à cette question simple l’est tout aussi : non. Pour savoir ce qu’il faut transférer il faut faire une distinction entre les fonctions qui impactent le contenu et celles qui impactent le design. Celles qui ont un impact sur le contenu ont tout intérêt à être déplacées dans un (ou plusieurs) plugins alors que les autres servent uniquement le design ou layout du site et doivent rester dans le fichier functions.php du thème.

Que faut-il (ou peut-on) transférer ?

Dès l’instant où le fait de ne plus avoir une fonction va poser un problème il serait judicieux qu’elle se retrouve dans le plugin, par exemple :

• Les shortcodes
• Les filtrages de contenu
• Les custom post types
• Les custom taxonomies
• Les ajouts à l’admin de WordPress

Que faut-il conserver dans functions.php ?

Si une fonction n’a qu’un impact visuel, notamment sur le design et la structure du site, dans ce cas il appartient directement au thème et doit par conséquent rester dans functions.php – par exemple :

• Les menus
• Les sidebars
• La pagination

Créer le plugin de fonctionnalités

La création d’un plugin est très simple et si vous savez ajouter des fonctions à functions.php alors vous pouvez créer votre plugin !

Première étape

Créez un repertoire qui porte le nom de votre plugin en n’utilisant que des lettres non accentuées, des chiffres et des tirets. Pour cette article on partira du principe que le nom du plugin est monsite-fonctions.

Dans ce répertoire créez un fichier PHP qui porte exactement le même nom : monsite-fonctions.php.

Deuxième étape

Ajoutez les commentaires en début de fichier qui permettront à WordPress de voir qu’il s’agit bien d’un plugin :

/*
Plugin Name: Fonctions de monsite
Plugin URI: http://www.monsite.com/
Description: Déplace les fonctionnalités qui impactent le contenu dans un plugin
Author: Nom Prénom
Version: 0.1
Author URI: http://www.monsite.com/
*/

Troisième étape

Il n’y a plus qu’a insérer les fonctions dans ce fichier, puis activer le plugin dans l’administration de WordPress et le tour est joué !

Conclusion

Comme vous l’avez vu il est très simple de créer un plugin rendant les fonctions clés d’un site sous WordPress indépendantes de son thème. Cela peut être également très utile dans le cas où votre client veut pouvoir changer de thème sans pour autant perdre ses fonctions. Vous pouvez également vous constituer une bibliothèque de plugins réutilisables dans d’autres thèmes.

Pour en savoir plus sur la création de plugins, je vous invite à consulter le codex de WordPress (en anglais) : writing a plugin

Happy coding !

Le problème

Si vous êtes webdesigner ou développeur il y a de fortes chances que vous utilisiez des hôtes virtuels (virtual hosts) configurés dans Apache et, par conséquent, que vous routiez vos noms d’hôtes virtuels par le biais du fichier hosts de MacOS.

Vous aurez certainement remarqué que la dernière entrée de ce fichier ne fonctionne pas, à savoir : page blanche :(

La solution

C’est bête comme choux mais il fallait le savoir : il suffit d’ajouter une ligne vide à la suite de votre dernière entrée et tout rentre dans l’ordre !

Functions.php

Il suffit d’ajout un tout petit bloc de code dans le fichiers functions.php :

// filtrage des recherches -> limite aux articles publiés
function filtre_recherche( $query ) {
	if ( $query->is_search && !is_admin() ) {
		$query->set( 'post_type', 'post' );
	}
	return $query;
}
// ajout du filtrage sur le hook 'pre_get_post'
add_filter( 'pre_get_posts', 'filtre_recherche' );

Ce bout de code restreindra la recherche aux seuls articles (posts) publiés. Si l’on souhaite étendre la recherche à plusieurs types, il suffit de modifier légèrement la fonction :

// filtrage des recherches -> limite aux articles publiés, aux pages et à un custom post type
function filtre_recherche( $query ) {
	if ( $query->is_search && !is_admin() ) {
		$query->set(  'post_type', array( 'post', 'page', 'custom-post-type' ) );
	}
	return $query;
}
// ajout du filtrage sur le hook 'pre_get_post'
add_filter( 'pre_get_posts', 'filtre_recherche' );

Vous l’aurez remarqué, seule la partie $query->set() change : on lui passe un array des types de posts que l’on souhaite voir apparaître dans les résultats de recherche.

Pour en savoir plus

Rendez-vous sur le Codex de WordPress : la class WP_query (qui contient la propriété $query) et le hook pre_get_posts

Happy coding !

Présentation du site

Le but du site est simple : permettre aux auteurs d’articles (publiés sur leur propres sites) ainsi qu’aux utilisateurs de sites de partager les articles et autres ressources, en français, concernant le webdesign et le développement web et qu’ils jugent utiles et pertinents.

Il n’est pas nécessaire de s’inscrire pour partager, il suffit de remplir un formulaire simple et rapide.

Un peu de technique

Pour ceux que cela intéresse, le site est développé avec WordPress et utilise la technique d’affichage des articles en colonne dont j’ai fait un petit tutoriel ici même. J’ai également développé un petit plugin pour permettre à tout le monde d’ajouter des articles sans pour autant devoir s’inscrire.

Le mot de la fin

J’espère simplement que le site sera utile et que beaucoup de gens y participerons en ajoutant des liens vers des articles/ressources qui leur ont plu ou qu’ils ont publié eux-même.

Le maître-mot sera simplement : partagez !

Happy coding !

Voici ce que l’on veut obtenir : afficher sur la page d’accueil la liste des articles (ou les extraits) dans 2 colonnes, avec les plus récents en haut. Pour y parvenir nous utiliserons l’opérateur modulo de PHP et de la fonction rewind_posts() de WordPress.

Le problème

On pourrait tout simplement utiliser la propriété float de CSS pour arriver à nos fins et ça fonctionnerai parfaitement dans le cas de figure où tous les blocs contenant les articles ont la même hauteur (comme dans l’image précédente).

Mais il est très probable que ça ne soit pas le cas : la hauteur de chaque bloc va varier en fonction de son contenu (l’extrait ou l’article). Dans ce cas de figure il y aura 2 problèmes : l’espacement aléatoire entre les blocs (en hauteur) et le non respect de l’ordre chronologique :

Ce n’est pas un bug mais seulement la manière dont fonctionnent les éléments « floatants ».

Pour résoudre le problème d’espacement on pourrait utiliser 2 div pour créer les colonnes et y insérer nos articles, mais dans ce cas l’ordre chronologique des articles se fera de haut en bas, colonne par colonne (voir l’image ci-dessous). Hors nous voulons que les 2 derniers articles soient en haut de la page.

La solution

Nous utiliserons tout de même les 2 div pour créer nos colonnes, c’est au niveau de la boucle de WordPress que nous agirons pour respecter la chronologie de nos articles.

Voici la structure HTML de base que nous utiliserons:

<div id="page">
	
	<div id="header"></div>
	
	<div id="contenu" class="clearfix">
		<div class="colonne"></div>
		<div class="colonne"></div>
	</div>
	
	<div id="sidebar" class="clearfix"></div>
	
	<div id="footer"></div>
	
</div>

Les règles CSS qui vont avec :

#page { width: 960px; margin: 0 auto }
#header { padding: 10px; margin: 20px 0 }
#contenu { width: 660px; float: left }
.colonne { width: 300px; margin-right: 30px; float: left }
#sidebar { width: 300px; float: right }
#footer { padding: 10px; margin: 20px 0 }
.clearfix:after { visibility: hidden; display: block; font-size: 0; content: " "; clear: both; height: 0; }

J’ai mis la structure complète mais ce qui nous intéresse ici c’est surtout le contenu de la div #contenu

Le template WordPress

Dans le cas d’un blog classique il n’y a qu’une seule boucle pour afficher les articles. Pour ce que nous souhaitons réaliser on pourrait utiliser 2 boucles sur mesure, mais ce n’est pas nécessaire et utiliserai inutilement plus de ressources (2 requêtes MySql au lieu d’une seule, plus de mémoire) et de temps.
Nous utiliserons la fonction rewind_posts() qui permet de revenir au début de la boucle pour ensuiter la parcourir à nouveau. L’astuce réside dans la manière dont nous allons la traiter : grâce à l’opérateur modulo nous filtrerons l’affichage (ou non) des articles…

Dans le template de la page d’accueil :

<div id="contenu" class="clearfix" >

	<!-- 1ere colonne -->
	<div class="colonne">
		<?php
		// variable qui servira pour filtrer l'affichage des posts
		// et qui sera incrémentée à chaque itération
		$i = 1;
		if( have_posts() ) :
			while( have_posts() ) :
				the_post();

				// s'il ne s'agit pas du 1er article dans la série de 2
				// on passe à l'itération suivante sans rien afficher
				if( $i%2 != 1 ) :
					$i++; // incrémente le compteur
					continue; // on passe directement à l'itération suivante

				else : // pas nécessaire mais clarifie le fonctionnement ?>

					<div class="article">
						<h2><?php the_title(); ?></h2>
						<?php the_excerpt(); // le résumé de l'article ?>
					</div>

				<?php
				endif; // fin if $i%2
				$i++; // incrémente le compteur
			endwhile; // fin boucle while
		endif; // fin if have_posts() ?>

		<?php
		// on se remet au début de la boucle des articles 
		// pour pouvoir la traiter à nouveau
		rewind_posts();
		?>
	</div><!-- fin 1ere colonne -->

	<!-- 2eme colonne -->
	<div class="colonne">
		<?php
		$i = 1; // variable qui servira pour filtrer l'affichage des posts
		if( have_posts() ) :
			while( have_posts() ) :
				the_post();

				// s'il ne s'agit pas du 2eme article dans la série de 2
				// on passe à l'itération suivante sans rien afficher
				if( $i%2 != 0 ) :
					$i++; // incrémente le compteur
					continue; // on passe directement à l'itération suivante

				else : ?>

					<div class="article">
						<h2><?php the_title(); ?></h2>
						<?php the_excerpt(); // le résumé de l'article ?>
					</div>

				<?php
				endif; // fin if $i%2
				$i++; // incrémente le compteur
			endwhile; // fin boucle while
		endif; // fin if have_posts() ?>

	</div><!-- fin 2eme colonne -->

</div><!-- fin #contenu -->

Et voila, nous sommes arrivé à notre résultat ! Bien évidemment on pourrait vouloir 3 colonnes d’articles : l’opération est la même sauf que l’on utilisera $i % 3 au lieu de $i % 2 — Le diviseur servant à déterminer le nombre d’articles a ne pas afficher et sera égal au nombre de colonnes.
Il faudra également dupliquer tout le bloc de code pour ajouter la 3e colonne, sans oublier rewind_posts() à la fin de la 2e colonne ni de changer la valeur de test du modulo pour la 2e colonne ( if( $i%3 != 2 ) ).

A propos du modulo

Si vous ne savez pas ou ne vous souvenez pas du fonctionnement de modulo, voici l’explication :
On divise le chiffre de gauche par celui de droite et le résultat ne tient compte que du chiffre entier obtenu (donc sans chiffre après la virgule). Ce calcul retourne le reste de cette division (donc un entier également).
Par exemple 1 % 3 = 1 car 1 / 3 = 0 et il reste 1
Ceci est très pratique lorsque l’on doit faire quelque chose de particulier toutes les X itérations.

Conclusion

Nous avons pu obtenir la liste de nos articles sur 2 colonnes sans utiliser inutilement de ressources supplémentaires. Autre avantage de cette technique : elle respecte le réglage du nombre de posts à afficher dans le tableau de bord de WordPress.

Happy coding :)

Le problème

Pour pouvoir faire de l’upload il faut déclarer les types de fichiers acceptés dans son controlleur (ou dans un fichier de config) à l’aide de la déclaration

$config['allowed_types'] = 'gif|jpg|png|zip';

Lors de la soumission du formulaire contenant le fichier a envoyer, le navigateur envoi un mime type au serveur correspondant au type de fichier que l’on souhaite uploader. CodeIgniter va ensuite confronter ce mime type avec ceux qui sont autorisés et agir en conséquence.

Le problème vient du fait que les navigateurs n’envoyent pas tous le même mime type pour les fichiers ZIP et, après recherche, il s’avère qu’il en existe 7 différents. Hors CodeIgniter n’en prend en charge que 3. Donc si votre navigateur envoi l’un des 4 types non répertoriés, l’upload échoue avec un magnifique message d’erreur : « The filetype you are attempting to upload is not allowed. »

La solution

Il suffit d’éditer le fichier application/config/mimes.php en ajoutant les mime types manquants à la ligne correspondant à votre type de fichier. Dans le cas d’un fichier ZIP il s’agit de la ligne 54 :

'zip'	=>  array('application/x-zip', 'application/zip', 'application/x-zip-compressed'),

qu’il faut changer en

'zip'	=>  array('application/x-zip', 'application/zip', 'application/x-zip-compressed','application/octet-stream','application/x-compress','application/x-compressed','multipart/x-zip'),

Et tout rentre dans l’ordre :)

Ajouter d’autre mime types

Si vous deviez ajouter de nouveaux types de fichiers à la liste des fichiers autorisés ou qu’un type existant posait le même problème que pour les ZIP, il suffit de faire un simple

var_dump($_FILES)

et de repérer le résultat de ["file_type"] dans l’array retourné. C’est cette information qu’il faudra ajouter au fichier application/config/mimes.php.

Pourquoi commenter ?

Les intérêts sont multiples et variés allant du simple « j’en suis là » à la fin de la journée jusqu’à la documentation d’une application.

Commenter pour comprendre ce qu’on a fait

Lors d’une session de développement on est souvent confronté à un problème nouveau à gérer et la solution n’est pas forcément toujours évidente. On fait quelques recherches, on trouve une solution ou l’inspiration pour la créer et on l’intègre. Tout fonctionne, c’est parfait, on est content.
3 mois plus tard on doit revenir dessus car il faut améliorer la fonction en y intégrant de nouveaux paramètres ou s’en resservir pour un autre projet, et là c’est le drame : on ne comprend plus comment ça fonctionne, voire même à quoi sert ladite fonction… Les 30 secondes nécessaires à écrire les quelques commentaires salutaires nous auraient permises d’éviter une décapilarisation crânienne subite et la perte de pas mal de temps.

Commenter pour expliquer aux autres

On peut travailler en équipe sur un projet et d’autres développeurs risquent d’avoir à intervenir sur votre code pendant que vous faites autre chose. Autre cas de figure : vous développez seul un projet puis un peu plus tard c’est un autre développeur qui le reprend ou qui vous rejoin dessus. Vous pouvez également être en train de développer un script/module/librairie/application destiné(e) à être partagé(e) avec d’autres (dans le cadre d’open source par exemple).
Encore une fois, le temps passé à commenter le code évitera aux autres d’être complètement perdus à la lecture de votre chef d’oeuvre. Ceci est d’autant plus vrai que chaque développeur a son style et sa manière de coder et qui, bien souvent, n’est limpide que pour lui-même…

Commenter pour se faciliter la tâche

Les IDE de qualité sont capable de lire les commentaires DocBlock et de s’en servir pour afficher, lors de la saisie, les informations d’utilisation que vous avez pris le soin d’entrer. Dans le cadre du développement d’une application répartie en plusieurs fichiers (souvent le cas en POO ou en utilisant un framework), les commentaires révèlent toute leur puissance en vous évitant de replonger dans le code d’une fonction pour retrouver quels arguments lui passer ou encore ce qu’elle retourne.
Ce type de commentaire peut aussi être utilisé pour l’écriture automatique de la documentation d’une API, par exemple, à l’aide d’un générateur de documentation tel que PHPdocumentor ou Doxygen

Les différents types de commentaires

Il existe 3 types de commentaires : ligne simple, multiligne et DocBlock. Les 2 premiers ne servent qu’à indiquer des informations courtes au sein même du code alors que le DocBlock permettra aux IDE et générateurs de documentation d’en faire bien plus.

Les commentaires simples et multilignes se présentent de la manière suivante :

// je suis un commentaire sur une seule ligne
/* je suis
un commentaire
sur plusieurs lignes */

Le commentaire DocBlock se présente ainsi :

/**
 * Cette fonction sert à faire ceci...
 * un commentaire
 * sur plusieurs lignes
 *
 * @param string $text Description du paramètre
 * @param int $id Description du paramètre
 * @return bool Description de ce que retourne (ou non) la fonction
*/

Notez l’utilisation de certains mots clés (@param, @return) dont vous trouverez la liste complète ici. C’est précisément ces mots-clés qui permettrons à l’IDE et au générateur de documentation de travailler.

Un exemple d’utilisation

Voici un petit exemple d’utilisation des 3 types de commentaires dans un modèle du framework CodeIgniter :

<?php

class Blog_model extends CI_Model {

	// constructeur
	function __construct() {
		parent::__construct();
	}

	/**
	 * Recupération des derniers posts de wordpress
	 *
	 * @param	int $count	Le nombre de posts que l'on veut afficher (optionnel)
	 * @return	object		Les posts à afficher
	 */
	function get_latest_posts($count = 5) {
		// requete mysql à l'aide d'ActiveRecord
		$this->db->select('post_title, post_name');
		$this->db->where('post_status', 'publish');
		$this->db->where('post_type', 'post');
		$this->db->limit($count);
		$this->db->order_by('ID', 'desc');

		$query = $this->db->get('wp_posts');
		
		/* on récupère les posts
		sous forme d'objet */
		$data = $query->result();

		//var_dump($data); exit; // test des résultats obtenus
		
		// renvoi des résultats au controlleur
		return $data;
	}

}

J’ai eu la main un peu lourde ici mais en même temps il vaut mieux trop de commentaires que pas assez !

Conclusion

Il y a peu de temps j’ai eu l’occasion d’intervenir sur un gros projet de CRM/ERP qui était quasiment abouti et dont le développeur a du se retirer. Malheureusement il n’avait pas jugé utile de commenter son code et la conséquence directe à été une grosse perte de temps pour moi (le temps de comprendre le fonctionnement) et une grosse perte de temps et d’argent pour le client car il a du supporter le coût de « temps de compréhension » du code existant en plus du temps de développement nécessaire au résultat demandé…
Pour faire bref, passez un peu de temps à commenter votre code – votre client, les utilisateurs de votre code et vous-même ne vous remercieront jamais assez !