test de saisi sur mon blog avec live writer.
samedi 3 août 2013
mardi 14 février 2012
jeudi 8 décembre 2011
L'Extreme Programming
L'Extreme Programming (XP) est un processus de développement logiciel, c'est-à-dire un ensemble de pratiques destinées à organiser le travail d'une équipe de développement. Ces pratiques se focalisent sur la construction proprement dite du logiciel, en aval des phases préparatoires d'études d'opportunité ou de faisabilité.
XP propose une réponse originale à ces questions, avec un ensemble de pratiques organisées autour des principes suivants :
- Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines).
- L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des développements.
- L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses membres.
- L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au produit un niveau de robustesse très élevé.
- Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides.
L'objectif de ce dossier est de donner une vision d'ensemble des principes et des pratiques d'XP, en commençant par ce qui fait son agilité : l'ouverture au changement.
mercredi 7 décembre 2011
Atelier :Bonnes pratiques objet en .net : Introduction aux principes SOLID
I. Introduction
I - B. Couplage=--------
Le couplage est une métrique qui mesure l'interconnexion des modules. Deux modules sont dit couplés si une modification d'un de ces modules demande une modification dans l'autre.
I - C. Encapsulation :+++++++
L'idée derrière l'encapsulation est d'intégrer à un objet tous les éléments nécessaires à son fonctionnement, que ce soit des fonctions ou des données.
Le corolaire est qu'un objet devrait (et non pas doit, comme c'est souvent expliqué) masquer la cuisine interne de la classe, pour exposer une interface propre, de façon à ce que ses clients puissent manipuler l'objet et ses données sans avoir à connaitre le fonctionnement interne de l'objet.
II. Responsabilité unique (SRP: Single Responsibility Principle)
SOLID est l'acronyme de cinq principes de base (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle et Dependency Inversion Principle) que l'on peut appliquer au développement objet.
I - B. Couplage=--------
Le couplage est une métrique qui mesure l'interconnexion des modules. Deux modules sont dit couplés si une modification d'un de ces modules demande une modification dans l'autre.
I - C. Encapsulation :+++++++
L'idée derrière l'encapsulation est d'intégrer à un objet tous les éléments nécessaires à son fonctionnement, que ce soit des fonctions ou des données.
Le corolaire est qu'un objet devrait (et non pas doit, comme c'est souvent expliqué) masquer la cuisine interne de la classe, pour exposer une interface propre, de façon à ce que ses clients puissent manipuler l'objet et ses données sans avoir à connaitre le fonctionnement interne de l'objet.
II. Responsabilité unique (SRP: Single Responsibility Principle)
Le principe de responsabilité unique, est qu'une classe donnée ne doit avoir qu'une seule responsabilité, et, par conséquent, qu'elle ne doit avoir qu'une seule raison de changer.
Les avantages de cette approche sont les suivants:
-Diminution de la complexité du code
-Augmentation de la lisibilité de la classe
-Meilleure encapsulation, et meilleure cohésion, les responsabilités étant regroupées
pour l’appliquer il faut Analyser et regrouper des méthodes du code puis en sortir des classes
II. Ouvert/fermé (OCP: Open/closed Principle)
-Les modules qui se conforment au principe ouvert/ferme ont deux attributs principaux. 1 - Ils sont "ouverts pour l'extension". Cela signifie que le comportement du module peut être étendu, que l'on peut faire se comporter ce module de façons nouvelles et différentes si les exigences de l'application sont modifiées, (hériter de la classe d'origine)
2 - Ils sont "Fermés à la modification". Le code source d'un tel module ne peut pas être modifié. Personne n'est autorisé à y apporter des modifications.«
Voir Exemple
III. Substitution de Liskov (LSP: Liskov Substitution Principle)
-Les sous-types doivent être remplaçables par leur type de base SANS CAST.
Principe de Polymorphisme on POO.
Voir Exemple
IV. Séparation des Interfaces (ISP: Interface Segregation Principle)
-Les clients ne doivent pas être forcés de dépendre d'interfaces qu'ils n'utilisent pas.
Les interfaces doit être le moins compliquée.
Modèle ISP
V.Inversion des dépendances (DIP: Dependency Inversion Principle)
Les architectures classiques ne permettent pas la réutilisation des modules "métier"
Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "métier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication)
Les modules de haut niveau doivent être modifiés lorsque les modules de bas niveau sont modifiés.
Selon le principe d'inversion des dépendances
, la relation de dépendance doit être inversée : les modules de bas niveau doivent se conformer à des interfaces définies et utilisées par les modules de haut niveau.
Vers des Framework métier ?
Ce principe conduit à des applications dans lesquelles la logique "métier" est parfaitement réutilisable. Cette partie métier forme une sorte de "framework", qui permet de développer une même application dans des contextes techniques différents.(sfeir Tools bon exemple, edition EML )
mercredi 20 juillet 2011
mardi 7 juin 2011
Exemple de migration d’application web ASP.net vers Azure
Le numéro de Juin du magazine Programmez ! est disponible et Avec un article, qui présente succinctement la migration d’une application ASP.net vers Windows Azure qui présente migration de l’application
Open Source nopCommerce pour la rendre “Azurée”.
Plus d’infos voila le lien de l'article
vendredi 3 juin 2011
projets Régie ou forfaits
Les différences pour un développeur sont :
* Forfait : le projet se déroule en général dans les locaux de ton employeur (et non pas du client). Tu travailles avec les personnes de ta SSII et non pas directement chez le client. Les projet sont en général plus tendu (si le projet prend du retard, ta boite perd de l'argent. Si le projet a de l'avance, ta boite gagne de l'argent car ils te feront bosser sur autre chose -> ta boite va tout faire pour que le projet aille le plus vite possible). Le forfait est très formateur, il permet également de montrer à ton employeur ce que tu vaux. Par contre, la dimension métier est souvent amoidrie et tu bosses toujours au même endroit (ce qui supprime l'avantage des SSII qui bossent souvent en régie : rencontrer différentes personnes, travailler dans différents milieux, avec différentes méthodes...).
* Régie : le projet se déroule chez le client (en changeant de mission, on change de client, on a donc un panel important en terme de communication, méthode, techno...). La dimension métier est très importante (tu bosses directement avec les personnes qui ont le besoin. Tu es facturé au jour travaillé et non pas au travail réalisé, les projets peuvent donc être plus pèpères.
Les forfaits sont beaucoup plus rares, mais intéressants en terme de conduite de projet, technique... C'est une expérience à faire, mais c'est une erreur de ne faire que cela. Ils te permettront plus facilement d'évoluer vers un poste technique ou un poste de pilotage de projet (mais sans la dimension métier, c'est loin d'être simple).
Les régies sont très courantes (80% des projets infos) et t'apportent une adaptabilité et une connaissance métier très importantes (c'est surement les 2 choses les plus importantes dans notre métier).
* Forfait : le projet se déroule en général dans les locaux de ton employeur (et non pas du client). Tu travailles avec les personnes de ta SSII et non pas directement chez le client. Les projet sont en général plus tendu (si le projet prend du retard, ta boite perd de l'argent. Si le projet a de l'avance, ta boite gagne de l'argent car ils te feront bosser sur autre chose -> ta boite va tout faire pour que le projet aille le plus vite possible). Le forfait est très formateur, il permet également de montrer à ton employeur ce que tu vaux. Par contre, la dimension métier est souvent amoidrie et tu bosses toujours au même endroit (ce qui supprime l'avantage des SSII qui bossent souvent en régie : rencontrer différentes personnes, travailler dans différents milieux, avec différentes méthodes...).
* Régie : le projet se déroule chez le client (en changeant de mission, on change de client, on a donc un panel important en terme de communication, méthode, techno...). La dimension métier est très importante (tu bosses directement avec les personnes qui ont le besoin. Tu es facturé au jour travaillé et non pas au travail réalisé, les projets peuvent donc être plus pèpères.
Les forfaits sont beaucoup plus rares, mais intéressants en terme de conduite de projet, technique... C'est une expérience à faire, mais c'est une erreur de ne faire que cela. Ils te permettront plus facilement d'évoluer vers un poste technique ou un poste de pilotage de projet (mais sans la dimension métier, c'est loin d'être simple).
Les régies sont très courantes (80% des projets infos) et t'apportent une adaptabilité et une connaissance métier très importantes (c'est surement les 2 choses les plus importantes dans notre métier).
__________________
Inscription à :
Articles (Atom)