Criterios y estructura propuesta para los proyectos

Este documento propone criterios verificables de estructura, nomenclatura y responsabilidades para los proyectos de Java de segundo semestre, Angular de tercer semestre y React Native con Expo de cuarto semestre, de acuerdo con la referencia Estructuras ValleGrande. Los árboles muestran una estructura objetivo; no afirman que el código actual ya la cumpla.

Criterios comunes

La guía de código limpio exige identificadores en inglés en todos los semestres: nombres de clases, métodos, variables, archivos y paquetes. El texto visible al usuario y la explicación del README pueden estar en español. Se debe usar un solo idioma para los identificadores, incluso en el modelo de base de datos.

Cada clase y función debe tener una responsabilidad reconocible. La guía considera ideal una función de hasta 15 líneas y aceptable una de 16 a 30; también pide evitar duplicación, números sin nombre y capturas genéricas de errores. El criterio práctico es que un cambio de interfaz no obligue a modificar consultas SQL y que un cambio de base de datos no obligue a reescribir la vista.

1. Java de segundo semestre

La referencia establece Java 17 o superior, interfaz Swing, MySQL y JDBC. El proyecto actual utiliza JavaFX y conserva los libros en memoria. La migración de la interfaz debe confirmarse con el docente antes de implementarla. Los nombres del árbol toman Book como entidad de ejemplo.

library/
├── .gitignore
├── README.md
├── pom.xml
├── database/
│   └── schema.sql
└── src/
    ├── main/
    │   └── java/
    │       └── pe/edu/vallegrande/library/
    │           ├── Main.java
    │           ├── view/
    │           │   ├── BookCrudView.java
    │           │   └── BookEditView.java
    │           ├── controller/
    │           │   └── BookCrudController.java
    │           ├── service/
    │           │   └── BookService.java
    │           ├── dto/
    │           │   └── BookDto.java
    │           ├── model/
    │           │   └── Book.java
    │           ├── dao/
    │           │   └── BookDAO.java
    │           ├── db/
    │           │   └── AccessDB.java
    │           ├── util/
    │           └── exception/
    └── test/
        └── java/
            └── pe/edu/vallegrande/library/
                └── BookServiceTest.java

Relación entre capas: View → Controller → Service → DAO → AccessDB → MySQL.

• view presenta los datos y recibe las acciones del usuario.
• controller coordina la vista y llama al servicio.
• service valida datos y aplica reglas del sistema.
• dao ejecuta las operaciones de datos mediante JDBC.
• db/AccessDB.java centraliza la conexión con MySQL.
• database/schema.sql define las tablas necesarias.
• test contiene pruebas de la lógica del servicio.

Cambios principales desde el proyecto actual: configurar Java 17 o superior; sustituir el almacenamiento en memoria por JDBC y MySQL; renombrar Libro como Book y LibroDAO como BookDAO; mover el DAO fuera de model; agregar la capa service; hacer que el controlador utilice el servicio; completar el README y las pruebas. Si el docente exige Swing, reemplazar la vista JavaFX. El nombre de proyecto library es provisional porque los documentos de referencia muestran convenciones distintas para el uso de guiones en proyectos Java.

Criterios de revisión para Java

• El proyecto compila con la versión de Java declarada.
• Las clases, métodos, campos, paquetes y tablas tienen nombres descriptivos en inglés.
• La vista no ejecuta SQL ni contiene reglas de negocio.
• El controlador depende de BookService, nunca de BookDAO o AccessDB.
• BookService valida y coordina las operaciones; BookDAO realiza el acceso a datos.
• AccessDB centraliza la conexión; las credenciales se obtienen de configuración local, sin subirlas al repositorio.
• Existen pruebas de las reglas del servicio y un README con instrucciones reproducibles.

2. Angular de tercer semestre

El proyecto angular-feature-based-architecture-main usa Angular 19, una versión válida frente al mínimo Angular 17+ de la guía de tecnologías. Su intención de organizarse por funcionalidades es útil, pero la estructura de tercer semestre espera core/, shared/, modules/ y environments/.

vg-fe-courses/
├── .gitignore
├── README.md
├── angular.json
├── package.json
├── tsconfig.json
└── src/
    ├── index.html
    ├── styles.css
    ├── environments/
    │   ├── environment.ts
    │   └── environment.development.ts
    ├── assets/
    └── app/
        ├── app.component.ts
        ├── app.component.html
        ├── app.module.ts
        ├── app-routing.module.ts
        ├── core/
        │   ├── guards/
        │   ├── interceptors/
        │   └── services/
        ├── shared/
        │   ├── components/
        │   │   └── navbar/
        │   │       ├── navbar.component.ts
        │   │       ├── navbar.component.html
        │   │       └── navbar.component.css
        │   ├── pipes/
        │   └── directives/
        └── modules/
            ├── landing/
            │   ├── pages/
            │   │   └── home/
            │   │       ├── home.component.ts
            │   │       ├── home.component.html
            │   │       └── home.component.css
            │   ├── components/
            │   │   ├── hero/
            │   │   └── benefits/
            │   └── landing-routing.module.ts
            └── courses/
                ├── components/
                │   ├── course-list/
                │   │   ├── course-list.component.ts
                │   │   ├── course-list.component.html
                │   │   └── course-list.component.css
                │   └── course-form/
                ├── services/
                │   └── course.service.ts
                ├── models/
                │   └── course.model.ts
                └── courses-routing.module.ts

Relación entre carpetas: app-routing → module/page → component → service → HttpClient → API. core guarda servicios y mecanismos globales; shared contiene piezas reutilizadas por varios módulos; modules agrupa cada funcionalidad. Una pieza usada solo en landing debe quedar dentro de landing, no en shared.

Hallazgos en el proyecto actual:

• package.json declara Angular 19; la versión cumple el mínimo del estándar.
• features/landing/ y shared/components/ contienen versiones de hero, courses, footer y contact con responsabilidades solapadas. Se debe elegir una sola ubicación para cada componente según su alcance real.
• Hay nombres en español (inicio, cursos, servicios, nosotros, contacto) mezclados con nombres en inglés. La guía exige identificadores en inglés.
• app-routing.module.ts usa LadingComponent, que no está definido, y AppModule no importa AppRoutingModule. Hay que corregir ambas cosas antes de evaluar la navegación.
• core/ contiene principalmente archivos README y no se encontró environments/. Las carpetas deben contener implementación cuando la funcionalidad exista; no conviene crear servicios, guards o interceptors vacíos solo para llenar el árbol.
• El README raíz conserva el texto inicial de Angular CLI y no explica la arquitectura del proyecto.

Criterios de revisión para Angular

• El proyecto usa vg-fe-{nombre} y los nombres de carpetas, clases, selectores y variables son coherentes y están en inglés.
• La aplicación compila y la ruta inicial carga un componente existente.
• AppRoutingModule está conectado a AppModule; las rutas de cada funcionalidad permanecen en su módulo.
• No hay componentes duplicados entre shared y un módulo de funcionalidad.
• Los componentes presentan datos y eventos; las llamadas HTTP viven en servicios mediante HttpClient.
• La URL de la API proviene de environments/, sin estar repetida en componentes.
• Se elige Bootstrap o Tailwind como único sistema de estilos, instalado mediante npm si se utiliza, según el estándar.
• El README explica la estructura, la instalación, la ejecución y las pruebas.

3. Aplicación móvil de cuarto semestre

El proyecto disponible es una aplicación Expo y React Native, por lo que corresponde al estándar móvil de cuarto semestre. La guía usa el prefijo vg-app- y TypeScript. library es solo un nombre de ejemplo; debe reemplazarse por el nombre real del proyecto.

vg-app-library/
├── .gitignore
├── README.md
├── app.json
├── package.json
├── tsconfig.json
├── app/
│   ├── _layout.tsx
│   ├── +not-found.tsx
│   ├── (tabs)/
│   │   ├── _layout.tsx
│   │   ├── index.tsx
│   │   └── settings.tsx
│   └── books/
│       ├── index.tsx
│       └── [id].tsx
├── components/
│   ├── ui/
│   │   ├── Button.tsx
│   │   └── Input.tsx
│   └── books/
│       ├── BookCard.tsx
│       └── BookForm.tsx
├── services/
│   ├── api.ts
│   └── bookService.ts
├── hooks/
│   └── useBooks.ts
├── types/
│   └── book.types.ts
├── constants/
│   └── Colors.ts
└── assets/

Relación entre carpetas: app → components y hooks → services → API; los contratos de datos se guardan en types.

• app contiene únicamente las pantallas y los archivos de navegación de Expo Router.
• components reúne elementos visuales reutilizables y componentes propios de cada función.
• services centraliza las solicitudes HTTP mediante Axios.
• hooks concentra la lógica reutilizable de las pantallas.
• types define los tipos de datos de TypeScript.
• constants guarda valores compartidos, como los colores.

Cambios principales desde el proyecto actual: conservar una sola carpeta app/ y retirar la duplicación con src/app/; reunir los componentes y utilidades en una ubicación coherente; actualizar los imports; usar el prefijo vg-app-; completar el README. La guía incluye Axios, NativeWind y React Hook Form. Su incorporación debe hacerse con versiones compatibles con el SDK de Expo instalado. El proyecto ya tiene Expo Router, AsyncStorage y strict: true.

Criterios de revisión para Expo

• Solo hay una carpeta de rutas de Expo Router y cada archivo de ruta representa una pantalla.
• Las pantallas coordinan componentes y hooks; no contienen solicitudes HTTP ni lógica de almacenamiento repetida.
• bookService.ts concentra las llamadas a la API y api.ts configura el cliente Axios.
• Los componentes visuales no conocen las URL de la API.
• Los tipos de datos están definidos en types/ y TypeScript conserva strict: true.
• Archivos, componentes, funciones, rutas y variables usan nombres descriptivos en inglés.
• Los formularios tienen validación y los estados de carga y error son visibles para el usuario.
• El README explica cómo instalar, configurar y ejecutar la aplicación.

Referencias

• Tecnologías por semestre
• Estructuras de proyecto
• Código limpio
• Patrones de arquitectura