vendredi 1 octobre 2010

Développer une grosse application

Comment faire ? Voici quelques étapes conseils ... avec ruby on rails bien sûr.

Identifier les fonctions coeurs de métier
Cette première étape est à mon sens trés important. Déjà, elle permet de mettre en avant la priorité en termes de fonctions dans l'application. Elle permet de répondre aux questions : qu'est ce qui est important ? Quelle fonction a le meilleur ROI ? Quels sont les 20% de l'application qui vont apporter 80% de valeurs ?

Il n'y a pas de règles précises. Cependant, ces fonctions doivent s'appuyer sur un nombre restreint de table de base de données. Cela peut aller de 1 table à 4 ou 5 (ce qui fait 2 ou 3 entitées dans votre conception). Par exemple, Facebook, c'est un schéma de coeur de métier qui ressemble à ça :
- table utilisateurs
- table sont_amis
- table message_mur
- table commentaire
On voit bien que tout tourne autour de l'utilisateur, et que c'est bien cette entité qui a été choisi en premier. Les fonctions "périphériques" comme s'envoyer des messages, créer des événements, etc... ne sont pas dans le coeur de métier. Bref.


Go rails ! Générer le modèle
rails generate model user name:string prenom:string email:string sex:boolean hashed_password:string
rails generate model message_mur message:string date_message:date user:references
rails generate model sont_amis user:references user:references est_valide_boolean
rails generate model commentaire user:references message_mur:references commentaire:string date_com:date
rake db:migrate

Rails va générer des classes dans app/model : user.rb, message_mur.rb, etc...
Il faut rajouter les références avec :belongs_to ou :has_many.
Plus de détails sur les associations ...

Puis on peut ajouter quelques validations : validates_uniqueness_of, :validates_presence_of, :validates_format_of ....

Préparer des données tests
Comme argumenté dans un précédent post, avoir ses données tests dans la logique de migration de rails est cool :
rails generate migration add_test_data

Cette commande ne va pas générer des données pour vous, attention ! Cette classe va avoir deux méthodes qu'il faut coder : up et down. Cf ce précédent billet.

Plus de détails sur les migrations "standalone" ...

Ne pas scaffolder ni web2.0-iser
Scaffolder c'est bien pour impressionner sa GF sur la puissance de rails. En pratique, on ne l'utilise jamais vraiment. Il est préférable de mettre sur papier des user stories (ou use case, ou business case) simplissime sans fioriture web 2.0. Il faut d'abord avoir une appli web1.0 solide robuste etc... pour ensuite la transformer en web2.0 : c'est bien plus facile, c'est bon pour les débutants, et une fois que l'appli web1.0 est validée, débuggée, et sa couverture fonctionnelle des besoins est de 100%, c'est cadeau de passer au web 2.0.

Web1.0 c'est une action par page (éh oui ça fait mal ça) et pas d'ajax (forcément).

Générer les controller
Typiquement, en reprenant le coeur de métier facebook :
rails generate controller profil index new-comment voir-commentaires-message
rails generate controller un-ami index commenter voir-commentaires-message supprimer-ami voir-ses-amis
rails generate controller chercher index resultat
rails generate controller home index creer-compte recup-mdp logout

Voila en exemple, rapidement, ce qu'un controller pourrait donner pour permettre aux utilisateurs d'intéragir à la Facebook. Le lecteur avisé constatera que scaffolder (en remplacant les generate model par generate scaffold) va créer une structure de controller totalement différente, qui sera orientée CRUD et non pas utilisation réelle.

Mais là, je n'ai pas forcément raison.

Rails promeut "Convention over Configuration". C'est à dire avoir un controller du nom de son modèle (avec un "s") facilite le routage. Ensuite, le nom des controllers dans la bare d'URL peut être renommé.


Coder un controller à la fois
Bon là, pas de miracles. J'avoue. IMHO, commencer par coder le premier controller (typiquement home index).
"generate controller" crée également des .html.erb => c'est idéal pour respecter le non scaffoldage et non web2.0-age.

Bref cette étape est la plus longue, classiquement, c'est le coeur du développement. Rails raccourci grâce à plein de méthodes, et surtout, rend fun. Si vous êtes débutant, je conseille ce trés bon bouquin. Il n'y a pas encore de nouvelle édition pour rails3.0. Cependant, le lecteur avisé (encore!) s'y retrouvera. Sinon il y a toujours ce guide officiel pour rails 3.0.

Fonctionner par itération
Rails est magiquement trés pratique pour le développement itératif. Pourquoi ? Déjà, le code source, même en faisant n'importe quoi, est trés léger (il n'y en a pas beaucoup). Cela devient facile de s'y repérer. Un changement ? Pas grave ! Quelques lignes à supprimer, une migration de la base à effectuer, une partie d'un écran à refactoriser en partial...

Refactoriser
DRY (Don't repeat yourself) est un concept mis en avant par rails mais qui en général, dans tout développement, est une best practice. Tout simplement, les bouts de codes qui font la même choses sont factorisés ailleurs ensemble.

Tester et faire tester
Il y a plusieurs types de tests :

  • Tests unitaires : tests de méthodes à l'intérieur d'une classe (sans ressources externes : autres classes, base de données, fichiers, ...)

  • Tests d'intégrations : tests unitaires avec ressources externes

  • Tests fonctionnels : test d'un cas métier, de plus haut niveau que le test unitaire

  • Tests d'acceptances utilisateurs : confrontation des utilisateurs

  • Tests de non régressions : aprés implémentations de nouveautés ou de changements, ces tests indiquent que les impacts sont couverts

  • Tests "du couloir" : prendre le premier étranger qui passe dans le couloir et le mettre devant l'application. Similaire au test UAT, sauf qu'ici, c'est un étranger.

  • TDD (qui n'est pas un test en soit, on est d'accord)
Déployer
Une fois l'application testé en developpement, il est temps de passer en production. Pour ça, pas de secret : il faut analyser vos besoins volumétriques, et en fonction, choisir une stratégie adaptée. A moins de vouloir être le nouveau Facebook, nul besoin de scalabilité, de 10 CPU etc...




Aucun commentaire:

Enregistrer un commentaire