En génie logiciel, les code smells ou mauvaises odeurs peuvent être de mauvaises pratiques de conception logicielle qui conduisent à l’apparition de défauts. Ces défauts sont souvent issus de mauvais choix d’implantation ou de conception et conduisent à une complexification du code source et de la maintenance et évolutivité de celui‐ci. À la différence d'un AntiPattern, les code smells ne sont pas forcément des erreurs, c'est-à-dire qu'ils peuvent persister sans perspective d'évolution dans un logiciel. Afin de corriger un code smell, il est nécessaire de procéder à un réusinage du code source, c’est‐à‐dire modifier le code sans en altérer son comportement.
À la manière des patrons de conceptions, de nombreux exemples de code smells ont été répertoriés et décrits dans la littérature scientifique.
Martin Fowler en a notamment répertorié des dizaines ainsi que la refactorisation à adopter.
L’anti‐patron Duplicated Code est un exemple de code smell classique. Il s’agit de trouver la même portion de code à plusieurs endroits d’une application.
La duplication de code peut se situer dans une même classe, au sein de méthodes différentes, ou dans des classes différentes.
L’anti‐patron Feature Envy décrit une méthode qui fait de nombreux appels à des méthodes d’autres classes. Le plus souvent ces appels sont faits à des getters (ou accesseurs) par besoin de données.
C’est le signe que la méthode se trouve probablement dans la mauvaise classe.
Aussi connu sous le nom de God Class ou Winnebago, l’anti‐patron Blob est une classe ayant trop de responsabilités au sein du logiciel.
Cela se manifeste par un trop grand nombre d’attributs et de dépendances aux classes data, ainsi qu’un nombre d’appels de ces méthodes par les classes extérieures très important.
L’anti‐patron Long Parameter List est une erreur héritée des débuts de la programmation, avant l’arrivée de l’orienté objet. Chaque fonction nécessitait toute une série de paramètres, qu’il était préférable d’utiliser à la place des variables globales.
Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.
We learn and apply software engineering principles to program projects in Python. Projects cover problems in life sciences, and will be developed over the course of the semester.
La duplication de code en programmation informatique est une erreur courante de conception de logiciels où une suite d'instructions similaires (voire identiques) existe en plusieurs endroits du code source d'un logiciel. La duplication de code arrive à la suite de la programmation par copier-coller. C'est une erreur classique de débutants en programmation informatique ; cependant, cette erreur touche également les développeurs confirmés. Le code dupliqué pose des problèmes de maintenance dont l'importance augmente avec la quantité de code dupliqué.
Le réusinage de code est l'opération consistant à retravailler le code source d'un programme informatique – sans toutefois y ajouter des fonctionnalités ni en corriger les bogues – de façon à en améliorer la lisibilité et, par voie de conséquence, la maintenance, ou à le rendre plus générique (afin par exemple de faciliter le passage de simple en multiple précision) ; on parle aussi de « remaniement ». Cette technique utilise quelques méthodes propres à l'optimisation de code, avec des objectifs différents.
L’architecture logicielle décrit d’une manière symbolique et schématique les différents éléments d’un ou de plusieurs systèmes informatiques, leurs interrelations et leurs interactions. Contrairement aux spécifications produites par l’analyse fonctionnelle, le modèle d'architecture, produit lors de la phase de conception, ne décrit pas ce que doit réaliser un système informatique mais plutôt comment il doit être conçu de manière à répondre aux spécifications. L’analyse décrit le « quoi faire » alors que l’architecture décrit le « comment le faire ».
The potential of automatic code generation through Model-Driven Engineering (MDE) frameworks has yet to be realized. Beyond their ability to help software professionals write more accurate, reusable code, MDE frameworks could make programming accessible fo ...
With the widespread deployment of Control-Flow Integrity (CFI), control-flow hijacking attacks, and consequently code reuse attacks, are significantly more difficult. CFI limits control flow to well-known locations, severely restricting arbitrary code exec ...
We investigate the properties of electronic states and optical transitions in hexagonal GaAs quantum dots within Al0.3Ga0.7As nanowires, grown in axial direction [111]. Such dots are particularly interesting due to their high degree of symmetry. A streamli ...