Devops Parte 1: Creación proyecto .net pruebas unitarias

Mario Ernesto Villanueva Gutierrez — Sat, 03 Sep 2022 05:22:57 +0000

Creación del proyecto

Paso 1: Crear proyecto .net

Abra visual studio community
cree nuevo proyecto Web APi
Seleccione .net 6, open api
* Opcional: en mi caso no usar minimalApi

Paso 2: Crear proyecto de test

Cree nuevo proyecto xUnit
seleccione .net 6

Paso 3: Agregar dependencias en el proyecto de test

Agregar paquetes nuget coverlet.collector -- Clic derecho sobre el proyecto -> Administrar paquetes nuget -> buscar coverlet.collector -> instalar
Agregar paquetes nuget coverlet.msbuild -- Clic derecho sobre el proyecto -> Administrar paquetes nuget -> buscar coverlet.msbuild -> instalar
Agregar paquetes nuget Xunit.DependencyInjection
-- Clic derecho sobre el proyecto -> Administrar paquetes nuget -> buscar Xunit.DependencyInjection -> instalar
Resultado final

Paso 4: Configuración

Crear api desde un controller que exponga un hola mundo

Crear prueba unitarias asociada al api

Paso 5: Generación de reporte coverage.xml
dotnet test .\microservicio.dotnet.test\microservicio.dotnet.test.csproj /p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:CoverletOutput='coverage.xml' --configuration Release --no-restore

El software es como limpiar la cocina

Mario Ernesto Villanueva Gutierrez — Sun, 28 Aug 2022 05:08:37 +0000

Uno de las premisas que he escuchado durante mi experiencia laborar en los sistemas informáticos es la siguiente frase: "Si funciona en producción no lo toques", frase escuchada una y otra vez, que nos indica en el buen sentido de la palabra, con letras despampanantes, marcadas en rojo y subrayado, que no toquemos absolutamente nada, para que todo siga tal y como estaba.

Cada vez que lo escucho eso me imagino esto:

Porque no?

la cocina sigue prendiendo fuego, el cuchillo sigue cortando, aah pero claro no toquemos nada!

De alguna manera es verdad, sería lo más lógico que producto de nuestras buenas intenciones algo deje de funcionar.

La manipulación del software genera incertidumbre por parte de los usuario del sistema y sería mal visto que nuestras buenas deseos terminen dejando algo sin funcionar en producción, Entonces pregunto:

¿Vale la pena tocar algo productivo que ya esta funcionando?

Yo creo que si, pero antes veamos algunos antecedentes importantes que vale la pena mencionar para entender más el contexto:

Entropía del software

Wikipedia nos indica que "es la medida de desorden del software que refleja la complejidad de su mantenimiento" (https://es.wikipedia.org/wiki/Entrop%C3%ADa_del_software)

Manipulación de código por muchos desarrolladores

Una de las grandes realidades de los productos es la manipulación del código por diversos desarrolladores que pasan por el sistema en función del tiempo, los que han tenido que realizar correcciones y/o nuevas implementaciones, adoptando el mismo estilo arquitectónico que poseía el software, implementándolo medianamente bien o de plano de forma incorrecta, o simplemente poniendo su propio sello en el código. Creando un código con muchos estilos y formas de mirarlo.

Poca expertis / tiempos de entrega

Un punto importante y no menor es la responsabilidad de muchas empresas en colocar a profesionales de nivel jr en puestos que requieren un conocimiento más alto. Muchos de ellos sin entender del porque están ahí, poniendo su mejor esfuerzo para sacar adelante la difícil tarea de entregar sus desarrollo a tiempo, luchando con tratar de entregar todo para ayer. Predicando la palabra de "stackoverflow es mi pastor", copiando y pegando código muchas veces sin entender, pero al fin y al cabo solucionando el problema puntual, creyendo que por que esta en stackoverflow es ley.

Entonces, ¿Cuales son los beneficios de modificar un código que ya esta funcionando en producción?

yo creo que muchos:

Limpiar la cocina antes de trabajar: antes de todo es muy importante limpiar donde vamos a trabajar. Limpiar el código fuente, factorizar funciones, normalizar nombres de variable, quitar código comentado, quitar código que no se ocupa, nos ayuda a entender que elementos tenemos disponibles para trabajar, a crear una mapa mental de donde va cada cosa tiene su propio lugar.
Quedarnos con lo que realmente importa: te has fijado cuando tienes el pelo largo o no te has arreglado en varios días, luego vas a la peluquería sales como una persona renovada? Esto es exactamente igual. Al quedarnos con lo que realmente es vital para un caso de uso, nos deshacemos de lo que no necesitamos, sacándonos ese peso extra que llevamos en nuestro hombros (en este caso en nuestro código), permitiéndonos una vez más aclara la visión de que tenemos que hacer y dónde lo vamos a hacer.
No trabajamos solos: han escuchado el que significado UX? de breves líneas vendría siendo (espero no me maten mis amigos Uxs): "entregar valor a cada uno de los usuarios del sistema, entendiendo sus dolores, haciendolos participes en la construcción de cambios, haciendolos los principales participes en cada uno de los punto de contacto de nuestros proceso". Dada esta estupenda explicación, tenemos que entender que nuestros pares son nuestros usuarios, y tenemos que hacer que en cada vez que tocan nuestro código fuente, sientan la mejor experiencia que puedan tener mientras trabajan.

Ustedes no se imaginan el dolor de cabeza que puede llegar a ser ver una ensalada de código arrojado, tirado y desparramado sobre una pieza de software. Pienso que si podemos hacer un código más legible para la siguiente persona que tocará el código todos saldremos beneficiado. Porque le haremos su trabajo más placentero y nos quedaremos con la sensación que la experiencia que vivió fue la mejor.

Entonces ya en este punto podemos preguntarnos ¿Cómo es factible asegurar que los cambios realizados no afecten el normal funcionamiento del sistema?.

A continuación te presento de manera breve algunas estrategias y/o principios que aplico cuando me veo enfrentado a este tipo de situaciones.

Pruebas unitarias: Lo primero que necesitamos dejar en manifiesto es saber el comportamiento de lo que estamos modificando, la mejor manera es por medio de pruebas unitarias. La pruebas unitarias nos permitirá tener la capacidad de dejar en evidencia que los resultados finales no cambien. Esto es importante, porque necesitamos marcar un presedente de lo que estaba cuando comencemos a mover el código.
Don't repeat yourself : Este principio, nos habla a grandes rasgos que cada elemento de nuestro código es único y dentro nuestro sistema no puede ser repetido. Principio de responsabilidad única: Principio perteneciente a los principios SOLID (wiki), que nos dice que cada una de las parte del código tiene que tener un sólo objetivo, una sola responsabilidad.
SonarQube: Es importante tener bajo nuestro repertorio un marco de trabajo o estilo de programación. Sonar es el framework perfecto para aprender sobre la calidad del software. Es una herramienta que evalúa nuestro código y nos indica que parte de el se encuentra fuera de regla, regla que ha sido estandarizada por una comunidad que sugiere las buenas prácticas de programación.
Eliminar código que no se ocupa: Es importante siempre siempre tener en nuestro sistema sólo lo que ocupa, lo no se va ocupar dentro del código a la basura, se ocupa? no. entonces borrelo.
Eliminar código comentado: git! su mejor amigo es git, es el mejor mecanismo para el código que podría servir en un tiempo que jamás llegará. y si llega? revise el historial de la pieza.
Tener presente la complejidad ciclomatica: La complejidad ciclomatica es la forma elegante de decir que el código es complejo de leer, dado la cantidad de clausulas ocupadas. Una función no debería tener más de par de líneas de código y debe ser simple de leer a ojo de lectura - Ojalá existiera la regla que indique que toda función sea escrita en lo largo de un tweets -.

Finalmente es importante destacar, que refactorizar un código no es una tarea fácil, siempre puede conllevar sin sabores, pero una vez que se consigue la gratificación es mucho mayor.

Nunca es tarde para intentar trabajar en una cocina limpia y ordenada!!!

Un abrazo.

Para quien programamos?

Mario Ernesto Villanueva Gutierrez — Thu, 11 Aug 2022 05:27:21 +0000

La primera respuesta que se me viene a la mente sería para uno mismo, en segundo lugar quizás por temas profesionales. Otros podrán decir que por hobby y otros podrían decir porque es una pasión.

Cualquier sea el caso, razón o necesidad permitame proponer otra idea sobre la palestra, y que ojalá sería de mi más profundo agrado que usted señor leyente pueda reflexionar.

Yo propongo que deberíamos programar para el próximo ser vivo que tome nuestro código. Como así? creo que usted debería pensar que después de usted hay otro ser humano que hará un esfuerzo enorme por entender lo que usted hizo. Entonces, que pasa si yo sé que existirá ese alguien y programo pensando bajo ese escenario y el siguiente ser piense de la misma forma, y así seguidamente hasta el fin de los fines de la tierra, generando una cadena de valor en nuestro código y erradicando ese odio profundo en aquel código que fue escrito con sufrimiento, pena y dolor.

Yo quiero pensar que este acto tan generoso produce un sinergía en el código, quiero creer que el siguiente ser sentirá una energía positiva cuando lea nuestro código y diga: "woow que legible es este código, todo tan ordenado" y toda esa buena atmósfera la transforme en algo más que buenas intenciones, la transforme en un código que realmente sea significativo para él y quien sabe para usted señor lector, tal vez cuando usted tome un código con esta características, siente este valor agregado y usted ponga mucho más de usted cuando este creando variables y clases.

Finalmente recordarle que cuando las cosas se hacen con amor, las cosas funcionan mucho mejor.

Atte el psicologo del código.

DEV Community: Mario Ernesto Villanueva Gutierrez

Devops Parte 1: Creación proyecto .net pruebas unitarias

Creación del proyecto

El software es como limpiar la cocina

Para quien programamos?