Livrables, normes et conventions de codage Flashcards
Parties prenantes
! Les développeurs
! Les analystes
! L’équipe d’exploitation
! L’équipe de réseautique
! L’équipe de maintenance
! Le bureau de projet
! Les responsables de la sécurité
! Les administrateurs de bases de données
! L’équipe d’assurance-qualité
! La direction
! Les utilisateurs
! Saisie de données
! Intelligence d’affaire
! Etc.
! Les différents commanditaires
! Le service des communications
! Le service de vérification interne
! Autres service
! Comptabilité
! Ressources humaines(formation), Etc.
! Les différents paliers de gouvernement
! Les agences de règlementation et de surveillance
! Les actionnaires
! Les clients
! Les fournisseurs
! Les partenaires externes
! Les vérificateurs
Les livrables de projet inclus :
– La documentation
– Le code source
– Les tests
– Les fichiers connexes ! JAR, SQL, ANT, etc.
– Les versions du logiciel
– Les dépendances et leurs versions
– Projet construit pour le déploiement
La documentation doit inclure:
– La documentation pour les développeurs
– La documentation pour les administrateurs
– Administrateur de systèmes, administrateur de base de données, administrateurs de sécurité, etc.
– La documentation pour les gestionnaires
– La documentation pour les utilisateurs
– Wiki du projet
– Les diagrammes du projet
– Etc.
Les différents documents utilisés durant le cycle
de développement du logiciel:
– Spécifications du logiciel
– Diagrammes de classes,
– Diagrammes de séquences,
– Schéma relationnel,
– Diagrammes de cas d’utilisation,
– etc.
Le code source doit suivre des normes et conventions de
codage
– un ensemble de règles à suivre
! pour uniformiser les pratiques de développement logiciel,
! diffuser les bonnes pratiques de développement
! éviter les erreurs de développement “classiques” au sein d’un groupe de
développeurs.
– s’articulent autour de plusieurs thèmes :
! Le nommage et l’organisation des fichiers du code source
! le style d’indentation
! Les conventions de nommage, ou règles de nommage
! Les commentaires et documentation du code source
! Recommandations sur la déclaration des variables
! Recommandations sur l’écriture des instructions, des structures de
contrôle et l’usage des parenthèses dans les expressions
! Recommandations sur la la gestion des erreurs.
Normes
! Le génie logiciel repose sur un ensemble de normes
au niveau international permettant de définir :
– le champ de connaissance et d’application.
– un processus normalisés
! Organismes principaux
– Institute of Electrical and Electronics Engineers (IEEE)
– International Organization for Standardization (ISO)
– Software Engineering Institute (SEI)
Les normes suggèrent une structure de base au
projet :
Ø Documentation et Méthodologie
Ø Adaptée selon le type projet
Ø Suggestion — pas d‘imposition ni d‘obligation
! Exemple de normes
– Software Engineering Body of Knowledge (SWEBOK Guide)
– Capability Maturity Model (CMM)
– ISO 29110 / ISO 12207 / ISO 15504
– IEEE Std. 730 / 828 / 829
Art de la programmation
! La programmation est un art où chaque
développeur possède :
– Sa propre personnalité
– Son propre esprit créatif
– Son propre style
Convention de codage
Formatage du code;
Formatage de la documentation dans le code;
Nomenclature;
! Tabulations vs Espaces
– Nombre d’espaces, tabulation
– Position des espaces
! Dans les parenthèses, après les mot-clés, etc.
! Accolades vs Indentation
– Nombre d’espaces d‘indentation
– Position des accolades
! Position des éléments vs ordre d‘apparition des
éléments
– La largeur des lignes de code
– La position des déclarations de variables
– La mise en page des commentaires
– L‘ordre d‘apparition des variables membres,
constructeurs, destructeurs, méthodes publiques, etc.
! Nomenclature vs Casse
– Le choix des noms des identifiants
! Choisissez des noms prononçables et significatifs.
! Facile a chercher - Pas de codification (notation hongroise - strName)
! Le plus important de la convention de codage,
! Impacte fortement la lisibilité du code
– Préfixes, suffixes, classes, variables, packages, la casse des identifiants
– Des verbes d’action pour commencer les noms des méthodes.
– Choix de la casse
! Point de discussion très fréquent
! Différent type
– camelCase
– PascalCase
– snake_case
– hyphen-case
Avantage
! Raisons d’utiliser une bonne convention de codage :
– Faits
! 80% du coût durant la vie d’un logiciel est lié à sa maintenance.
! Il est rare que la maintenance d’un logiciel soit effectuée durant
toute sa durée d’existence par la même personne qui a écrit le code.
– Conséquence
! Utiliser une bonne convention de codage améliore la capacité de
maintenance du code d’un logiciel.
! Si le code source est envoyé au client à la fin du projet, il doit être
fonctionnel et aussi bien structuré.
Avantage
! Améliorer la lisibilité, la cohérence et
l’homogénéité du code - Impact :
– plus facile à comprendre et à maintenir.
– plus facile de suivre et déboguer le code.
– plus facile de reprendre du code après une longue période d’arrêt.
– plus efficace les “code walkthroughs«
! On comprend mieux et plus rapidement ce que fait le
code.
Recommandations
! Rendre le code homogène.
– L’utilisation de plusieurs conventions de codage différents dans un même fichier ou ensemble de fichiers vont nuire à la lisibilité
– Uniformiser le code en n’adoptant qu’une seule convention de codage pour toute l’équipe
– Peu importe la convention de codage , tant que toute l’équipe suit le même standard
! Rendre le code clair et facile à lire.
– Organiser de façon logique vos fichiers et vos classes.
– Utiliser des lignes avec un nombre limité de caractères.
– Utiliser judicieusement les espaces blancs, les tabulateurs et/ou tout autre séparateur.
! Utilisez des identifiants compréhensibles.
– Choisissez des noms significatifs.
! Établir et partager la norme de codification au sein de l’équipe
– Standard de programmation de l‘équipe \ Team coding convention
! Certains langages de programmation, comme Java, ont déjà un Standard de programmation prédéfinie.
! D’autres langages de programmation, comme C++, ont un Standard de programmation qui n’est pas normalisé, mais défini par les pratiques de l‘industrie.
