Show Menu
Cheatography

Code Review Cheat Sheet (DRAFT) by

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Sonar

Est-ce que je me suis assurer qu'il n'y ait plus d'anom­alies dans Sonar dans les classes que j'ai ajoutées / modifiées ?
Est-ce que mon code respecte les standards de sécurité (owasp) ?
Est-ce que j'ai une couverture de code qui se rapproche de 100% ?

Standard Desjardins

J'utilise le français lorsque applicable et je vérifie la syntaxe
J'ai fait un squash de mes commits

Réflex­ivité

Est-ce que j'ai évité d'utiliser la réflexion ?
Peut briser l'enca­psu­lation, moins performant

DRY (Don't repeat yourself)

Éviter la duplic­ation à l'inté­rieur d'une même applic­ation

Accès

Est-ce que les classes, méthodes et propriétés ont l'accès minimal ?
Est-ce que tous les get et set sont nécess­­aires, avec les bons accès ?
Respecter l'enca­psu­lation, facilite les tests, diminue la duplic­ation

Utiliser les design patterns avec parcimonie

Utiliser les design patterns seulement pour régler un réel problème

Single Respon­sib­ility principle

Une classe devrait avoir une seule raison de changer
Robustesse du code, moins de bugs sur les autres fonctions. Une seule foncti­onn­alité testé avec un junit

Open-C­­losed principle

Une classe ne devrait plus être modifié, on devrait ajouter du code, pas modifier du code foncti­­onnel
Faciliter la mainte­nance du code et la réutil­isation

Liskov Substi­­tution principle

Si on vérifie un type d'objet, on ne respecte pas le principe
La sous-c­lasse doit pouvoir recevoir les mêmes types de paramètres que la superc­lasse. La sous-c­lasse devrait retourner le même type que la superc­lasse ou un objet parent du type. La sous-c­lasse doit lancer les mêmes exceptions ou les sous-type de l'exce­ption de la superc­lasse

Interface Segreg­­ation principle

Faire de petites interfaces au lieu de grosses
Éviter que l'inte­rface ne devienne trop spécifique et non réutil­isable

Dependency Inversion principle

Utilise des interfaces au lieu de classes
Permet de diminuer les impacts quand on change l'impl­éme­ntation et facilite les tests

Récurs­ivité

Est-ce que j'ai évité d'utiliser la récursion s'il y a une meilleure façon de faire ?
Difficile à débuguer, moins performant

Singleton

Une seule instance de classe par jvm nécessaire
Éviter que plusieurs threads exécutent le même code au même moment, ie façade et gestio­nnaire d'accès

Strategy Pattern

Permet de sélect­ionner un algorithme à l'exéc­ution
Éviter d'avoir des conditions à plusieurs endroits pour vérifier l'algo­rithme à exécuter

Factory Pattern

Chain of Respon­sib­ility Pattern

Permet de définir une série d'objets qui peuvent répondre à une requête selon des conditions fixées à l'exéc­ution, ou de déléguer la suite du traitement à un autre objet de la série
ie Filter

Template Method Pattern

Définit le squelette d'un algori­thme, en déléguant certaines parties de l'algo­rithme à des sous-c­lasses
Éviter d'avoir de la duplic­ation dans des composants similaires

State Pattern

Permet de changer l'exéc­ution d'un objet selon son état interne
Éviter succession de if dans le code

Adapter Pattern

Permet de convertir l'inte­rface d'une classe en une autre interface attendu
Permet d'accéder à des foncti­onn­alités non dispon­ibles dans l'api courant

Decorator Pattern

Ajouter des respon­sab­ilités à un objet dynami­que­ment. Aussi appelé wrapper
 

Builder pattern

Permet d'éviter la multip­lic­ation des constr­ucteurs lorsqu'il y a des paramètres optionnels

Support Cheatography!