Castaña Driven Development

Verdura — Wed, 13 Aug 2025 20:22:12 +0000

Introducción en la metodología de trabajo.

Programación por "sensaciones", cortoplacismo, microgestión, y otra serie de plagas que nos hacen la vida imposible.

En este capítulo os traigo una serie normas para trabajar en consultoría mediocre que os sacarán una sonrisa, o no. Cualquier parecido con la realidad es una mera casualidad.

CDD aplicada al desarrollo.

Idiomas en el código.

Una aplicación es CDD Compliant when the code is básicamente en (1, N) idiomas y no tiene sentido en ninguno. Ejemplo:

 <?php
// Since UID t specified in the $connectionInfo array,
// The connection will be attempted using Wi
$usuario = "por_favor_no_me_pongas_másTICKETS";
$pass = "123456789"; //(Recomendada por los mejores expertos en ciberseguridad)

function familyName($a, $b) {
 try {
        mysql_connect('mysql_host', $a, $pass);
        return "Ok";
    }
    catch (Exception $e) {
        echo "NO FUNCIONA";
    }
}
echo familyName($usuario, $pass);

Gestión de dependencias

El límite lo pone el disco duro principalmente. Eso de eliminar lo que no usas, o actualizarlo en la medida posible no es del todo compatible con el patrón CDD.
No tiene sentido preocuparse hasta que se llene tu repositorio de artefactos, o tardes 45 minutos de instalación.

¡Recuerda! Si no te cazan, todo va bien. ¿Qué es lo peor que puede pasar, que la aplicación vaya a mejor y sea más segura?

Autores del código

Si no hay sistema alguno de control de versiones, el/la autor/a siempre puede ponerse la diana en la espalda de forma manual.
Ejemplo:

 /**
  * TODO: Hacer que funcione
  *
  * @author Verdura
  */
public static void dropDatabaseS_inConFirMAR(
        String host,
        int port,
        String user,
        String password,
        String databaseName
)

Gestión de errores

En aras de optimizar el coste de la aplicación, el patrón CDD recomienda siempre delegar la observabilidad al cliente. Es decir, que te contacte él diciendo el mensaje de error.

Si el cliente no sabe lo que es 0X42358724 LANG ERROR CRITICAL FAILURE, es un problema con su formación, no con que alguien quiera dividir algo por cero. Capturar las excepciones está penado por la CDD Alliance.

Infraestructura

Nube pública y contenedores.

Efectivamente, está por llegar una tormenta de despidos cuando llegue la factura del proveedor. Sólo apta para millonarios, la nube permite engañar como servicio a la gente pensando que el patrón CDD aplicado en el servidor de un externo va a servir para algo.

El método CDD siempre recomienda aislar el código en contenedores, que es la versión triste de la virtualización. Esto permite ahorrar recursos sin tener que emular un sistema operativo completo y pagar por usar un servicio gestionado de Kubernetes o similares por el doble de coste y la mitad de rendimiento. Fuente: VCores vs Cores

CI/CD

CI/CD, al contrario que mucha gente piensa, no es ningún grupo de Rock, sino que se trata de dos tipos de procesos distintos.

CI

CI (Continuous integration):

Consiste en enviar el código a un repositorio central de código (OPCIONAL), pasar test de tu app (MUY OPCIONAL), generar un artefacto (OPCIONAL) y y enviarlas en algún sitio como un repositorio de artefactos, por que es un poco raro seguir este flujo para no hacer nada con el código.

Una buena práctica de CI aplicado CDD, es generar una imagen de Docker con tu apliación y luego al montar la imagen de Docker publicar una versión de tu código en el repositorio de artefactos. Por ejemplo: Generar una imagen de Docker de una aplicación escrita en Node y luego subirla como paquete de NPM.

CD

CD (Continuos Delivery):

Consiste en desplegar lo que genera el CI.

Hay múltiples estrategias de despliegue, por ejemplo, desplegar en un entorno de pruebas y cuando sea estable (OPCIONAL) promocionarlo a entorno productivo, reemplazar las réplicas antiguas gradualmente cuando la aplicación está ya lista para recibir peticiones... etc.

Y luego, la 3ª opción, que es conectarse al servidor por escritorio remoto y abrir el IDE de confianza y ahorrarse todo este proceso bonito sobre el papel, pero no siempre neceseario.

Infraestructura como código

Dado que escribir código CDD es tendencia, sería discriminatorio que el departamento de Sistemas / DevOOOPS / SecDevOOOPS / Plataforma de Ingeniería no siguiera convenciones parecidas.

Gracias a herramientas como Terraform / OpenTofu / Pulumi puedes escribir lo vergonzoso / innecesariamente complejo que es el estado de tu infraestructura. Creas bloques de código que se conectan a la API del proveedor que uses y luego te llega una factura millonaria por que había cosas que no habías declarado por que lo hiciste a mano en 1742.

También hay herramientas como Ansible, el que gestionas el mantenimiento / setup de los servidores, etc... Por ejemplo, para automatizar instalación de paquetería, propagar configuraciones, etc..

Conclusiones

Huid de cualquier entidad que aplique CDD.
Queda pendiente CDD aplicado a gestión de equipos.

QA de ofertas de empleo

Verdura — Sat, 29 Feb 2020 17:30:42 +0000

Últimamente las ofertas de trabajo son bastante vacías. Se dan situaciones absurdas como no saber para qué cliente vas a trabajar o cuántos días de vacaciones vas a recibir. ¿Merece la pena una oferta de la compañía de mis sueños si no sé qué quieren para su proyecto?

Viendo desde el punto de vista del empleador, ¿por qué nadie me responde a mis ofertas de trabajo? Si soy de una empresa de selección de personal, ¿cómo le hago entender a mi cliente que ha de darme más detalles?

Por ello necesitamos una manera de hacer ver a los demás desde un punto de vista matemático si una oferta es buena. Para ello desarrollé el proyecto qa-empleo

Aunque todos los criterios son subjetivos por que no todo el mundo busca el mismo tipo de trabajo, con qa-empleo quiero crear una forma de poder evitar que por ejemplo, por querer trabajar en una compañía famosa acabemos frustrados por no tener en cuenta aspectos como el teletrabajo o que el proyecto no es lo parecía

El proyecto está muy muy verde,me falta calcular la rotación histórica (ratio de trabajadores que abandonan la compañía) a través de la api de LinkedIn.

El proyecto en sí no es más que un script que se ejecuta de la siguiente forma:

python3 qa-empleo.py nombre-de-la-empresa nota-tipo-contrato nota-ubicación-cliente nota-requerimientos-cliente nota-vacaciones nota-salario nota-horario nota-teletrabajo

El script mostrará por pantalla la rotación histórica del proyecto y si la oferta es buena (la nota ha de ser superior a 6)

Si os gusta la idea cualquier sugerencia es bienvenida, bien por aquí, bien mediante un issue en el repositorio del proyecto.

DEV Community: Verdura