Código obsoleto - Código de terceros

Hay un consejo en la comunidad TDD que dice que no debemos usar objetos simulados para tipos que no son de nuestra propiedad . Creo que este es un buen consejo, y trato de seguirlo. Por supuesto, hay personas que dicen que no debemos usar objetos simulados en absoluto. No importa qué opinión tenga, el consejo "no imitar lo que no es suyo" también contiene un significado oculto. La gente a menudo lo pasa de largo, al ver la palabra "burlarse" y enojarse.

Este significado oculto es que debe crear interfaces, clientes, puentes, adaptadores entre nuestra aplicación y el código de terceros que utilizamos. Si crearemos objetos simulados de estas interfaces en nuestras pruebas ni siquiera es tan importante. Lo importante es que creamos y usamos interfaces que separan mejor nuestro código del código de terceros. Un ejemplo clásico de esto en el mundo PHP es crear y usar un cliente HTTP en nuestra aplicación que use el cliente Guzzle HTTP , en lugar de usar Guzzle directamente.

Por qué Bueno, para empezar, Guzzle tiene una API mucho más poderosa que la que necesita su aplicación (en la mayoría de los casos). La creación de su propio cliente HTTP, que proporciona solo el conjunto necesario de API de Guzzle, limitará a los desarrolladores de aplicaciones a lo que pueden hacer con este cliente. Si la API de Guzzle cambia en el futuro, tendremos que hacer cambios en un solo lugar, en lugar de corregir sus llamadas en toda la aplicación con la esperanza de que nada se rompa. ¡Dos muy buenas razones, y ni siquiera mencioné objetos simulados!

No creo que esto sea difícil de lograr. El código de terceros generalmente se encuentra en una carpeta separada de nuestra aplicación, a menudo es vendor/ o library/ . También reside en un espacio de nombres diferente y tiene una convención de nomenclatura diferente a la que se usa en nuestra aplicación. El código de terceros es bastante fácil de identificar y, con un poco de disciplina, podemos hacer que nuestro código de aplicación sea menos dependiente de partes de terceros.

¿Qué sucede si aplicamos las mismas reglas al código heredado?

¿Qué sucede si miramos nuestro código heredado y el de terceros? Esto puede ser difícil de hacer, o incluso contraproducente si el código obsoleto se usa exclusivamente en modo de soporte, cuando solo corregimos errores y ajustamos un poco pequeñas partes de él. Pero si escribimos un nuevo código que (re) usa obsoleto, creo que vale la pena considerarlo de la misma manera que el código de terceros. Al menos desde el punto de vista del nuevo código.

Si es posible, el código obsoleto y nuevo debe ubicarse en diferentes carpetas y espacios de nombres. Ha pasado mucho tiempo desde la última vez que vi el sistema sin inicio, por lo que es bastante factible. Pero en lugar de usar ciegamente código heredado en el nuevo código, ¿qué pasa si creamos interfaces para él y los usamos?

El código obsoleto a menudo está lleno de objetos "divinos" que hacen demasiadas cosas. Usan un estado global, tienen propiedades públicas o métodos mágicos que dan acceso a propiedades privadas como si fueran públicas, tienen métodos estáticos que son muy convenientes para llamar a cualquier persona y en cualquier lugar. Así que esta conveniencia nos ha llevado a la situación en la que nos encontramos.

Otro problema, quizás incluso más grave, con el código desactualizado es que estamos listos para cambiarlo, arreglarlo, descifrarlo porque no lo consideramos como código de terceros. ¿Qué hacemos cuando vemos un error o queremos agregar una nueva función al código de terceros? Describimos el problema y / o creamos una solicitud de extracción. Lo que no hacemos es no ir al vendor/ carpeta y no editar el código allí. ¿Por qué estamos haciendo esto con código heredado? Y luego cruzamos nuestros dedos y esperamos que nada se haya roto.

En lugar de utilizar ciegamente código obsoleto en el nuevo código, intentemos escribir interfaces que incluyan solo el subconjunto requerido de la API del antiguo objeto "divino". Digamos que tenemos un objeto User en código heredado que sabe todo sobre todo. Sabe cómo cambiar el correo electrónico y la contraseña, cómo actualizar los usuarios del foro a moderadores, cómo actualizar los perfiles de usuarios públicos, establecer las preferencias de notificación, guardarse en la base de datos y mucho más.

src / Legacy / User.php

 <?php namespace Legacy; class User { public $email; public $password; public $role; public $name; public function promote($newRole) { $this->role = $newRole; } public function save() { db_layer::save($this); } } 

Este es un ejemplo crudo, pero refleja el problema: cada propiedad es pública y se puede cambiar fácilmente a cualquier valor, debemos recordar llamar explícitamente al método save después de cualquier cambio para guardar, etc.

Limitémonos y prohíbamos el acceso a estas propiedades públicas e intentemos adivinar cómo funciona un sistema desactualizado mientras aumentamos los derechos de los usuarios:

src / LegacyBridge / Promoter.php

 <?php namespace LegacyBridge; interface Promoter { public function promoteTo(Role $role); } 

src / LegacyBridge / LegacyUserPromoter.php

 <?php namespace LegacyBridge; class LegacyUserPromoter implements Promoter { private $legacyUser; public function __construct(Legacy\User $user) { $this->legacyUser = $user; } public function promoteTo(Role $newRole) { $newRole = (string) $newRole; //  ,  $role     ?  ! $legacyRoles = [ Role::MODERATOR => 1, Role::MEMBER => 2, ]; $newLegacyRole = $legacyRoles[$newRole]; $this->legacyUser->promote($newLegacyRole); $this->legacyUser->save(); } } 

Ahora, cuando queremos aumentar los derechos de User en el nuevo código, utilizamos la interfaz LegacyBridge\Promoter , que se ocupa de todas las sutilezas de aumentar un usuario en un sistema desactualizado.

Cambiar idioma de herencia

La interfaz para el código obsoleto nos brinda la oportunidad de mejorar el diseño del sistema y puede salvarnos de posibles errores de nombres que se cometieron hace mucho tiempo. El proceso de cambiar el rol de un usuario de moderador a participante no es "promoción" (aumento), sino más bien "degradación" (disminución). Nadie nos impide crear dos interfaces para estas cosas diferentes, incluso si el código heredado se ve igual.

src / LegacyBridge / Promoter.php

 <?php namespace LegacyBridge; interface Promoter { public function promoteTo(Role $role); } 

src / LegacyBridge / LegacyUserPromoter.php

 <?php namespace LegacyBridge; class LegacyUserPromoter implements Promoter { private $legacyUser; public function __construct(Legacy\User $user) { $this->legacyUser = $user; } public function promoteTo(Role $newRole) { if ($newRole->isMember()) { throw new \Exception("Can't promote to a member."); } $legacyMemberRole = 2; $this->legacyUser->promote($legacyMemberRole); $this->legacyUser->save(); } } 

src / LegacyBridge / Demoter.php

 <?php namespace LegacyBridge; interface Demoter { public function demoteTo(Role $role); } 

src / LegacyBridge / LegacyUserDemoter.php

 <?php namespace LegacyBridge; class LegacyUserDemoter implements Demoter { private $legacyUser; public function __construct(Legacy\User $user) { $this->legacyUser = $user; } public function demoteTo(Role $newRole) { if ($newRole->isModerator()) { throw new \Exception("Can't demote to a moderator."); } $legacyModeratorRole = 1; $this->legacyUser->promote($legacyModeratorRole); $this->legacyUser->save(); } } 

No es un gran cambio, pero el propósito del código es mucho más claro.

Ahora, la próxima vez que necesite llamar a algunos métodos desde un código desactualizado, intente crear una interfaz para ellos. Puede ser imposible, puede ser demasiado costoso. Sé que el método estático de este objeto "divino" es realmente muy simple de usar y con su ayuda puedes hacer el trabajo mucho más rápido, pero al menos considera esta opción. Simplemente puede mejorar ligeramente el diseño del nuevo sistema que está creando.