Nuestra máxima es ofrecer el mejor producto posible a un precio más que razonable. Para que el proyecto triunfe, tal y como explicamos en nuestra metodología de trabajo, necesitaremos la mayor implicación por parte del cliente en el proceso que acompaña al desarrollo del software.

Nuestra garantía es un fiel reflejo de esta implicación exigida al cliente.

INCLUIDO

Nuestra garantía incluye la corrección de todos aquellos defectos que puedan detectarse dentro del plazo incluido en la garantía.

Nuestra garantía cubre solamente los errores, no incluye modificaciones procesos a los que el cliente debería de haber prestado una atención mayor y que no son derivados de nuestra actividad.

NO INCLUIDO

Tampoco incluye modificaciones de textos ni nuevos requisitos o necesidades que aparecen después de la entrega.

DURACIÓN

La garantía ofrecida por DEVTIA es bastante simple, ofrecemos una garantía de corrección de errores de tres meses en todos nuestros proyectos que comenzará a contar tras la finalización del mismo. El cliente debe comprometerse a revisar en profundidad el funcionamiento de su proyecto en este plazo.

En caso de que por cualquier motivo, el cliente no pueda realizar estas comprobaciones para recurrir a la garantía, no pasará nada, no hay ningún problema, queremos que nuestro producto funcione a la perfección y vamos a encargarnos de reparar lo que debamos. Eso sí, en caso de recurrir a la garantía fuera de plazo, el cliente tendrá que pagar por el tiempo adicional que dedicaremos a su proyecto.

Nuestra recomendación es que, en la medida de lo posible, exprimas al máximo el funcionamiento de la herramienta durante estos tres meses para que no se escape ningún posible error y no tengas que pagar ni un euro de más.

Nuestros valores te interesan si estás pensando en trabajar con nosotros, da igual si vas a ser un empleado, un proveedor o un cliente, ya que estos valores aplican exactamente igual a todas las partes interesadas. Queremos construir un círculo de confianza, y dentro de este círculo de confianza esperamos que tú también tengas unos altos estándares, y que estos sean 100% compatibles con los nuestros.

Transparencia y honestidad

La transparencia es la capacidad de transmitir la realidad tal cual es. Muchas personas creen que su interlocutor quiere escuchar sí a todo. El cliente siempre tiene la razón. En nuestra opinión lo que realmente quiere escuchar es la verdad. La confianza se consigue a través de una relación de comunicación honesta y fluida. Por esto nos esforzamos mucho en engrasar nuestros canales de comunicación.

Resumen

La confianza es algo difícil de alcanzar en todos los ámbitos de la vida, y en especial en el ámbito laboral. Se pueden tardar meses e incluso años forjar una relación fuerte y perdurable en el tiempo. En DEVTIA cuidamos las relaciones como un aspecto de capital para la compañía.

Este es el primero de una serie de entradas en las que analizamos el libro pragmatic programmer from journeyman to master publicado en el año 1999 por Andrew Hunt y David Thomas. Puedes leer la serie en cualquier orden, o leer solamente las entradas que te interesen ya que son independientes entre sí.

Si te interesa, también puedes ver esta entrada en nuestro canal de youtube.

Una de las ideas que subyacen en todo el libro es la responsabilidad. Responsabilidad de tus acciones, de tu carrera, de los proyectos en los que trabajas. Es cierto que muchas cosas no dependen de tí, pero si depende de tí la actitud que tomas cuando te enfrentas a ellas.

En esta línea de pensamiento no debes tener miedo a reconocer que no sabes algo, y sobre todo no debes tener miedo a reconocer que te has equivocado. Si te dedicas al mundo del desarrollo de software puedes estar seguro que ambas situaciones se van a dar antes o después.

Lo importante es cómo te enfrentas a estas situaciónes. Aunque no lo creas, cuando has metido la pata, también es un buen momento para demostrar que eres un gran profesional.

Podemos estar orgullosos de las habilidades que tenemos, pero también podemos estar orgullosos de cómo manejamos la situación cuando nos equivocamos.

¿Cual es la forma correcta de actuar?

1. Sé honesto y directo.
2. Avisa lo antes posible.
3. Nadie quiere saber cuales son tus excusas.
4. Ahora no importa quien es el culpable, tampoco importa lo que no puede hacerse.
5. Lo único que importa es que puede hacerse para paliar los daños y para volver a una situación normal lo antes posible.

Analizar qué ha ocurrido

Una vez que la situación de crisis ha pasado, ahora toca analizar que es lo que pasó.

1. Sigue sin ser importante de quien fue la culpa, probablemente varias personas tienen una parte de culpa.
2. Importa que es lo que puedes hacer tú para que no vuelva a pasar.

Apuntaté a nuestra academia si quieres recibir un consejo como este cada semana en tu bandeja de entrada.

¿Pruebas automáticas?

Las pruebas o la batería de pruebas es un software que debe escribirse en paralelo a nuestro propio software y cuya responsabilidad es comprobar que nuestro software funciona correctamente. Básicamente es software que prueba nuestro software.

Puede que intuitivamente pienses que construir una batería de pruebas, es trabajo adicional, ya que probablemente tardarás más tiempo y por lo tanto tu trabajo será más caro para tus clientes pero esto no es así.

Cuando tienes una buena batería de pruebas, la primera "derivada" es que vas a cometer menos errores. Menos errores supone menos tiempo arreglando errores y más tiempo programando. Además supone menos frustración en los usuarios.

La segunda derivada es que puedes hacer cambios con mayor confianza, y esto te hace ir más rápido. Las pruebas detectarán que has roto, y simplemente tendrás que arreglarlo, un equipo con una buena batería de pruebas termina trabajando mucho más rápido que un equipo que no las tiene.

Hay una tercera derivada y es que al desarrollar tu batería de pruebas te va a permitir diseñar mejor software, pero esto es algo en lo que profundizaremos en una entrada más adelante.

¿Si es tan bonito por que no todo el mundo hace pruebas automáticas?

Cuando escribes pruebas debes ser tan cuidadoso cómo con el código de producción. Todo lo que hemos comentado ya en esta serie sobre elegir buenos nombres, funciones, argumentos, etc son cosas que también aplican a las pruebas automáticas.

Escribir buenas pruebas requiere cierta técnica y ocurre que muchos programadores o equipos comienzan haciendo pruebas, y al no ser pruebas de calidad terminan teniendo una batería de pruebas que supone más un problema que una solución. Tras esta mala experiencia desisten, por eso en esta entrada vamos a explicarte cómo escribir buenas pruebas.

Escribe tus pruebas "PRIMERO"

FIRST o PRIMERO es un acrónimo que se utiliza para describir las características que debería tener una prueba.

Fast o Rápidas

Una prueba, así como la batería de pruebas a la que pertenecen deberían ser tan rápidas cómo sea posible. ¿Cuánto? Pues depende del tipo de prueba y del proyecto. El autor no se moja en este aspecto, pero en mi opinión deberías mantener cada prueba por debajo de 1 segundo.

Independent o independientes

Unas pruebas no deberían depender de otras. Esto te permitirá ejecutar aisladamente las pruebas que fallen en lugar de tener que ejecutar toda la batería o un conjunto de pruebas.

Repeatable o repetibles

El resultado de una prueba debería ser siempre el mismo y no variar si la ejecutas varias veces. De esta forma, podrás ejecutar una prueba una y otra vez, hasta que arregles el error. De lo contrario tendrías continuamente errores que luego no vas a poder reproducir.

Self-validating o validación automática

Lo que quiere decir esta regla es que las pruebas no deberían depender de una revisión, por ejemplo que el resultado fuera un texto que luego necesitarás leer para saber si es correcto o no. La prueba debe pasar o no pasar, no debería haber otro resultado posible.

Timely o en el momento correcto

El autor introduce en este capítulo las reglas del ciclo de TDD: rojo, verde y refactorización, pero no quiero profundizar mucho sobre este aspecto aquí, porque tendremos el libro "Test Driven Development: By Example" por en este blog y en el canal de youtube más pronto que tarde.

Show me the code

Supongamos que tenemos la clase rectangulo que vimos en el capítulo de estructuras vs objetos.

class Rectangle
{
    private $height;
    private $width;

    public function __construct(float $height, float $width)
    {
        $this->height = $height;
        $this->width = $width;
    }

    public function area(): float
    {
        return round($this->height * $this->height, 2);
    }
}

Escribir una prueba es una tarea muy sencilla, normalmente es simplemente una clase que tiene que extender de algún tipo de framework de pruebas, así es como se hace con phpunit

class RectangleTest extends \PHPUnit\Framework\TestCase
{
    public function test_area()
    {
        $rectangle = new Rectangle(1.11, 2.22);
        $this->assertSame(2.46, $rectangle->area());
    }
}

Fácil, pero ¿que ocurre al ejecutarlo?

Efectivamente había un error en el código. En este caso lo hemos introducido a posta, pero es un tipo de error que se puede cometer fácilmente.

¿Has visto cual?

Veamos un ejemplo con la clase responsable de notificar a los usuarios de la academia que hay un nuevo contenido disponible. En el método send recibiremos un usuario y la entrada que debe serle notificada.

Partiremos de este primer ejemplo donde la gestión de errores ensucia el código para ver cuales son las diferentes mejoras que podemos ir realizando.

class SendCommand extends AbstractCommand
{
    private function send(User $user, Post $post): void
    {
        $code = $this->mailer->sendTemplate(
            [$user->getEmail() => $user->getName()],
            $post->getName(),
            '@App/Command/Academy/Mailing/Post/post.html.twig',
            [
                'user' => $user,
                'post' => $post,
            ]
        );

        if (Code::TIMEOUT == $code) {
            sleep(20);
            $this->send($user, $post);
        } elseif (Code::ADDITIONAL_DATA_REQUIRED == $code) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because was unavailable',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        } elseif (Code::ADDITIONAL_DATA_REQUIRED == $code) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because additional space was needed',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        } elseif (Code::INBOX_IS_FULL == $code) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because the inbox was full',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        }
    }
}

Como se puede ver este ejemplo inicial tiene bastante que mejorar.

Evita utilizar códigos de error

Los códigos de error son difíciles de manejar. En general van a requerir un montón de estructuras if / else para poder lidiar con los diferentes códigos de error.

Además siempre cabe la posibilidad de que se añada un nuevo código de error que nosotros no tengamos capturado. En lugar de códigos de error sería conveniente utilizar excepciones.

A continuación vemos exactamente el mismo código pero utilizando excepciones:

class SendCommand extends AbstractCommand
{
    private function send(User $user, Post $post): void
    {
        try {
            $this->mailer->sendTemplate(
                [$user->getEmail() => $user->getName()],
                $post->getName(),
                '@App/Command/Academy/Mailing/Post/post.html.twig',
                [
                    'user' => $user,
                    'post' => $post,
                ]
            );
        } catch (TimeoutException $e) {
            sleep(20);
            $this->send($user, $post);
        } catch (AdditionalDataRequiredException $e) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because was unavailable',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        } catch (ServiceUnavailableException $e) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because additional space was needed',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        } catch (InboxIsFullException $e) {
            $this->log(
                sprintf(
                    'message [%06d] for user "%s" could not be sent because the inbox was full',
                    $post->getId(),
                    $user->getEmail()
                )
            );
        }
    }
}

De momento no hemos mejorado mucho y nuestro código sigue teniendo una pinta terrible, pero estamos un paso más cerca de tener nuestro código bastante más elegante.

Separar lógica y gestión de errores

Lo que vamos a hacer ahora es separar la responsabilidad en dos métodos. Uno de ellos contendrá la lógica de negocio y el otro contendrá la gestión de errores. Este sencillo cambio hace nuestro código mucho más legible y fácil de mantener.

class SendCommand extends AbstractCommand
{
    private function handleSendException(User $user, Post $post, \Exception $exception): void
    {
        try {
            throw $exception;
        } catch (TimeoutException $e) {
            // ..
        } catch (AdditionalDataRequiredException $e) {
            // ..
        } catch (ServiceUnavailableException $e) {
            // ..
        } catch (InboxIsFullException $e) {
            // ..
        }
    }

    private function send(User $user, Post $post): void
    {
        try {
            $this->mailer->sendTemplate(
                [$user->getEmail() => $user->getName()],
                $post->getName(),
                '@App/Command/Academy/Mailing/Post/post.html.twig',
                [
                    'user' => $user,
                    'post' => $post,
                ]
            );
        } catch (\Exception$exception) {
            $this->handleSendException(user, $post, $exception);
        }
    }
}

Evita los detalles de implementación

Nuestro código ha mejorado bastante, pero todavía tiene un problema. Nuestro comando conoce los detalles de implementación del sistema de envío de correo. Esto supone un problema, si en el futuro quisiéramos enviar el correo o las notificaciones con otra librería o a través de otro medio, nuestro comando dejaría de funcionar.

Para ello es conveniente evitar conocer los detalles de implementación ( las excepciones ) que contiene el sistema de envío, con lo que nos debería quedar algo así.

class SendCommand extends AbstractCommand
{
    private function handleSendException(User $user, Post $post, \Exception $exception): void
    {
        $this->log(
            sprintf(
                'message [%06d] for user "%s" with message "%s"',
                $post->getId(),
                $user->getEmail(),
                $exception->getMessage()
            )
        );
    }

    private function send(User $user, Post $post): void
    {
        try {
            $this->mailer->sendTemplate(

                [$user->getEmail() => $user->getName()],
                $post->getName(),
                '@App/Command/Academy/Mailing/Post/post.html.twig',
                [
                    'user' => $user,
                    'post' => $post,
                ]
            );
        } catch (\Exception$exception) {
            $this->handleSendException($user, $post, $exception);
        }
    }
}

Hacer una única cosa

Una función solo debería hacer una única cosa, y además debería de ser ser capaz de hacerla bien. Este concepto a la vez que es sencillo de entender es bastante complejo de explicar, así que vamos a definir algunas características que pueden indicarte que una de tus funciones hacen más de una cosa.

Demasiado larga

Si una función tiene demasiadas líneas de código, es muy probable que esté haciendo varias cosas a la vez. Deberías tratar de encontrar bloques dentro de esa misma función que hagan una cosa concreta e ir extrayendolas en funciones más pequeñas.

El límite exacto para considerarse demasiado larga es un poco difuso, pero por encima de 20 líneas deberías al menos plantearte si tu función es demasiado larga.

Secciones

Como continuación a lo anterior, si una función puede dividirse en secciones, nos encontramos ante un caso claro de que esa función hace más de una cosa.

A continuación vemos la función Lock::acquire

/**
 * {@inheritdoc}
 */
public function acquire(bool $blocking = false): bool
{
    try {
        if ($blocking) {
            if (!$this->store instanceof BlockingStoreInterface) {
                throw new NotSupportedException(sprintf('The store "%s" does not support blocking locks.', get_debug_type($this->store)));
            }
            $this->store->waitAndSave($this->key);
        } else {
            $this->store->save($this->key);
        }

        $this->dirty = true;
        $this->logger->info('Successfully acquired the "{resource}" lock.', ['resource' => $this->key]);

        if ($this->ttl) {
            $this->refresh();
        }

        if ($this->key->isExpired()) {
            try {
                $this->release();
            } catch (\Exception $e) {
                // swallow exception to not hide the original issue
            }
            throw new LockExpiredException(sprintf('Failed to store the "%s" lock.', $this->key));
        }

        return true;
    } catch (LockConflictedException $e) {
        $this->dirty = false;
        $this->logger->notice('Failed to acquire the "{resource}" lock. Someone else already acquired the lock.', ['resource' => $this->key]);

        if ($blocking) {
            throw $e;
        }

        return false;
    } catch (\Exception $e) {
        $this->logger->notice('Failed to acquire the "{resource}" lock.', ['resource' => $this->key, 'exception' => $e]);
        throw new LockAcquiringException(sprintf('Failed to acquire the "%s" lock.', $this->key), 0, $e);
    }
}

Podemos observar 3 secciones principales. En la primera trata de adquirir el bloqueo, en la segunda comprueba si el bloqueo debería haber expirado y en el último bloque realiza el manejo de errores. Podríamos facilitarle mucho la vida al lector si extrajeramos esos bloques dejándolos en algo similar a esto.

/**
 * {@inheritdoc}
 */
public function acquire(bool $blocking = false): bool
{
    try {
        $this->tryAcquire($blocking);
        $this->releaseIfExpired();

        return true;
    } catch (\Exception $e) {
        return $this->handleException($e);
    }
}

switch

Un bloque switch es probablemente un indicador de que una función hace varias cosas. La forma de solucionar esto es extraer ese bloque switch para que la única cosa que haga nuestra función es decidir qué hacer en función del valor que le pasemos a switch.

A continuación vemos un caso válido de un bloque switch dentro de la clase Store\StoreFactory, ya que aunque tiene un elemento switch la función hace una única cosa, en este caso devolver la instancia de Store\PersistingStoreInterface correcta en función del tipo de conexión que estemos utilizando.

/**
     * @param \Redis|\RedisArray|...
     *
     * @return PersistingStoreInterface
     */
    public static function createStore($connection)
    {
        if (!\is_string($connection) && !\is_object($connection)) {
            throw new \TypeError(sprintf('Argument 1 passed to "%s()" must be [...], "%s" given.');
        }

        switch (true) {
            case $connection instanceof \Redis:
            case $connection instanceof \RedisArray:
            case $connection instanceof \RedisCluster:
            case $connection instanceof \Predis\ClientInterface:
            case $connection instanceof RedisProxy:
            case $connection instanceof RedisClusterProxy:
                return new RedisStore($connection);
            // en total hay 32 casos diferentes.
        }

        throw new InvalidArgumentException(sprintf('Unsupported Connection: "%s".', $connection));
    }

Un sólo nivel de abstracción

Dentro de una misma función debemos mantenernos siempre dentro del mismo nivel de abstracción.

Por ejemplo si tuviéramos una capa de dominio de negocio y una capa de persistencia de datos, dentro de una misma función no deberíamos pasar de un nivel a otro, por lo cual tendríamos funciones con lógica de negocio y funciones con lógica de persistencia de datos.

Procesamiento de errores

Empezaremos indicando que el procesamiento de errores es mucho más sencillo a través de excepciones que de códigos de error, pero esto lo veremos mucho más en profundidad en el capítulo de procesamiento de errores.

El problema que tienen los bloques try / catch es que dificultan mucho la lectura.Si tenemos una función donde además de la lógica de la función tiene uno o más bloques try / catch, probablemente deberíamos extraer la parte de la lógica de negocio y dejar esa función sólamente con los bloques try catch tal y cómo hicimos con la función Lock::acquire en el ejemplo anterior.

Sin embargo, aunque suene a tópico, somos seres humanos y estamos expuestos a cometer errores que, sin lugar a dudas, perjudicarán a nuestros clientes. Cómo afrontes este error puede dar lugar a dos finales totalmente distintos:

• Puedes perder toda la confianza que hayas podido ganar como profesional y parecer una persona incompetente que probablemente no seas.
• Puedes actuar de manera profesional, no excusándote del error, ni echando balones fuera, demostrando así tu valía como profesional y recuperando la confianza perdida de tu cliente.

Actuar bajo la presión de los errores no es una tarea en absoluto fácil. Hemos elaborado esta pequeña guía para que sepas cómo hacerlo de la mejor manera posible. Está muy orientada al trabajo que realizamos en DEVTIA: Desarrollo de software a medida, pero seguro que puedes aplicar estos consejos a cualquier tipo de trabajo.

Mantén la calma

Antes de tomar cualquier tipo de decisión, lo primero que deberías hacer es respirar y lograr mantenerse lo suficientemente tranquilo como para saber que la decisión que tomes a continuación va a ser la correcta. Los nervios no son buenos compañeros en este tipo de situaciones.

Una vez en calma, empieza a actuar de manera progresiva. En primer lugar, tienes que impedir que el error, venga de donde venga, se siga propagando y acabe por producir daños mucho mayores.

Por ejemplo, si tienes un comercio electrónico y has estado realizando ventas, pero a la hora de intentar pagar la pasarela de pago no ha funcionado de manera correcta, lo primero que deberías poner sería un mensaje del tipo “ahora mismo no podemos procesar su pedido, inténtelo de nuevo más tarde” o “déjenos su email y le avisaremos en cuanto la pasarela de pago se encuentre disponible”.

Informa al responsable

A veces, algunas personas tratan de ocultar sus errores y solucionarlos en la sombra, sin que nadie se entere. Este comportamiento no debería darse nunca en un buen profesional.

La honestidad y la transparencia han de ser tu política a seguir en estos casos, avisando lo antes posible del error al responsable y explicando claramente qué ocurrió y por qué. En este momento es esencial transmitir que no se están buscando responsables ni culpables, sino que todos estáis remando hacía una misma meta: la solución del problema.

Además de informar al responsable, deberás explicarle, cuáles son las soluciones que tu propones y qué implica cada una de ellas.

Pide ayuda

Todo el mundo comete errores y la peor actitud posible es tragártelos tú solo.

Así que no dudes en pedir ayudar a tus compañeros más cercanos, ellos también cometen o cometerán errores y se habrán visto en situaciones similares. No tengas miedo en contar con ellos.

En momentos así y por el bien de la empresa, todos deberían estar dispuestos a ayudar, no importa a quién pidas ayuda, lo importante es que sea una ayuda incondicional, de esta manera también se reforzarán no solo las relaciones profesionales, sino también las personales.

Cuando el error no lo cometas tú, no dudes en estar disponible para aquel que lo haya cometido. Adopta la actitud que te gustaría que adoptarán contigo.

Actua despacio

Al igual que la ansiedad, la prisa es un enorme enemigo a la hora de solucionar un error. Cuando los errores se intentan solucionar rápidamente cabe la posibilidad de que se cometan otros más graves, entrando en un bucle del que es complicado salir.

La paciencia será la mejor de las virtudes en este tipo de situaciones.

Piensa que el error ya está hecho y que a todas las personas a quienes afecta directa o indirectamente ya saben de su existencia. Ya no tienen ninguna prisa, ahora lo importante es mantener la cabeza fría y hacer un buen trabajo para solucionarlo.

Es mejor una solución que lleve su tiempo, que una rápida que no resuelva el problema.

Aprende

Una vez las cosas han vuelto a su cauce, lo mejor es analizar qué es lo que salió mal y cómo evitar una situación similar en el futuro.

Reflexionando y cambiando los procedimientos que indujeron al error, se está demostrando una actitud proactiva y un enfoque constructivo en vez de derrotista.

¿Había falta de conocimiento?, ¿Falta quizá de comunicación?, ¿Falló la concentración?, ¿Era un error evitable?... Un buen análisis del origen del fallo será esencial para aprender de los errores propios y afrontar el futuro siendo un equipo mejor y más cohesionado.