Discussion sur les méthodes de refactorisation du code PHP

Cet article présente principalement la méthode de refactorisation de code PHP et analyse en détail les concepts, principes, techniques de mise en œuvre associées et précautions de refactorisation de code PHP sous forme d'exemples. Les amis dans le besoin peuvent s'y référer

. Cet article analyse la méthode de refactorisation du code PHP avec des exemples. Partagez-le avec tout le monde pour référence, comme suit :

À mesure que PHP passe d'un simple langage de script à un langage de programmation mature, la complexité de la base de code d'une application PHP typique augmente également. Pour contrôler le support et la maintenance de ces applications, nous pouvons utiliser divers outils de test pour automatiser le processus. L'un d'eux est le test unitaire, qui vous permet de tester directement l'exactitude du code que vous écrivez. Cependant, les bases de code existantes ne sont souvent pas adaptées à ce type de tests. Cet article décrira les stratégies de refactoring pour le code PHP qui contiennent des problèmes courants afin de simplifier le processus de test avec les outils de tests unitaires populaires tout en réduisant les dépendances liées à l'amélioration de la base de code.

Introduction

En regardant l'histoire du développement de PHP, nous constatons qu'il a évolué à partir d'un simple script dynamique utilisé pour remplacer le populaire Scripts CGI à l'époque, le langage devient un langage de programmation moderne à part entière. À mesure que la base de code s'agrandit, les tests manuels sont devenus une tâche impossible et toutes les modifications de code, quelle que soit leur taille, ont un impact sur l'ensemble de l'application. Ces impacts peuvent être aussi minimes qu'affecter le chargement d'une certaine page ou l'enregistrement d'un formulaire, ou ils peuvent produire des problèmes difficiles à détecter, ou encore des erreurs qui ne se produisent que dans des conditions spécifiques. Cela peut même entraîner la réapparition de problèmes précédemment résolus dans l'application. De nombreux outils de tests ont été développés pour résoudre ces problèmes.

L'une des méthodes les plus populaires est le test dit fonctionnel ou d'acceptation, qui teste l'application à travers ses interactions utilisateur typiques. Il s'agit d'un excellent moyen de tester des processus individuels dans une application, mais le processus de test peut être très lent et ne parvient généralement pas à vérifier si les classes et méthodes sous-jacentes fonctionnent comme prévu. À l’heure actuelle, nous devons utiliser une autre méthode de test, à savoir les tests unitaires. L'objectif des tests unitaires est de tester la fonctionnalité du code sous-jacent de l'application et de garantir qu'il produit des résultats corrects après son exécution. Souvent, ces applications Web « en pleine croissance » introduisent lentement du code existant qui devient de plus en plus difficile à tester au fil du temps, ce qui rend difficile pour l'équipe de développement d'assurer la couverture des tests des applications. Ceci est souvent appelé « code non testable ». Voyons maintenant comment identifier le code non testable dans votre application et comment le corriger.

Identification du code non testable

Un domaine problématique concernant l'non-testabilité d'une base de code généralement rencontré lors de l'écriture de code n'est pas évident. Lors de l'écriture du code d'une application PHP, les utilisateurs ont tendance à écrire le code pour suivre le flux des requêtes Web, ce qui signifie généralement adopter une approche plus orientée processus pour la conception d'applications. La précipitation pour terminer un projet ou réparer rapidement une application peut inciter les développeurs à « rogner sur les raccourcis » afin de réaliser le codage rapidement. Auparavant, un code mal écrit ou confus pouvait exacerber les problèmes de non-testabilité dans une application, car les développeurs effectuaient souvent la solution la moins risquée, même si cela pouvait créer des problèmes de support ultérieurs. Ces zones problématiques ne peuvent pas être découvertes par les tests unitaires normaux.

Fonctions qui s'appuient sur l'état global

Les variables globales sont pratiques dans les applications PHP. Ils vous permettent d'initialiser certaines variables ou objets dans votre application puis de les utiliser ailleurs dans l'application. Cependant, cette flexibilité a un prix, et la surutilisation des variables globales est un problème courant avec le code non testable. Nous pouvons voir cela se produire dans le listing 1.

Listing 1. Fonctions qui dépendent de l'état global

<?php
function formatNumber($number)
{
  global $decimal_precision, $decimal_separator, $thousands_separator;
  if ( !isset($decimal_precision) ) $decimal_precision = 2;
  if ( !isset($decimal_separator) ) $decimal_separator = &#39;.&#39;;
  if ( !isset($thousands_separator) ) $thousands_separator = &#39;,&#39;;
  return number_format($number, $decimal_precision, $decimal_separator,
 $thousands_separator);
}

Ces variables globales soulèvent deux questions différentes. Le premier problème est que vous devez prendre en compte toutes ces variables globales dans vos tests, en vous assurant qu'elles sont définies sur des valeurs valides et acceptables pour la fonction. Le deuxième problème, le plus grave, est que vous ne pouvez pas modifier l'état des tests suivants et invalider leurs résultats. Vous devez vous assurer que l'état global est réinitialisé à l'état avant l'exécution du test. PHPUnit dispose d'outils qui peuvent vous aider à sauvegarder les variables globales et à restaurer leurs valeurs après l'exécution d'un test, ce qui peut vous aider à résoudre ce problème. Cependant, une meilleure approche consiste à permettre à la classe de test de transmettre les valeurs de ces variables globales directement aux méthodes. Le listing 2 montre un exemple de cette approche.

Listing 2. Modifiez cette fonction pour prendre en charge le remplacement des variables globales

<?php
function formatNumber($number, $decimal_precision = null, $decimal_separator = null,
$thousands_separator = null)
{
  if ( is_null($decimal_precision) ) global $decimal_precision;
  if ( is_null($decimal_separator) ) global $decimal_separator;
  if ( is_null($thousands_separator) ) global $thousands_separator;
  if ( !isset($decimal_precision) ) $decimal_precision = 2;
  if ( !isset($decimal_separator) ) $decimal_separator = &#39;.&#39;;
  if ( !isset($thousands_separator) ) $thousands_separator = &#39;,&#39;;
  return number_format($number, $decimal_precision, $decimal_separator,
 $thousands_separator);
}

Faire cela non seulement rend le code Le rend plus testable et le rend également indépendant des variables globales de la méthode. Cela nous permet de refactoriser le code pour ne plus utiliser de variables globales.

Instance unique qui ne peut pas être réinitialisée

单一实例指的是旨在让应用程序中一次只存在一个实例的类。它们是应用程序中用于全局对象的一种常见模式，如数据库连接和配置设置。它们通常被认为是应用程序的禁忌， 因为许多开发人员认为创建一个总是可用的对象用处不大，因此他们并不太注意这一点。这个问题主要源于单一实例的过度使用，因为它会造成大量不可扩展的所谓 god objects 的出现。但是从测试的角度看，最大的问题是它们通常是不可更改的。清单 3就是这样一个例子。

清单 3. 我们要测试的 Singleton 对象

<?php
class Singleton
{
  private static $instance;
  protected function __construct() { }
  private final function __clone() {}
  public static function getInstance()
  {
    if ( !isset(self::$instance) ) {
      self::$instance = new Singleton;
    }
    return self::$instance;
  }
}

您可以看到，当单一实例首次实例化之后，每次调用 getInstance() 方法实际上返回的都是同一个对象，它不会创建新的对象，如果我们对这个对象进行修改，那么就可能造成很严重的问题。最简单的解决方案就是给对象增加一个 reset 方法。清单 4 显示的就是这样一个例子。

清单 4. 增加了 reset 方法的 Singleton 对象

<?php
class Singleton
{
  private static $instance;
  protected function __construct() { }
  private final function __clone() {}
  public static function getInstance()
  {
    if ( !isset(self::$instance) ) {
      self::$instance = new Singleton;
    }
    return self::$instance;
  }
  public static function reset()
  {
    self::$instance = null;
  }
}

现在，我们可以在每次测试之前调用 reset 方法，保证我们在每次测试过程中都会先执行 singleton 对象的初始化代码。总之，在应用程序中增加这个方法是很有用的，因为我们现在可以轻松地修改单一实例。

使用类构造函数

进行单元测试的一个良好做法是只测试需要测试的代码，避免创建不必要的对象和变量。您创建的每一个对象和变量都需要在测试之后删除。这对于文件和数据库表等 麻烦的项目来说成为一个问题，因为在这些情况下，如果您需要修改状态，那么您必须更小心地在测试完成之后进行一些清理操作。坚持这一规则的最大障碍在于对 象本身的构造函数，它执行的所有操作都是与测试无关的。清单 5 就是这样一个例子。

清单 5. 具有一个大 singleton 方法的类

<?php
class MyClass
{
  protected $results;
  public function __construct()
  {
    $dbconn = new DatabaseConnection(&#39;localhost&#39;,&#39;user&#39;,&#39;password&#39;);
    $this->results = $dbconn->query(&#39;select name from mytable&#39;);
  }
  public function getFirstResult()
  {
    return $this->results[0];
  }
}

在这里，为了测试对象的 fdfdfd 方法，我们最终需要建立一个数据库连接，给表添加一些记录，然后在测试之后清除所有这些资源。如果测试 fdfdfd完全不需要这些东西，那么这个过程可能太过于复杂。因此，我们要修改 清单 6所示的构造函数。

清单 6. 为忽略所有不必要的初始化逻辑而修改的类

<?php
class MyClass
{
  protected $results;
  public function __construct($init = true)
  {
    if ( $init ) $this->init();
  }
  public function init()
  {
    $dbconn = new DatabaseConnection(&#39;localhost&#39;,&#39;user&#39;,&#39;password&#39;);
    $this->results = $dbconn->query(&#39;select name from mytable&#39;);
  }
  public function getFirstResult()
  {
    return $this->results[0];
  }
}

我们重构了构造函数中大量的代码，将它们移到一个 init() 方法中，这个方法默认情况下仍然会被构造函数调用，以避免破坏现有代码的逻辑。然而，现在我们在测试过程中只能够传递一个布尔值 false 给构造函数，以避免调用 init()方法和所有不必要的初始化逻辑。类的这种重构也会改进代码，因为我们将初始化逻辑从对象的构造函数分离出来了。

经硬编码的类依赖性

正如我们在前一节介绍的，造成测试困难的大量类设计问题都集中在初始化各种不需要测试的对象上。在前面，我们知道繁重的初始化逻 辑可能会给测试的编写造成很大的负担（特别是当测试完全不需要这些对象时），但是如果我们在测试的类方法中直接创建这些对象，又可能造成另一个问题。清单 7显示的就是可能造成这个问题的示例代码。

清单 7. 在一个方法中直接初始化另一个对象的类

<?php
class MyUserClass
{
  public function getUserList()
  {
    $dbconn = new DatabaseConnection(&#39;localhost&#39;,&#39;user&#39;,&#39;password&#39;);
    $results = $dbconn->query(&#39;select name from user&#39;);
    sort($results);
    return $results;
  }
}

假设我们正在测试上面的 getUserList方法，但是我们的测试关注点是保证返回的 用户清单是按字母顺序正确排序的。在这种情况下，我们的问题不在于是否能够从数据库获取这些记录，因为我们想要测试的是我们是否能够对返回的记录进行排 序。问题是，由于我们是在这个方法中直接实例化一个数据库连接对象，所以我们需要执行所有这些繁琐的操作才能够完成方法的测试。因此，我们要对方法进行修 改，使这个对象可以在中间插入，如 清单 8所示。

清单 8. 这个类有一个方法会直接实例化另一个对象，但是也提供了一种重写的方法

<?php
class MyUserClass
{
  public function getUserList($dbconn = null)
  {
    if ( !isset($dbconn) || !( $dbconn instanceOf DatabaseConnection ) ) {
      $dbconn = new DatabaseConnection(&#39;localhost&#39;,&#39;user&#39;,&#39;password&#39;);
    }
    $results = $dbconn->query(&#39;select name from user&#39;);
    sort($results);
    return $results;
  }
}

Vous pouvez désormais transmettre directement un objet compatible avec l'objet de connexion à la base de données attendu et utiliser cet objet directement au lieu de créer un nouvel objet. Vous pouvez également transmettre un objet fictif, c'est-à-dire que nous pouvons renvoyer directement la valeur souhaitée dans certaines méthodes appelantes de manière codée en dur. Ici, nous pouvons simuler la méthode de requête de l'objet de connexion à la base de données, de sorte que nous n'ayons besoin que de renvoyer les résultats sans réellement interroger la base de données. Une refactorisation comme celle-ci peut également améliorer cette approche car elle permet à votre application de connecter différentes connexions à la base de données en cas de besoin, plutôt que de simplement se lier à une connexion à la base de données par défaut désignée.

Avantages du code testable

De toute évidence, écrire davantage de code testable simplifiera certainement les tests unitaires des applications PHP (comme vous le voyez dans les exemples présenté dans cet article), mais ce faisant, il peut également améliorer la conception, la modularité et la stabilité de votre application. Nous avons tous vu du code "spaghetti", qui regorge de beaucoup de logique commerciale et de présentation dans l'un des processus principaux d'une application PHP, ce qui causera sans aucun doute de sérieux problèmes de support pour ceux qui utilisent l'application. Dans le but de rendre le code plus testable, nous avons refactorisé certains des codes problématiques précédents ; ces codes étaient non seulement problématiques dans leur conception, mais également fonctionnels. Nous améliorons la réutilisabilité de notre code en rendant ces fonctions et classes plus polyvalentes et en supprimant les dépendances codées en dur, les rendant plus facilement réutilisables par d'autres parties de l'application. De plus, nous remplaçons le code mal écrit par du code de meilleure qualité pour simplifier la prise en charge future de la base de code.

Conclusion

Dans cet article, nous avons appris comment améliorer le code PHP à travers quelques exemples de code typiques non testables dans les applications PHP Testability. Nous décrivons également comment ces situations peuvent survenir dans les applications, puis comment corriger de manière appropriée le code problématique pour faciliter les tests. Nous avons également appris que ces modifications du code peuvent non seulement améliorer la testabilité du code, mais aussi généralement améliorer la qualité du code et améliorer la réutilisabilité du code refactorisé.

Recommandations associées :

Explication détaillée des exemples de mécanismes de réutilisation de code PHP

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!