Développement web : de quoi a-t-on besoin et que devons-nous faire ?
On ne bidouille plus.
L'époque où l'on codait des sites à la mode de Grand-Papa dans tout un bric à brac de fichiers comprenant tous du HTML, des scripts PHP (ou autre), des requêtes BDD, etc. est révolue. Allez, souvenons-nous :
Extrait d'un livre d'or en PHP, « ancienne mode »…<?
if($reqlivr<>0 && $reqlivr<>1) //cas où le paramètre est erronné
$reqlivr=0;
if($reqlivr==0)
{
require ("../common/connexion.php");
$sql = mysql_query("SELECT * FROM livre ORDER BY Date DESC");
?>
<div align="left"><font face="Verdana" size="2"><br>Bienvenue dans notre livre d'or !<br>
N'hésitez pas à laisser ici vos impressions concernant le site et l'entreprise !
<p align="left"><font face="Verdana" size="2"><font face="Verdana" size="2"><a href="?pg=15&reqlivr=1">Cliquez
ici</a> pour rédiger un message...</font></font></p>
<p align="justify">
<?
while($valeurlud = @mysql_fetch_array($sql))
{
?>
<table border="1" cellspacing="0" style="border-collapse: collapse" width="100%" cellpadding="0" id="AutoNumber1">
<tr>
<td width="100%" background="../images/fond_livre.jpg"><font face="Trebuchet MS" size="2" color="#000000">
<?
echo '<b> '.$valeurlud["Expediteur"].'</b>';
if($valeurlud["Mail"]<>"")
echo ' (<a href="mailto:'.$valeurlud["Mail"].'"><font color="#000000">'.$valeurlud["Mail"].'</font></a>)';
echo ', <font size="1">'.Date_Explicite($valeurlud["Date"]).'</font>';
?>
</font></td>
</tr>
etc.
Besoin d'applications robustes et maintenables
Pour déployer une application ou un site web qui tienne la route et qui soit maintenable dans le temps, par différentes équipes, il est primordial de le faire selon des pratiques éprouvées, génériques et partagées.
Les design patterns, notamment (mais pas exclusivement), nous aident en ce sens.
Un exemple très répandu aujourd'hui est le MVC : Model/View/Controller, que nous verrons en détails un peu plus tard sur la page Design patterns et bonnes pratiques : MVC. Il permet notamment aux équipes de développement de déléguer la création des vues/templates à d'autres équipes, que l'on appelle souvent « intégrateurs » ou designers.
Les frameworks comme Django implémentent ce genre de design pattern et bonnes pratiques, et favorisent leur bonne utilisation.
Besoin de performance
Les applications et sites web doivent être rapides. Pour les gens qui les utilisent d'abord (c'est un des point mesurés quand on parle de UX : User eXperience). Pour les robots indexeurs ensuite.
Le problème, c'est qu'un site ou application réalise beaucoup de requêtes, sur des bases de données contenant beaucoup d'informations. Les SGBD ont réalisé d'énormes progrès en matière de gestion de la charge, et leur paramétrage subtil, généralement œuvre d'ingénieurs spécialisés, peut aussi aider.
N'en reste pas moins que la plupart des sites importants doivent par exemple, en plus de ces optimisations, réaliser une gestion de cache efficace.
Les frameworks web permettent de gérer efficacement le cache d'un site ou d'une application.
Le code métier d'abord
Écrire des requêtes SQL, c'est intéressant. Surtout quand on aime le SQL, et que l'on veut devenir DBA par exemple (DataBase Administrator). Les développeurs sont rarement très enjoués à l'idée d'écrire des requêtes SQL, et préfèrent manipuler leurs objets métier, directement. Les framework web incluent généralement à cet effet des outils d'ORM (Mapping objet-relationnel), qui permettent d'écrire du code objet et de manipuler les données sous-jacentes directement en appelant des méthodes de ces objets. C'est plus pratique, et surtout ça permet, dans une certaine mesure, d'instaurer une couche d'abstraction par rapport au SGBD.
Tout un tas d'autres choses doivent être programmées pour s'assurer du bon fonctionnement d'une application web, mais leur développement est parfois très rébarbatif et assez éloigné des préoccupations métier de l'application : authentification, gestion des logs, etc. Plutôt que de recoder ces éléments à chaque nouveau projet, les frameworks fournissent des solutions génériques et adaptables.
Besoin d'écrire du code « qui marche », et surtout qui continue de marcher…
Les applications web ont cette particularité d'être très souvent mises à jour, car elles évoluent dans un écosystème très actif et changeant. Plus on fait de mises à jour sur une application, plus on risque de la casser : et oui, plus on travaille, plus on a de chances de faire des bêtises, seuls ceux qui ne font rien sont à l'abris…
Pour pallier ce problème, une seule solution : tester efficacement et systématiquement le code nouveau et déjà existant, avant chaque release, pour limiter les risques.
C'est là qu'interviennent les tests unitaires et tests d'intégration, qui sont très importants en développement web (comme ailleurs…).
Les frameworks de développeent web intègrent des frameworks de test, rendant le développement dirigé par les tests (TDD) possible et même agréable (si si !).
Besoin de développer vite
Sur le Web, tout va vite. Et on a très peu de temps à consacrer à coder des choses qui ont déjà été codées des millions de fois.
C'est par exemple le cas des interfaces de CRUD (Create, Read, Update and Delete) : on a toujours besoin d'interface d'administration de certaines parties de site, mais qui a envie de se farcir ce genre de développement aujourd'hui ? Une fois pour apprendre, mais pas plus !
Les frameworks web autorisent généralement le scaffolding (échaffaudage), c'est à dire la génération automatique des interfaces de CRUD, qui peuvent ensuite être surchargées par le programmeur.
Testez vos connaissances
- D'optimiser les temps de développement.
- De bénéficier de solutions génériques réutilisables à des problèmes connus.
- D'éviter les bugs.
Attention, framework ou pas, on peut produire de très jolis bugs (certains développeurs sont d'ailleurs très créatifs en la matière !). Qui dit framework ne dit pas systématiquement qualité du code…
- C'est contraire aux préconisations du design pattern MVC.
- Ça ne fonctionne simplement pas !
- C'est intéressant de regrouper tous les accès aux données dans les modèles, pour plus de cohérence et parce que c'est leur vocation !
- Ce n'est plus à la mode.
Ce n'est bien sûr pas une question de mode. MVC a plus de 30 ans, et est toujours utilisé partout dans le monde.
Tout ce qui se rapporte à la définition et au traitement des données manipulées par l'application doit être fait dans les modèles.
- Parce que les gens n'aiment pas attendre le chargement des pages.
- Parce qu'il n'est pas possible de gérer la mise en cache.
- Parce que les moteurs de recherche n'aiment pas attendre le chargement des pages.
- Parce que l'accès aux données est couteux en matière de perf, et que les applications web réalisent beaucoup d'accès aux données.