Entrega Architecure Debt

.github/workflows/buildandtest.yml

@@ -4,6 +4,7 @@ on:
   push:
     branches:    
       - main
+      - Primera_Entrega
 
 jobs:
   build:
@@ -13,20 +14,6 @@ jobs:
     steps:
       - uses: actions/checkout@v3
 
-      - name: Setup .NET Core SDK 3.1
-        uses: actions/setup-dotnet@v2
-        with:
-          dotnet-version: 3.1.x
-
-      - name: Setup .NET Core SDK 5
-        uses: actions/setup-dotnet@v2
-        with:
-          dotnet-version: 5.0.x
-
-      - name: Setup .NET Core SDK 6
-        uses: actions/setup-dotnet@v2
-        with:
-          dotnet-version: 6.0.x
 
       - name: Setup .NET Core SDK 7
         uses: actions/setup-dotnet@v2
@@ -39,14 +26,6 @@ jobs:
       - name: Build
         run: dotnet build src/RestClient.Net.sln --no-restore
 
-      - name: Test on .NET Core 3.1
-        run: dotnet test src/RestClient.Net.UnitTests --no-build --verbosity normal --framework nercoreapp3.1
-
-      - name: Test on .NET 5
-        run: dotnet test src/RestClient.Net.UnitTests --no-build --verbosity normal --framework net5.0
-
-      - name: Test on .NET 6
-        run: dotnet test src/RestClient.Net.UnitTests --no-build --verbosity normal --framework net6.0
 
       - name: Test on .NET 7
         run: dotnet test src/RestClient.Net.UnitTests --no-build --verbosity normal --framework net7.0        

.gitignore

@@ -1,10 +1,11 @@
-*.Designer.cs
+	*.Designer.cs
 *.csproj.user
 /.vs/RESTClient .Net/v14/.suo/
 /NuGet/Exported/
 bin/
 obj/
 packages/
+.sonarqube/
 /.vs/restore.dg
 /RESTClientDotNet.Net/.vs
 /CF.RESTClientDotNet.Net/.vs/*.dg

CSDT-2024.md

@@ -0,0 +1,119 @@
+# Refactoring + Code Smells
+## Code Smells
+- Se detect� uso Excesivo de desactivaci�n de advertencias relacionadas con diferentes code smells
+	- Las categorias mas desactivadas son:
+		- **Nombramiento de variables**: Se relacionan con la nomenclatura de las variables.
+		- **Inicializaci�n de variables**: Se relacionan con la no inicializaci�n de las variables no nulas.
+		- **Correcto uso de los tipos de datos**: Se relacionan con el uso correcto de los tipos.
+- Se detect� caso omiso deliveradamente a las advertencias del IDE, incluso cuando estas estan marcadas como errores.
+- Se detect� una clase Dios, la cual tiene una cantidad excesiva de m�todos y atributos, alrededor de 350 lineas de c�digo para la clase principal.
+- Falta de buenas pr�cticas.
+- Insuficiente documentaci�n y comentarios en el c�digo.
+- Pruebas unitarias existentes no son detectadas.
+- Desorganizaci�n en el proyecto de pruebas.
+- Se detect� TODOs sin resolver.
+- Hay poco uso de carpetas para organizar y agrupar el c�digo.
+- Hay mucho codigo dedicado a suprimir advertencias del IDE.
+- Los namespaces no corresponden a la estructura de carpetas y la advertencia se suprime.
+- La arquitectura Modelo Vista Controlador solo se aplica en ciertas partes del proyecto.
+- Esta joya: 
+		- //Note: not sure why this is necessary...
+		- RestClient.Net/DefaultGetHttpRequestMessage.cs Linea 69.
+		- Clase llamada "Stuff.cs" con ning�n comentario que la explique.
+		- //Is this good?
+		- RestClient.Net.Abstractions/CallExtensions.cs Linea 66
+
+## Tecnicas de Refactoring Recomendadas
+- **Renombrar variables**: Se recomienda cambiar el nombre de las variables para que sean m�s descriptivas.
+- **Extraer m�todos**: Se recomienda extraer m�todos para que cada m�todo haga una sola cosa.
+- **Eliminar c�digo muerto**: Se recomienda eliminar c�digo que no se utiliza.
+- **Eliminar comentarios innecesarios**: Se recomienda eliminar comentarios que no aportan informaci�n.
+- **Solo implementar codigo que se necesita**: Si no se entiende que hace algo, es mejor no implementarlo.
+- **Sustituir Valores por Referencias**: Se recomienda cambiar los valores primitivos por referencias cuando sea posible.
+- **Cambiar la arquitectura del Proyecto**: Se recomienda refactorizar y cambiar la arquitectura del proyecto para que sea m�s f�cil de entender y mas escalable.
+- **Adaptar el proyecto para que sea Open Source Friendly**: Si se va a dejar de desarrollar el proyecto, se recomienda adaptar el proyecto para que sea m�s f�cil de entender y mantener por otros desarrolladores anonimos.
+- **Adaptar los pipelines**: Los pipelines de Github Actions se pueden mejorar para que analicen mas aspectos del c�digo y despues de creados no deben ser ignorados.
+
+## Caracteristicas de Clean Code que se cumplen y no se cumple
+- **KISS (Keep It Simple, Stupid)**: No se cumple, el c�digo es muy complejo y no esta dise�ado para ser intrpretado por alguien que no es el desarrollador original. Ademas faltan carpetas para organizar el c�digo.
+- **DRY (Don't Repeat Yourself)**: Nada es aparentemente repetitivo, pero hay mucho c�digo que no se necesita.
+- **YAGNI (You Aren't Gonna Need It)**: Se cumple, no hay funciones aparentes que no se necesiten y la herramienta cumple con los requerimientos funcionales.
+- **SOLID**: El principio de responsabilidad unica no se cumple. Existe una clase dios que tiene demasiadas responsabilidades y las entidades y se puede partir en varias clases complementarias. Ademas no existe la segregacion de interfaces porque casi que no se usan, lo cual genera una acoplaci�n entre los componentes.
+
+## Pracicas de Extreme Programming que podrian ayudar para mejorar la calidad del c�digo
+- **Pair Programming**: Se nota que este es un proyecto desarrollado por una sola persona, el Pair Programming podr�a haber ayudado a detectar errores y mejorar la calidad del c�digo.
+- **Refactorizaci�n**: Este proyecto comenz� con una arquitectura sencilla pero al agregar m�s funcionalidades se qued� corto, la refactorizaci�n podr�a haber ayudado a mejorar la calidad del c�digo cuando se agregaron nuevas funcionalidades.
+- **Metafora**: Este proyecto tiene falta de comunicaci�n y documentaci�n, la met�fora podr�a haber ayudado a que todos los miembros del equipo entiendan el proyecto y se comuniquen mejor.
+ - **Presentacion del codigo**: Presentar el codigo a otros desarrolladores para que den su opinion y detecten errores, no solo la funcionalidad.
+- **Standar de Pruebas**: Las pruebas unitarias no solo no se detectan, sino que la carpeta que las contiene esta desorganizada, un est�ndar de pruebas podr�a haber ayudado a detectar errores y mejorar la calidad y legibilidad del c�digo.
+- **Aceptar el cambio**: El proyecto no se adapta a los cambios, se siguen ignorando las advertencias del IDE y no se adaptan los pipelines de Github Actions para analizar m�s aspectos del c�digo. Ademas esta atorado en una versi�n de .NET Core que ya no recibe soporte lo cual lo hace mucho mas complejo innecesariamente.
+
+## Deuda t�cnica en procesos. Implementaci�n de Integraci�n continua
+- El proyecto original cuenta con un solo workflow que se dedica a correr las pruebas unitarias en los frameworks netcore3.1, .Net 5, .Net 6 y .Net7.
+- No se cuenta con compatibilidad con otras versiones de .NET como la 8.0 que es la ultima versi�n estable ni la 9.0 que esta en desarrollo.
+- Al intentar copiar el workflow en el nuevo proyecto, se detecta que el pipeline no funciona pues sus dependencias estan seriamente desactualizadas. Se intentara volver a correr pero solo en la ultima version de .Net 7. Incluso en este caso, parte de la logica del programa es la genereaci�n de documentaci�n, pero esta est� generando errores de compilaci�n.
+- Despues de a�adir la anotaci�n `<GenerateDocumentationFile>true</GenerateDocumentationFile>` en el archivo .csproj de varios ed los proyectos de la soluci�n, se logra que el pipeline compile correctamente y que las pruebas unitarias corran. Pero 171 que existen, 2 fallan.
+- Se instal� una herramienta de analisis de codigo en el pipeline llamada SuperLint que analizar� todo el nuevo codigo que se suba al repositorio. 
+- El proyecto original cuenta con Dependabot instalado, pero es ignorado. Todas las dependencias desactualizadas se estan dejando sin actualizar bajo desicion del desarrollador. Esto es especialmente malo porque se sabe que la version de Newtonsoft.Json que se esta usando tiene vulnerabilidades criticas conocidas.
+- Se activ� Dependabot en la nueva version para que actualice las dependencias del proyecto, y a diferencia del original, esta vez no se van a ignorar sus advertencias.
+- Se instal� un Github Action llamado Typos Master que ayuda a encontrar errores ortograficos en el codigo. Por ahora solo esta activado en el archivo .github/workflows/buildandtest.yml pues el repositorio original si tenia errores ortograficos en este archivo.
+- El proyecto no cuenta con un pipeline de integraci�n continua que valide la calidad del c�digo, solo se corren las pruebas unitarias.# Refactoring + Code Smells
+## Code Smells
+- Se detect� uso Excesivo de desactivaci�n de advertencias relacionadas con diferentes code smells
+- Las categorias mas desactivadas son:
+	- **Nombramiento de variables**: Se relacionan con la nomenclatura de las variables.
+	- **Inicializaci�n de variables**: Se relacionan con la no inicializaci�n de las variables no nulas.
+	- **Correcto uso de los tipos de datos**: Se relacionan con el uso correcto de los tipos.
+- Se detect� caso omiso deliveradamente a las advertencias del IDE, incluso cuando estas estan marcadas como errores.
+- Se detect� una clase Dios, la cual tiene una cantidad excesiva de m�todos y atributos, alrededor de 350 lineas de c�digo para la clase principal.
+- Falta de buenas pr�cticas.
+- Insuficiente documentaci�n y comentarios en el c�digo.
+- Pruebas unitarias existentes no son detectadas.
+- Desorganizaci�n en el proyecto de pruebas.
+- Se detect� TODOs sin resolver.
+- Hay poco uso de carpetas para organizar y agrupar el c�digo.
+- Hay mucho codigo dedicado a suprimir advertencias del IDE.
+- Los namespaces no corresponden a la estructura de carpetas y la advertencia se suprime.
+- La arquitectura Modelo Vista Controlador solo se aplica en ciertas partes del proyecto.
+- Esta joya: 
+		- //Note: not sure why this is necessary...
+		- RestClient.Net/DefaultGetHttpRequestMessage.cs Linea 69.
+- Clase llamada "Stuff.cs" con ning�n comentario que la explique.
+- Lineas de comentario como:  //Is this good?
+		- RestClient.Net.Abstractions/CallExtensions.cs Linea 66
+
+## Tecnicas de Refactoring Recomendadas
+- **Renombrar variables**: Se recomienda cambiar el nombre de las variables para que sean m�s descriptivas.
+- **Extraer m�todos**: Se recomienda extraer m�todos para que cada m�todo haga una sola cosa.
+- **Eliminar c�digo muerto**: Se recomienda eliminar c�digo que no se utiliza.
+- **Eliminar comentarios innecesarios**: Se recomienda eliminar comentarios que no aportan informaci�n.
+- **Solo implementar codigo que se necesita**: Si no se entiende que hace algo, es mejor no implementarlo.
+- **Sustituir Valores por Referencias**: Se recomienda cambiar los valores primitivos por referencias cuando sea posible.
+- **Cambiar la arquitectura del Proyecto**: Se recomienda refactorizar y cambiar la arquitectura del proyecto para que sea m�s f�cil de entender y mas escalable.
+- **Adaptar el proyecto para que sea Open Source Friendly**: Si se va a dejar de desarrollar el proyecto, se recomienda adaptar el proyecto para que sea m�s f�cil de entender y mantener por otros desarrolladores anonimos.
+- **Adaptar los pipelines**: Los pipelines de Github Actions se pueden mejorar para que analicen mas aspectos del c�digo y despues de creados no deben ser ignorados.
+
+## Caracteristicas de Clean Code que se cumplen y no se cumple
+- **KISS (Keep It Simple, Stupid)**: No se cumple, el c�digo es muy complejo y no esta dise�ado para ser intrpretado por alguien que no es el desarrollador original. Ademas faltan carpetas para organizar el c�digo.
+- **DRY (Don't Repeat Yourself)**: Nada es aparentemente repetitivo, pero hay mucho c�digo que no se necesita.
+- **YAGNI (You Aren't Gonna Need It)**: Se cumple, no hay funciones aparentes que no se necesiten y la herramienta cumple con los requerimientos funcionales.
+- **SOLID**: El principio de responsabilidad unica no se cumple. Existe una clase dios que tiene demasiadas responsabilidades y las entidades y se puede partir en varias clases complementarias. Ademas no existe la segregacion de interfaces porque casi que no se usan, lo cual genera una acoplaci�n entre los componentes.
+
+## Pracicas de Extreme Programming que podrian ayudar para mejorar la calidad del c�digo
+- **Pair Programming**: Se nota que este es un proyecto desarrollado por una sola persona, el Pair Programming podr�a haber ayudado a detectar errores y mejorar la calidad del c�digo.
+- **Refactorizaci�n**: Este proyecto comenz� con una arquitectura sencilla pero al agregar m�s funcionalidades se qued� corto, la refactorizaci�n podr�a haber ayudado a mejorar la calidad del c�digo cuando se agregaron nuevas funcionalidades.
+- **Metafora**: Este proyecto tiene falta de comunicaci�n y documentaci�n, la met�fora podr�a haber ayudado a que todos los miembros del equipo entiendan el proyecto y se comuniquen mejor.
+- **Presentacion del codigo**: Presentar el codigo a otros desarrolladores para que den su opinion y detecten errores, no solo la funcionalidad.
+- **Standar de Pruebas**: Las pruebas unitarias no solo no se detectan, sino que la carpeta que las contiene esta desorganizada, un est�ndar de pruebas podr�a haber ayudado a detectar errores y mejorar la calidad y legibilidad del c�digo.
+- **Aceptar el cambio**: El proyecto no se adapta a los cambios, se siguen ignorando las advertencias del IDE y no se adaptan los pipelines de Github Actions para analizar m�s aspectos del c�digo. Ademas esta atorado en una versi�n de .NET Core que ya no recibe soporte lo cual lo hace mucho mas complejo innecesariamente.
+
+## Deuda t�cnica en procesos. Implementaci�n de Integraci�n continua
+- El proyecto original cuenta con un solo workflow que se dedica a correr las pruebas unitarias en los frameworks netcore3.1, .Net 5, .Net 6 y .Net7.
+- El proyecto no cuenta con un pipeline de integraci�n continua que valide la calidad del c�digo, solo se corren las pruebas unitarias.
+- No se cuenta con compatibilidad con otras versiones de .NET como la 8.0 que es la ultima versi�n estable ni la 9.0 que esta en desarrollo.
+- Al intentar copiar el workflow en el nuevo proyecto, se detecta que el pipeline no funciona pues sus dependencias estan seriamente desactualizadas. Se intentara volver a correr pero solo en la ultima version de .Net 7. Incluso en este caso, parte de la logica del programa es la genereaci�n de documentaci�n, pero esta est� generando errores de compilaci�n.
+ - Despues de a�adir la anotaci�n `<GenerateDocumentationFile>true</GenerateDocumentationFile>` en el archivo .csproj de varios de los proyectos de la soluci�n, se logra que el pipeline compile correctamente y que las pruebas unitarias corran. Pero 171 que existen, 2 fallan.
+- Se instal� una herramienta de analisis de codigo en el pipeline llamada SuperLint que analizar� todo el nuevo codigo que se suba al repositorio. 
+- El proyecto original cuenta con Dependabot instalado, pero es ignorado. Todas las dependencias desactualizadas se estan dejando sin actualizar bajo desicion del desarrollador. Esto es especialmente malo porque se sabe que la version de Newtonsoft.Json que se esta usando tiene vulnerabilidades criticas conocidas.
+- Se activ� Dependabot en la nueva version para que actualice las dependencias del proyecto, y a diferencia del original, esta vez no se van a ignorar sus advertencias.
+- Se instal� un Github Action llamado Typos Master que ayuda a encontrar errores ortograficos en el codigo. Por ahora solo esta activado en el archivo .github/workflows/buildandtest.yml pues el repositorio original si tenia errores ortograficos en este archivo.