Dix commandements de programmation de programmeurs

1.- DRY: Ne pas répéter.
DRY est l'une des lois les plus simples et la plus facile à comprendre.Mais il peut aussi être le plus difficile à appliquer (parce que pour ce faire, nous avons besoin de faire beaucoup de travail sur la conception générique, ce qui n'est pas facile).Cela signifie que lorsque nous trouvons un code similaire dans deux endroits ou plus, nous devons résumé leurs points communs dans une nouvelle méthode unique et changer le code dans l'endroit existant afin qu'ils puissent appeler cette nouvelle méthode avec certains paramètres appropriés.

LA LOI DE DRY EST PROBABLEMENT LA RÈGLE LA PLUS COURANTE DANS LA PROGRAMMATION, ET JUSQU'À PRÉSENT AUCUN PROGRAMMEUR NE L'A CONTESTÉE.Cependant, nous pouvons voir que certains programmes oublient cette règle lors de l'écriture des tests unitaires: nous allons ressembler, lorsque vous changez plusieurs interfaces d'une classe, si vous n'utilisez pas DRY, puis les programmes qui appellent l'interface d'une classe d'un cas, les deux doivent être modifiés manuellement.Par exemple : si vous n'utilisez pas une méthode standard de construction d'une classe dans de nombreux cas de test de test unitaire, mais chaque cas de test construit une instance de la classe elle-même, combien de cas de test vous devez modifier lorsque le constructeur de la classe est modifié.C'est la conséquence de ne pas utiliser la règle DRY.

2.- Méthode courte.
À tout le moins, voici trois bonnes raisons pour les programmeurs d'écrire des moyens courts.

Le code devient plus facile à lire.
Code devient plus facile à réutiliser (méthodes courtes peuvent réduire le degré de couplage entre le code)
Le code devient plus facile à tester.
3.- Bonnes pratiques de dénomination
L'utilisation d'une bonne spécification de nommage uniforme peut rendre votre programme plus facile à lire et à maintenir, quand une classe, une fonction, un nom variable atteint le royaume qui peut être "wangwen" état, nous pouvons avoir moins de documents, moins de communication.L'article "The Named Design in Programming" peut vous donner quelques conseils.

4.- Donner à chaque classe les bonnes responsabilités
Une classe, une responsabilité, et de telles règles peuvent se référer aux règles SOLID de la classe.Mais ce que nous mettons l'accent ici n'est pas une seule responsabilité, mais une bonne responsabilité.Si vous avez une classe appelée Client, nous ne devrions pas laisser cette classe avoir une méthode de vente, nous ne pouvons laisser cette classe avoir une méthode qui se rapporte le plus directement au client.

5.- Organiser le code
Il existe deux niveaux d'organisation du code.