Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (13)
Similaire à Clean code
Similaire à Clean code (20)
Clean code
- 1. CLEAN CODE Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.
- 2. Vue d’ensemble • Noms significatifs • Fonction • Commentaire • Objets et structures de données • Gestion des erreurs • SOLID • Test unitaire • Emergence 2
- 3. Pourquoi clean code • Simple et direct • Élégant • Efficace • Lisible • Facile à améliorer • Pas de doublons 3
- 4. Noms significatifs • Pourquoi existent-t-ils? • Qu'est-ce qu'ils font ? • Comment sont-ils utilisés? 4
- 5. Noms significatifs Évitez d'utiliser le même mot Choisir un mot par concept Faire des distinctions significatives Utiliser des noms prononçables Utiliser des noms consultables Éviter les encodages Éviter la cartographie mentale 5
- 6. Les Fonctions • Coeur des programmes. • « La première règle des fonctions est qu'elles doivent être petites ». • La forte cohésion. • Le nombre idéal d'arguments est Zéro • Pas d'effets secondaires. • Préférer les exceptions. • Plus que trois arguments ne doivent pas être utilisés. 6
- 7. Les Fonctions Préférer une exception que retourner un message d'erreur 7
- 8. Les Fonctions - Pas d'effets secondaires 8
- 10. Commentaires • Commentaires API publics • Commentaires légaux • Explication de l'intention • Avertissement pour les conséquences • real TODO Commentaires • Commentaires redondants • Commentaire bruyant • Marqueurs de position • Code commenté • Commentaires obsolètes 10
- 11. Commentaires • Le seul commentaire vraiment bon est le commentaire que vous avez trouvé un moyen de ne pas écrire. 11
- 12. Objets et structures de données • Exprimer nos données en termes abstraits • La différence entre les objets et les structures de données : Les objets cachent leurs données derrière des abstractions et exposent les fonctions qui fonctionnent sur ces données. Les structure des données exposent leurs données et n‘ont aucune fonction significative. 12
- 13. Objets et structures de données - La loi de Demeter - Une méthode f d'une classe C devrait seulement appeler les méthodes de : - C - Un objet créé par f - Un objet passé comme argument à f - Un objet détenu dans une variable d'instance de C 13
- 14. Gestion des erreurs • Utilisation des exceptions. • Définir des classes d'exception • Ne Jamais retourner Nul 14
- 15. SOLID • Single responsibility principle • Open/closed principle : Abstraction Polymorphisme. • Liskov substitution principle • Interface segregation principle • Dependency inversion principle Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions. Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions. 15
- 16. Test Unitaire • Les trois lois de TDD : 1. Ecrire un test qui échoue avant d’écrire tout code de production 2. Ne pas écrire plus d’un test suffisant pour échouer, ou qui échouera à la compilation 3. Ne pas écrire plus de code que nécessaire pour faire passer le test en cours 16 Cela évite souvent des erreurs de conception dues à une précipitation dans l'implémentation avant d'avoir défini les objectifs.
- 17. Test Unitaire • F.I.R.S.T les principes de test unitaire: 1. Fast 2. Independent 3. Repeatable 4. Self-Validating 5. Timely 17
- 18. Emergence Règles 4: Classes et méthodes minimales Règle 3: Expressive Règle 2: pas de duplication Règle 1: Exécute tous les tests 18
- 19. Autre Conseils • N’écrivez pas de Singleton ! Mettez en place l’injection de dépendances Et gérez la durée de vie de vos objets • Ne pensez pas héritage, pensez polymorphisme Sinon : "a un" au lieu de "est un“ • Ne pensez pas "switch/if", pensez polymorphisme Design Pattern strategy • Un code non testé n’est pas maintenable 19
Notes de l'éditeur
- Robert Cecil Martin (familièrement connu sous le nom de Oncle Bob) est un ingénieur logiciel américain et auteur, La mission de cette série est d'améliorer l'état de l'art de l'artisanat logiciel. Les livres de cette série sont techniques, pragmatiques et substantiels.
- Les noms de variables, de fonctions ou de classes doivent répondre à toutes les grandes questions:
- Noms des classes Nom des méthodes Ne soyez pas mignon Évitez d'utiliser le même mot Ajouter un contexte significatif
- What we call them: functions, methods, modules La forte cohésion : FONCTIONS DOIVENT FAIRE UNE CHOSE. IL DEVRAIT LE FAIRE BIEN. ILS DOIVENT LE FAIRE SEULEMENT. Un niveau d'abstraction par fonction Nom reflète la seule tâche qu'il accomplit Lorsqu'une fonction semble avoir besoin de plus de deux ou trois arguments, il est probable que certains de ces arguments doivent être enveloppés dans une classe de leur propre. Considérons, par exemple, la différence entre les deux déclarations suivantes: Réduire le nombre d'arguments en créant des objets hors d'eux peut sembler tricher, mais ce n'est pas le cas.
- L'effet secondaire est l'appel à Session.initialize (), bien sûr. La fonction checkPassword, par son nom, indique qu'elle vérifie le mot de passe. Le nom n'implique pas qu'il initialise la session. Ainsi, un appelant qui croit que le nom de la fonction dit courir le risque d'effacer les données de session existante quand il ou elle décide de vérifier la validité de l'utilisateur. Cet effet secondaire crée un couplage temporel. C'est-à-dire, checkPassword ne peut être appelé qu'à certains moments (en d'autres termes, quand il est sûr d'initialiser la session). Si elle est appelée hors service, les données de session peuvent être perdues par inadvertance. Les couplages temporels sont déroutants, surtout lorsqu'ils sont cachés comme effets secondaires. Si vous devez avoir un couplage temporel, vous devriez le préciser au nom de la fonction. Dans ce cas, nous pouvons renommer la fonction checkPasswordAndInitializeSession, bien que cela viole certainement "Do one thing."
- Le but d'un commentaire est d'expliquer le code qui ne s'explique pas. " Les commentaires ne compensent pas le mauvais code N'utilisez pas de commentaire lorsque vous pouvez utiliser une fonction ou une variable Les commentaires peuvent contenir des mensonges
- Gardez à l'esprit, cependant, que
- Il y a une raison pour que nous gardions nos variables privées. Nous ne voulons pas que d'autres dépendent d'eux. Nous ne voulons pas exposer les détails de nos données, Nous voulons plutôt Ce n'est pas seulement accompli en utilisant des interfaces et / ou getters et setters. La pensée sérieuse doit être mise de la meilleure façon de représenter les données qu'un objet contient. La pire option est d'ajouter joyeusement getters et setters.
- Le code 3 suivant semble violer la loi de Demeter parce qu'il appelle la fonction getScratchDir () sur la valeur de retour de getOptions () et appelle getAbsolutePath () sur la valeur de retour de getScratchDir ().
- Single responsibility principle Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class doit être à la fois ouverte (à l'extension) et fermée (à la modification). « Ouverte » signifie qu'elle a la capacité d'être étendue. « Fermée » signifie qu'elle ne peut être modifiée que par extension, sans modification de son code source. L'idée est qu'une fois qu'une classe a été approuvée via des revues de code, des tests unitaires et d'autres procédures de qualification, elle ne doit plus être modifiée mais seulement étendue. Si S est un sous-type de T, les objets de type T peuvent être remplacés par des objets de type S (Barbara Liskov in a 1987 ) Etat qu'aucun client ne doit être forcé de dépendre de méthodes qu'elle n'utilise pas
- Ces tests permettent aussi de préciser les spécifications du code. Ce qui facilite la production d'un code valide en toutes circonstances. On obtient donc un code plus juste et plus fiable, L'utilisation de TDD permet la construction conjointe du programme et d'une suite de tests de non-régression.
- Fonctionne rapidement Les tests ne doivent pas dépendre les uns des autres Les tests doivent être répétables dans n'importe quel environnement. Vous devriez être en mesure d'exécuter les tests dans l'environnement de production, Les tests doivent avoir une sortie booléenne. Soit ils passent ou échouent, Doit couvrir chaque scénario de cas d'utilisation et ne vise pas seulement à 100% de couverture. Doit essayer de viser Test Driven Development (TDD) de sorte que le code n'a pas besoin de refactoring plus tard.
- Et si il y avait quatre règles simples qu’on peut suivre qui pour nous aider à créer de bonnes conceptions? Et si ces quatre règles facilitent l'émergence de bonnes conceptions? Selon Kent, une conception est «simple» si elle suit ces règles: Vous pouvez vous exprimer en choisissant de bons noms. Vous pouvez également vous exprimer en gardant vos fonctions et classes de petite taille. Les petites classes et les fonctions sont généralement faciles à nommer, faciles à écrire et faciles à comprendre. Vous pouvez également vous exprimer en utilisant la nomenclature standard. votre conception à d'autres développeurs.