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.

En esta entrada queremos explicarte algunas de las buenas prácticas que implementamos en el equipo.

CÓDIGO LIMPIO

Cuando hablamos de código limpio nos referimos a buenas prácticas en el desarrollo de software descritos por Robert C Martin en su libro “Código Limpio”, del que puedes encontrar mucha información en esta serie de entradas que hemos publicado.

El seguimiento de las indicaciones que se aportan genera proyectos que son más fáciles de mantener en el tiempo.

PROGRAMACIÓN EN PAREJAS

La programación en parejas es un concepto propuesto por Ken Beck en su libro “Programación extrema”. La idea que subyace detrás de su propuesta es que si bien, dos programadores que trabajan juntos van a producir menos líneas de código, el que generen será de mayor calidad, por lo que de forma efectiva el equipo va más rápido.

Nosotros implementamos una versión de lo que él propone. Cada programador trabaja de forma independiente la mayoría del tiempo, pero programamos por parejas cuando alguien necesita ayuda o está tocando algo muy delicado.

PRUEBAS AUTOMÁTICAS

Las pruebas automáticas es un software diseñado para probar el software, valga la redundancia, en el que se está trabajando.

El uso de pruebas automáticas añade muchas ventajas al desarrollo, pero sobre todo la principal ventaja desde el punto de vista del cliente es un producto digital con menos errores y con mayor facilidad para ser modificado.

INTEGRACIÓN CONTINUA

Integración continua es una práctica muy relacionada con el desarrollo ágil, según la cual la batería de pruebas se ejecuta de manera automática en un servidor remoto con cada cambio en el código.

RESUMEN

Ciertas empresas suelen considerar que el candidato más cualificado para ocupar un puesto vacante es aquel que cumple con todos los requisitos y cuyas expectativas salariales son lo más bajas posibles, nosotros consideramos que enfocar así la busqueda es un error que puede traer consecuencias a larga. Pensamos que para que un empleado pueda exprimir sus capacidades en nuestra empresa, ha de existir una estrecha relación entre los requisitos que exigimos por su parte y las expectativas de trabajo que el candidato espera que la compañía ofrezca.

A lo largo de este artículo te contaremos cómo es nuestro proceso de selección con todo lujo de detalles.

La preselección

Solemos recibir candidaturas a través de dos canales:

1. A través de portales de empleo.
2. Nos contactan de manera directa al haber visto la oferta publicada a través de nuestra página web o de alguna redes sociales.

No nos gusta tener que depender de una plataforma o herramienta de terceros para comunicarnos, por lo que a partir de la toma de contacto nos comunicamos siempre de manera externa a ellas. Creamos en nuestro CRM una ficha con los datos relevantes del candidato y comprobamos si cumple los principales requisitos, aunque no los cumpla al 100%, pueden existir detalles que nos motiven a incluirlo en el proceso de selección como por ejemplo, una buena carta de presentación o una buena actitud.

Somos una empresa que trabaja 100% en remoto por lo que da igual en qué punto del globo se encuentren los candidatos, siempre que se conecten con nuestro horário y hablen nuestro idioma ;)

Llamada telefónica

Lanzamos a través de redes sociales los puestos que necesitamos cubrir y adjuntamos una encuesta que nos ayudará como primera criba, es importante para nosotros contar con un punto de partida óptimo que garantice conocimientos o estandares fijados así como conocer si el candidato o candidato están familiarizados con metodologías ágiles. Por lo general los primeros descartes se realizan por expectativas económicas que no van a acordes a lo que el candidato puede ofrecernos, por ejemplo, si buscamos a alguien que tenga experiencia en symfony, y el candidato tiene unos conocimientos mínimos, no vamos a poder ofrecer los 40k que nos exija, no podemos pagar esa cantidad para acabar enseñando a utilizar una herramienta que exigimos como esencial.

Entrevista personal

Es el plato fuerte de cualquier proceso de selección, es realizada por todo el equipo y se divide en dos partes:

El objetivo de la primera parte es buscar la sintonía entre lo que el candidato busca y lo que podemos ofrecerle entendiendo, entre otras cosas:

• Qué tipo de candidato es.
• Cuáles son sus motivaciones.
• Cuál sería su trabajo, pretendemos conocer si el desempeño deseado por el entrevistado se aproxima a lo que hacemos en nuestro día a día.

En la segunda parte dejamos preguntar al candidato y mostramos qué es lo que hacemos, esta parte de la entrevista es la más libre y abierta, suelen surgir preguntas de todo tipo y que dependen únicamente de la curiosidad del entrevistado. Intentamos mostrar la mayor transparencia posible sea cuál sea la pregunta.

La tasa de descartes en esta fase suele ser del 50%.

Prueba técnica

La prueba técnica nos sirve para saber si el candidato posee los conocimientos técnicos adecuados. No es una prueba complicada y aunque existan algunas partes en las que no se disponga de un conocimiento adecuado, se podrá superar poniendo un poco de empeño.

Se puede resolver de diversas formas. La forma en la que se resuelva nos dará las claves para saber con qué tipo de programador hemos topado. No solemos descartar a casi nadie en esta fase ya que evaluamos según factores que nos ha contado el candidato anteriormente.

Reunión del equipo

Todo el proceso esta diseñado para que al final llegue un pequeño grupo de personas a las que, tras una reunión de equipo, ordenaremos de mayor a menor teniendo en cuenta una ponderación realizada a través de los siguientes factores:

1. Feeling personal / soft skills.
2. Objetivos a medio-largo plazo.
3. Conocimientos técnicos requeridos.
4. Conocimientos técnicos adicionales del candidato.
5. Expectativas salariales.

Cada parte de nuestro equipo tiene opiniones diferentes al resto, por ello esta especie de ranking ponderado nos aporta una visión general de los entrevistados teniendo en cuenta las opiniones subjetivas de todo el equipo.

Oferta al candidato

Una vez ordenados de mayor a menor según la preferencia del equipo, nos ponemos en contacto con el candidato que más nos ha gustado para hacerle la oferta final y recordarle las condiciones pactadas. Le enviaremos la oferta por correo.

Normalmente aceptan la oferta. Si han llegado hasta aquí es porque existe “buen feeling” entre ambas partes. En caso de no aceptar, pasaríamos al siguiente candidato, llevando a cabo el mismo proceso.

¿Y los no seleccionados?

Todos los candidatos que no han superado alguna de las pruebas como podría ser la entrevista personal y la técnica, no se convierten en candidatos descartados, simplemente no han sido seleccionados y se lo comunicaremos explicando el motivo. De esta manera podemos ayudarle a mejorar en futuros procesos de reclutamiento.

Intellij IDEA junto con el resto de "sabores" del mismo como es PHPStorm, PyCharm, WebStorm es considerado por muchos el mejor entorno de desarrollo integrado que existe en la actualidad.

Esta entrada forma parte de una serie en la que vamos a aprender a usar este editor de forma profesional, a través del conocimiento de los diferentes atajos de teclado disponibles, así como de otras funcionalidades muy útiles para el día a día.

En esta entrada vamos a centrarnos en una de las características más potentes del IDE la refactorización.

Recomendaciones previas

No es necesario que te aprendas todos el primer día. Te recomendamos elegir dos o tres atajos de teclado. Los que te parezcan más útiles y los apuntes en un posit junto a la pantalla para que no se te olviden. Practica con ellos durante algunos días y una vez que los tengas dominados, continúes tu aprendizaje con otro grupo de dos o tres.

El primer atajo de teclado que vamos a recomendarte en cada una de las entradas, es encontrar una acción.

Encontrar una acción

ALT + SHIFT + A

Con este atajo podemos lanzar el menú de selección de acción. Este atajo es de los más útiles ya que te muestra el atajo de la acción que estás buscando por lo que puedes utilizarlo cuando no te acuerdes del atajo que quieres lanzar de forma que vas a poder aprenderlos poco a poco.

Refactorización con Intellij IDEA

Renombrar variable, función, método o clase

SHIFT + F6

Con este atajo podemos renombrar una variable, una función o método o una clase. El entorno de desarrollo buscará todas las apariciones de dicho elemento y los actualizará. Si se trata de una clase cambiará el nombre del fichero que lo contiene.

Extraer constante

CTRL + ALT + C

Con este atajo podemos extraer un valor a una constante de la clase.

Extraer propiedad

CTRL + ALT + F

Con este atajo podemos extraer un valor a una propiedad de la clase.

Extraer variable

CTRL + ALT + V

Con este atajo podemos extraer un valor a una variable del método.

Extraer parametro

CTRL + ALT + P

Con este atajo podemos extraer un valor a un parámetro del método.

Extraer método

CTRL + ALT + M

Con este atajo podemos extraer un bloque de código a un método de la clase. El entorno de desarrollo buscará coincidencias del mismo fragmento de código y nos ofrecerá reemplazarlas por el nuevo método.

Cambiar la firma de un método

CTRL + F6

Con este atajo podemos cambiar la firma de un método. El entorno de desarrollo buscará todas las llamadas a ese método y actualizará el código con la nueva firma.

Mover una clase

F6

Este atajo nos va a permitir mover una clase a otro directorio. El entorno de desarrollo actualizará el namespace y buscará todas las referencias y las actualizará también.

En esta entrada vamos a centrarnos en como navegar de la forma más productiva posible es decir llegar en el menor tiempo posible al lugar al que queremos llegar, tanto si es a otro fichero como si es a una zona diferente del fichero en el que nos encontramos.

Recomendaciones previas

No es necesario que te aprendas todos el primer día. Te recomendamos elegir dos o tres atajos de teclado. Los que te parezcan más útiles y los apuntes en un posit junto a la pantalla para que no se te olviden. Practica con ellos durante algunos días y una vez que los tengas dominados, continúes tu aprendizaje con otro grupo de dos o tres.

El primer atajo de teclado que vamos a recomendarte en cada una de las entradas, es encontrar una acción.

Encontrar una acción

ALT + SHIFT + A

Con este atajo podemos lanzar el menú de selección de acción. Este atajo es de los más útiles ya que te muestra el atajo de la acción que estás buscando por lo que puedes utilizarlo cuando no te acuerdes del atajo que quieres lanzar de forma que vas a poder aprenderlos poco a poco.

Navegación entre ficheros

En el primer bloque vamos a aprender como desplazarnos entre diferentes ficheros para llegar lo antes posible al documento que queremos llegar.

Buscar la clase o archivo

CTRL + N / CTRL + SHIFT + N

Con este atajo podemos buscar la clase o el archivo al que queremos ir respectivamente. El buscador de archivos funciona incluso si el editor está indexando el proyecto.

Navegar a la referencia

CTRL + B / CTRL + CLICK

Con este atajo podemos navegar hacia la definición de una clase o método. Si existen varias disponibles, nos mostrará todas las opciones. Si tienes instalado y configurado el plugin de symfony te permite navegar entre rutas o definiciones de plantillas.

Navegar a hacia delante o hacia atrás

ALT + SHIFT + LEFT / ALT + SHIFT + RIGHT

Con este atajo podemos navegar hacia delante o hacia atrás en la navegación que hemos realizado.

Ver ficheros visitados recientemente

CTRL + E

Con este atajo podemos navegar entre los ficheros que hemos visitado recientemente.

Ver localizaciones visitadas recientemente

CTRL + SHIFT + E

Con este atajo podemos navegar entre los bloques de código que hemos visitado recientemente.

Navegación dentro de un fichero

A continuación vamos a ver los atajos que consideramos más interesantes y que nos van a permitir navegar dentro de un mismo fichero muy rápidamente y sin utilizar el ratón.

Ver estructura

CTRL + F12

Con este atajo nos abre la vista de estructura para poder navegar fácilmente entre los diferentes métodos de una clase.

Método anterior o siguiente

ALT + UP / ALT + DOWN

Con este atajo podemos desplazarnos entre los diferentes métodos de la clase.

Ir al siguiente error

F2

Con este atajo podemos desplazarnos al siguiente error dentro de un fichero.

Saltar a la línea

CTRL + G

Con este atajo podemos desplazarnos directamente a la línea a la que nos queremos mover.

Te recomendamos que leas todos los atajos disponibles tanto en la web de jetbrains como en la configuración de atajos de teclado de tu editor para que descubras por tí mismo todos los atajos disponibles.

Si te gustaría recibir una entrada como esta cada semana en tu bandeja de entrada: apúntate a nuestra academia.

Elige tu estilo

En mi opinión no tan importante que reglas utilices para organizar tus clases. Lo que sí es muy importante, es que elijas unas y te comprometas con ellas. También es muy importante que no seas dogmático y que estés dispuesto a añadir o modificar tus reglas si es que aparecen otras mejores.

No hay nada más frustrante que tratar de explicar a un desarrollador una forma mejor de hacer las cosas, y que no sea capaz de salir de sus trece, pero que tampoco sea capaz de argumentar un motivo.

Dentro de las reglas que elijas ten en cuenta que nada debe quedar al azar, si no que se note que todo está de una forma determinada por un motivo determinado y no simplemente por que ha quedado así.

Nuestro estilo

Nosotros utilizamos la guia de estilo oficial para symfony ya que es el framework con el que trabajamos. Además es muy sencillo configurar el editor para que las aplique automáticamente.

A continuación vamos a explicar el resto de reglas que utilizamos nosotros y que no son exactamente iguales a las que describe el autor en el libro. Pero que vamos a argumentarte los motivos que hemos tenido en cuenta para elegirlas.

Para ello vamos a analizar la clase Rectangle que ya conocemos de entradas anteriores.

Casi todo lo que vamos a ver son esos pequeños detalles que forman parte de nuestra política de no dejar nada al azar, y que probablemente no supongan una gran diferencia por sí sólos, pero que en conjunto y adoptadas por todo el equipo, nos permiten generar una base de código de calidad en todos nuestros proyectos.

Vamos a describir las reglas leyendo la clase de arriba a abajo.

Cabecera

La cabecera es normalmente un fragmento de código comentado que se pone encima de cada fichero. Debería indicar a que proyecto pertenece, que tipo de licencia aplica y que personas han intervenido en ella.

Lo más habitual es utilizar alguna herramienta para asegurar que todos los ficheros tienen la cabecera correcta y esta está actualizada a la última versión.

/*
 * This file is part of the clean code example package.
 *
 * Copyright (c) 2016-2020 Devtia Soluciones.
 * All rights reserved.
 *
 * @author Daniel González <daniel@devtia.com>
 */
final class Rectangle
{
    //..
}

La definición de la clase

Nosotros intentamos por defecto ser lo más restrictivos posible, y luego ir abriendo la visibilidad según sea necesario. Por eso siempre declaramos nuestras clases por defecto como final. Una palabra reservada que nos permite indicar que la clase no puede extenderse.

Las constantes de clase

Nosotros habitualmente separamos las constantes en clases independientes. Por ejemplo, si quisiéramos poner los colores como constantes, es mejor crear una clase diferente para contenerlos. De esta forma mejoramos la semántica del dominio.

final class Color
{
    const WHITE = 'FFFFFF';
    const BLACK = '000000';
}

Atributos

Como norma general declaramos todos atributos como private. Si fuera necesario cuando realizamos un diseño, algunos de estos los declaramos como protected y evitamos siempre los atributos public salvo cuando se trata de DTOs.

Si tenemos atributos de diferente visibilidad dentro de una clase los agrupamos según su visibilidad.

Dentro de cada grupo, ordenamos los atributos por orden de importancia. Los más importantes arriba. También tratamos de agruparlos por tipo, para que estén todas las fechas juntas, todos las colecciones juntas, ...

final class Rectangle
{
    /* @var Point */
    private $topLeft;

    /** @var Color */
    private $backgroundColor;

    /** @var Color */
    private $borderColor;

    /* @var float */
    private $border;

    /* @var float */
    private $height;

    /* @var float */
    private $width;

    //..
}

El constructor y el resto métodos mágicos

A continuación de los atributos escribimos el constructor de la clase. Una clase no debería encontrarse en una situación inconsistente. Por eso el constructor debería recibir todo aquello que la clase necesita para existir. De esta forma evitamos por ejemplo la existencia de un Rectangle cuya altura está sin definir.

final class Rectangle
{
    //..
    public function __construct(Point $topLeft, float $height, float $width)
    {
        $this->topLeft = $topLeft;
        $this->height = $height;
        $this->width = $width;
    }
    //..
}

Los metodos mágicos son métodos que están definidos para todas las clases en php, y que son invocados cuando ocurre una circustancia concreta. Nosotros los definimos por orden alfabético después del constructor.

Los métodos públicos

Nosotros ordenamos los métodos agrupándolos por visibilidad. Arriba del todos los métodos public luego todos los protected y finalmente todos los private.

El autor nos indica que se deberían ordenar según su importancia y mantener los métodos relacionados cerca entre sí. Nosotros creemos que esto podría tener sentido en el momento de publicar el libro, pero es una regla dificil de aplicar, cuando por ejemplo un mismo método se llama desde diferentes métodos, ¿junto a cual lo pones?

Los editores modernos nos permiten navegar con facilidad entre métodos aúnque no estén cercanos entre sí, asi que nosotros simplemente los ordenamos alfabeticamente y configuramos el editor para que haga esto automáticamente por nosotros.

El resto de métodos

Los métodos que no son public deberían declararse private a menos que exista una buena razón para ello. Los ordenamos también por orden alfabético y dejamos que el editor se encarge de esta tarea.

Bloques de código

Para explicar esto es necesario traer un ejemplo un poco más complejo. Veamos un ejemplo real de uno de nuestros proyectos.

final class ProposalController extends AbstractProposalController
{
    //..
    public function copyAction(Project $proposal)
    {
        $this->throwNotFoundExceptionIfNotIsPublicProposal($proposal);

        $copyManager = $this->get('app.service.project_copy_manager');
        $publicProposal = $copyManager->generatePublicProposal(
            $proposal,
            null,
            \AppBundle\Entity\Project\Type::PUBLIC_PROPOSAL_CLIENT_VERSION
        );

        $manager = $this->get('app.service.project_manager');
        $manager->update($publicProposal);

        $this->addFlash('success', 'proposal successfully updated');

        return $this->redirectToRoute('_public.proposal.view', ['hash' => $publicProposal->getHash()]);
    }
    //..
}

Si ves el ejemplo anterior puedes ver que cada concepto está separado por un salto de línea. Lo primero que hacemos es la validación o cláusulas de guarda, de las que hablaremos en otra entrada más adelante.

Lo siguiente que hacemos es obtener una copia de la propuesta a través del servicio correspondiente. Después actualizamos esa copia, mensaje de éxito y redirección a la nueva propuesta.

Cada concepto está separado por un salto de línea facilitando su entendimiento al lector.

Ni un salto de línea de más

El último detalle. Ya hemos visto donde sí debemos poner un salto de línea. En nuestra opinión no se deben añadir saltos de línea adicionales, porque dan la sensación de estar ahí por que sí, en lugar de porque tienen que estar.

Empezemos describiendo los motivos por los que no deberías hablar con extraños: muchas veces cuando tenemos una clase que a su vez está formada por objetos de otras clases y estas a su vez por otras, tenemos una estructura de clases. Hasta aquí todo bien, pero: ¿qué ocurre cuando estas estructuras se vuelven complejas? Veamos un ejemplo que podría darse en un comando de symfony.

class CustomCommand extends Command
{
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $this->getApplication()->getKernel()->getContainer()->getCustomService()->getManager()->execute();

        return 1;
    }
}

Como puedes ver, estamos acoplando de forma innecesaria nuestro código a todas las clases que aparecen en la cadena de llamadas. Cualquier cambio en estas clases o en las relaciones entre ellas podría suponer que nuestro código dejase de funcionar. Para que esto no suceda viene al rescate la ley de demeter.

La ley de demeter

La ley de demeter fue descrita por primera vez dentro del proyecto demeter en 1987. Como curiosidad quiero contarte que Demeter, hace referencia a la diosa griega de la agricultura. Querian hacer referencia a algo así como "cultivar" software en contraposición a "construir" el software.

La ley indica que desde un método solo deberías "hablar" con aquellos a quien conozcas bien. Y estos son:

• Métodos de la misma clase.
• Métodos de los objetos de la clase.
• Métodos de los objetos creados en la misma función.
• Métodos de los objetos pasados como argumento a la función.

¿Y cómo lo soluciono?

Ya hemos detectado que es lo que no debes hacer, te voy a proponer ahora tres opciones a tener en cuenta cuando detectes este problema en tu código.

No hacer nada

La primera es no hacer nada. Es la solución más sencilla, y la peor de las tres que vamos a ver, pero como ya vimos en la entrada sobre los dogmas en el desarrollo de software, si crees que las clases que estás llamando y sus relaciones están muy consolidadas, podrías permitirte el lujo de realizar este tipo de llamadas en cadena.

Usar atajos

La segunda consiste en hacer atajos que permitan evitar estas llamadas encadenadas. Esta es una solución bastante rápida, que te puede permitir salir del paso en algún momento.

Por ejemplo en CustomService podríamos añadir el método executeManager.

class CustomService
{
    public function executeManager(): void
    {
        $this->getManager()->execute();
    }
}

Esta solución como puedes imaginarte tampoco es la mejor. Te permite abstraer parte de esa cadena de llamadas y por lo tanto es una opción mejor que al principio, ya que si la relacion cambia sólo tendrás que cambiar en este punto las llamadas.

El problema de esta solución es que puedes encontrarte con tu código con un montón de estos métodos atajos, que realmente por diseño no deberían encontraser ahí, pero están simplemente para hacer cumplir la ley de demeter.

Inyectar dependencias

La solución buena, como probablemente ya te venías imaginando es inyectar las dependencias. Veamos un ejemplo.

class CustomCommand extends Command
{
    public function setCustomManager(CustomManager $customManager)
    {
        $this->manager = $customManager;
    }

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $this->manager->execute();
    }
}

Hemos añadido como dependencia la clase CustomManager que era la que realmente necesitamos, y se la hemos inyectado a través de un setter, pero hemos eliminado toda la cadena de dependencias y las relaciones entre sí.

Con este sencillo cambio hemos podido eliminar fácilmente todas las dependencias sobrantes.

La semana pasada publicamos una entrada sobre el uso de los comentarios. En ella explicábamos que siempre que puedas deberías evitar el uso de comentarios.

Argumentábamos que cuando utilizas un comentario para explicar un código que no se entiende con facilidad, no estás mejorando tu código, sino que estás poniendo una piedra en tu camino. Tu código sigue siendo igual de difícil de entender y además ahora te tendrás que ocupar de mantener esos comentarios actualizados. Lo cual no aporta valor a tu proyecto.

Muchas personas nos han escrito tanto por Linkedin, Twitter, Youtube y el grupo privado que tenemos en Telegram para tratar temas del canal.

Nos han indicado diferentes ejemplos en el que era muy difícil eliminar los comentarios o directamente no se podían. No quiero entrar aquí a revisar cada uno de los ejemplos, pero tras revisarlo con el equipo, era evidente que eran buenos ejemplos. En esos casos, los comentarios si ayudaban a mejorar el código.

Es por eso que quiero hablar un poco sobre los dogmas.

Los dogmas en el desarrollo de software

Existen por supuesto muchos dogmas en el mundo del desarrollo de software, seguro que te suenan algunos de estos:

1. Si no haces scrum estricto no haces scrum.
2. No se puede sacar adelante un proyecto sin pruebas automáticas.
3. En 2020 todo el mundo tiene que hacer DDD.

Estas y otras muchas que se te ocurran las hemos escuchado todos cientos de veces.

Poner un hombre en la luna

Corría el año 1957, estados unidos y la unión soviética se encontraban enfrascados en mitad de la guerra fría, cuando los soviéticos pusieron por primera vez un satélite en órbita, el sputnik. Esto supuso un gran varapalo para la sociedad americana, que crearía la NASA. Había comenzado la carrera espacial.

12 años más tarde en cabo cañaveral despega un cohete con tres astronautas y una misión: "poner un hombre en la luna". Los estados unidos tuvieron que hacer un gran esfuerzo en el desarrollo de la tecnología informática, ya que aquel cohete tenía un computador capaz de guiarlo. Ese computador por supuesto ejecutaba software, y ese software fue programado 30 años antes de que se publicara el manifiesto ágil.

Es decir que sin las consideradas mejores prácticas del momento actual, sin el framework de moda, este equipo de programadores fueron capaces de diseñar y programar un software que puso a un hombre en la luna.

La flexibilidad y empatía

Lo mejor es ser capaz de adaptarse a cada situación, este es el único dogma que te tienes que grabar a fuego.

Pensar que sólo hay un camino para hacer las cosas bien es cuando menos una postura algo miope. Si alguien piensa que su metodología / tecnología / framework / loquesea es netamente superior a las todas las demás está evidentemente equivocado.

Te voy a poner un ejemplo personal. La técnica del diseño dirigido por test (TDD) es una técnica que te ayuda a diseñar software escribiendo primero las pruebas y luego el código de producción. Al hacerlo al revés, haciendo primero las pruebas, te ayuda a que pienses en tu diseño desde fuera hacia dentro, en lugar de como lo harías habitualmente, desde dentro hacia afuera.

Yo estuve haciendo TDD durante aproximadamente un año. Después dejé de hacerlo. ¿Por qué? Pues por dos motivos. Primero porque una vez que asimilas bien la metodología, vas a ser capaz de pensar desde fuera hacia dentro sin necesidad de escribir primero el test y segundo porque en muchos proyectos el diseño no es algo crucial.

En mi opinión tu criterio vale más que lo que alguien escribiera en un libro en la punta del mundo hace veinte años.

No dejes de aprender

Que los dogmas no sean realmente dogmas, no es una excusa para no seguir aprendiendo o mejorando. En mi opinión es tu responsabilidad como buen profesional ir mejorando cada vez tus capacidades.

Además es una buena forma de disfrutar de nuestra profesión y por que no decirlo de ganar cada vez más dinero. No se paga igual de bien a alguien que programa en el lenguaje "a pelo" que a un "tope de gama" en la última metodología o framework de moda.

Te propongo algunos consejos para que no dejes de aprender.

Busca un buen proyecto La forma más fácil de seguir mejorando es dedicar ocho horas al día a mejorar, y para ello debes elegir tu puesto de trabajo en función de donde más vayas a aprender. El dinero y otras ventajas deberían pasar a un plano secundario. Da igual que ganes menos dinero el año que viene, lo importante es cuánto dinero vas a ganar el resto de tu vida.

Sigue canales de youtube y podcast de la temática. Una buena forma de seguir aprendiendo es este tipo de contenidos que suelen tener una alta calidad, y no requieren de demasiado esfuerzo, ya que puedes ver este video, mientras que vas en el tren de camino al trabajo o mientras esperas a un amigo.

Asiste a conferencias y meetups. Es una forma fácil de aprender y de conocer gente. Nunca vas a aprender sobre todo, pero si tienes el teléfono del que sabe, también puede servir.

Lee libros En comparación con los anteriores es el que más esfuerzo o disciplina requiere, pero si no quieres que te den gato por liebre lo mejor es acudir a la fuente. Leer un libro al año, puede marcar la diferencia.

No olvides apuntarte a nuestra academia, para recibir todas las semanas un nuevo video sobre desarrollo de software

bloques de código

Por regla general deberías evitar el uso de comentarios. Los comentarios pueden parecer una herramienta muy útil ya que cuando estamos desarrollando puede que nos encontremos con que queremos explicar mejor cómo funciona nuestro código o por que hemos tomado una determinada decisión.

Pero cuando usamos un comentario de código donde antes teníamos un problema: que nuestro código no era suficientemente sencillo de entender, ahora tenemos dos: nuestro código sigue sin entenderse con facilidad, y ahora además debo ocuparme de mantener los comentarios que he realizado.

Puedes pensar que mantener ese comentario no es mucho trabajo, pero que tal si esa energía qué has gastado en mantener un comentario la hubieras gastado en hacer algo más productivo. ¿mejor, no?.

Vemos un ejemplo con el TokenStorage del componente Security de Symfony.

namespace Symfony\Component\Security\Core\Authentication\Token\Storage;

use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Contracts\Service\ResetInterface;

/**
 * TokenStorage contains a TokenInterface.
 */
class TokenStorage implements TokenStorageInterface, ResetInterface
{
    // ..
    public function setToken(TokenInterface $token = null)
    {
        if ($token) {
            // ensure any initializer is called
            $this->getToken();
        }

        $this->initializer = null;
        $this->token = $token;
    }
    //..
}

El autor de este código necesitaba hacer algunas llamadas antes de configurar el token. Se dio cuenta que que no era sencillo de entender y que otra persona que viniera detrás probablemente no entendería el motivo de esa llamada, asi que utilizó un comentario para aclararlo todo. ¿Pero que te parece si hubiera hecho esto?

namespace Symfony\Component\Security\Core\Authentication\Token\Storage;

use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Contracts\Service\ResetInterface;

/**
 * TokenStorage contains a TokenInterface.
 */
class TokenStorage implements TokenStorageInterface, ResetInterface
{
    // ..
    public function setToken(TokenInterface $token = null)
    {
        if ($token) {
            $this->callInitializer();
        }

        $this->initializer = null;
        $this->token = $token;
    }

    private function callInitializer(): void
    {
        $this->getToken();
    }
    //..
}

Como ves hemos eliminado el comentario y hemos mantenido e incluso mejorado la expresividad, ya que el código es igual de explícito. Por lo tanto siempre que nos veamos en la necesidad de añadir comentarios, debemos plantearnos si podríamos mejorar la expresividad de nuestro código mejorando los nombres que estamos utilizando o extrayendo métodos como en el ejemplo.

DocBlock y documentación autogenerada

Algunos editores de texto añaden documentación de forma más o menos automática que permite indicar los tipos de los argumentos y del valor devuelto, así como información adicional.

Veamos un ejemplo

    /**
     * get movements
     *
     * @return array
     */
    public function getMovements()
    {
        return $this->movements;
    }

Este tipo de documentación no aporta ningún valor adicional ya que simplemente está repitiendo lo mismo que ya dice el nombre de la función. Quizá esto tenía sentido antes de la versión 7, para ayudar al IDE en el autocompletado. Pero a partir de esta versión es mucho mejor eliminar estos comentarios y utilizar el tipado nativo del lenguaje.

   public function getMovements(): array
    {
        return $this->movements;
    }

Usos permitidos

Por supuesto el autor contempla algunos casos en los que sí estaría permitido y justificado el uso de comentarios.

Licencias y textos legales

Es un uso completamente justificado el incluir la licencia y otros textos legales en el encabezado de nuestros ficheros. Además esto no supone ningún trabajo adicional, por que es habitual utilizar sistemas que se encargan de añadir estos comentarios de forma automática, y además los IDE suelen ocultarlos por lo que no molestan.

APIs

Si estás construyendo una api y probablemente quieras generar la documentación a través de algún sistema automático, sí estaría justificado el incluir toda esta información adicional en tu código.

Evita el uso de contracciones

Esta es la primera regla y la más sencilla de todas. Cuando programamos, podemos caer en la tentación de crear pequeñas contracciones, dentro de la api de linux por ejemplo nos encontramos con un montón de ellas como por ejemplo mv, cp, chmod y muchas más.

Cuando escribes una contracción puede que en ese momento a tí te parezca obvia, pero es posible que para otra persona en otro contexto no lo sea tanto, así que no merece la pena ahorrarse unos caracteres a cambio de los problemas que puedas generar en el futuro.

Además esta regla te permitirá no entrar en conflicto con la siguiente que es la consistencia. Si usas una contracción en una variable o método, ¿Por qué no usarlo en todas las demás? ¿En cuáles sí y en cuáles no? Acabas de crear un problema donde no lo había.

Sé consistente

Una de las características que vimos del código limpio es que no es fácil de mejorar. Eso significa que el código es consistente. Si has decidido por ejemplo llamar Lesson a la entidad que representa a un profesor, una asignatura, una colección de alumnos y un momento concreto en el tiempo, no deberías utilizar ningún tipo de sinónimos.

Otro elemento que debes tener en cuenta a la hora de producir nombres consistentes es utilizar siempre los mismos verbos para una determinada tarea. Por ejemplo si has decidido que cuando accedas a un repositorio y recuperes un conjunto de lecciones vas a utilizar el verbo get generando nombres del tipo getByUser(), getByState(), getByDate() deberías evitar usar sinónimos del verbo get, como por ejemplo fetchByUser(), findByState(), retrieveByDate().

Utiliza el contexto

Evita repetir conceptos que ya están claros a través del contexto. Continuando con el ejemplo anterior, si estás escribiendo un método dentro de LessonRepository para buscar lecciones por su estado no necesitas indicar que estás buscando lecciones getLessonsByState. Ya te encuentras dentro de LessonRepository así que todos sus métodos deberían devolver por colecciones de lecciones. Debes evitar repetir "Lessons" en cada nombre, siendo getByState() más adecuado./p>

Deberías evitar usar nombres demasiado largos, así como deberías evitar usar nombres demasiado parecidos. Si te encuentras en una situación en la que estás escribiendo un nombre demasiado largo deberías evaluar si puedes utilizar el contexto para generar un nombre más corto.

Por ejemplo si tienes la clase UniversityLessonState que contiene los estados posibles de una lección de la universidad, podrías generar un nuevo namespace del tipo University\Lesson\State obteniendo un nombre de clase mucho más corto y fácil de leer, pero sin haber perdido ningún tipo de información.

Si necesitas dos palabras para definir el nombre de una clase es probable que necesites crear un nuevo contexto, y si necesitas tres palabras definitivamente deberías crear un contexto nuevo.

Hace lo que dice que hace

Entramos en la parte final de las recomendaciones. Sin embargo estas dos últimas son las más importante de todas. Cuando eliges un nombre lo más importante es ser sincero. El nombre que estás eligiendo tiene que servir para identificar qué es lo que contiene.

En general debemos evitar nombres genéricos como data, info, resume, items. En algunos momentos muy concretos puede que tengan sentido, ¿pero que contienen exactamente?. Quizá el autor no sabía que nombre poner y eligió uno de estos.

Si lo que queríamos crear era por ejemplo un conjunto de lecciones filtradas por algunos criterios, podríamos haber elegído lessons o filteredLessons al menos indica que contiene un conjunto de lecciones.

Debemos también evitar nombres que definan qué es lo que necesita el autor en lugar de que es lo que hace un método o clase. Por ejemplo LessonRepository::getForDashboard. Tenemos claro que el autor necesitaba una colección de lecciones para mostrarlas en el dashboard, pero no tenemos ni idea de que criterios tiene en cuenta. Si el criterio para mostrar las lecciones en el dashboard fuera que pertenecieran a un determinado usuario, que estuvieran en un rango determinado de fechas, como por ejemplo los próximos 15 días, y se encontraran en un determinado estado, podríamos haber elegido LessonRepository::getByUserFromToAndState.

Explica cómo debe usarse

Llegamos al último punto. Una vez que has encontrado el nombre adecuado que cumple todos los anteriores requisitos debes plantearte una última pregunta.

¿Explica mi nombre cómo debe ser utilizado? Veamos un ejemplo supongamos que tenemos una clase que se encarga de realizar cambios sobre las lecciones LessonManager::changeDate, el contexto LessonManager nos indica que la entidad que va a modificar es una Lesson y el nombre nos revela que la va a cambiar de estado.

Por coherencia los argumentos deberían ser Lesson, Date en este orden. Sin embargo podemos ayudar a evitar malentendidos, nombrando correctamente los argumentos. LessonManager::changeDate($lesson, $toDate) no deja lugar a ningún tipo de equivocación.

Conclusiones

Cuando escribimos código limpio debemos tener en cuenta a la persona que lo va a leer, y cuando elegimos nombres debemos elegirlos pensando primero en esa persona en hacerle la vida lo más fácil posible.