Diario de Prácticas (II)

Las prácticas están a punto de llegar a su fin. En este punto, el trabajo de codificación de la versión básica del servidor API backend está prácticamente terminado. Es un buen momento para hacer un resumen.

Como líder del grupo del proyecto, mi único conocimiento sobre gestión de proyectos de software proviene de haber leído The Mythical Man-Month durante las vacaciones de invierno. Después de esta experiencia práctica, me doy cuenta de que aún soy muy inexperto. Sin embargo, creo que he aprendido algunas cosas.

Diseño

Comparado con hace dos años, cuando empezaba a escribir los ejercicios de C en VS sin pensarlo dos veces, hoy en día he cambiado bastante.

~~En primer lugar, hace mucho que no abro VS.~~

En resumen, durante estos dos años he pasado por varias etapas de codificación intensiva: la etapa de aprendizaje puro e inocente de Python, la experiencia de desarrollar la aplicación de control para el robot en el equipo de robótica, la experiencia de escribir el scraper para el sitio web de la oficina académica (tanto para profesores como para estudiantes), y la participación en el proyecto “Orange Juice” donde escribí una herramienta de gestión de archivos. Al principio, por supuesto, me lancé sin pensar, pero supongo que después de sufrir las consecuencias de las contradicciones e inconsistencias suficientes veces, uno aprende la importancia de diseñar con antelación. Una vez que entras en el mundo del diseño, la cuestión pasa a ser el grado de profundidad; por lo tanto, esta experiencia de dirigir todo el proyecto ha sido un ejercicio muy beneficioso.

Primero, definir claramente qué se quiere hacer. Esta pregunta es crucial para un equipo que realmente quiere crear un producto: definir su propio producto es una cuestión a nivel estratégico. Lamentablemente, esta vez no teníamos una idea particularmente interesante. Con la responsabilidad sobre mis hombros, mi expectativa para estas prácticas era hacer un proyecto sólido y sencillo.

En resumen, se trata de una aplicación web tradicional con las características de un Mini Programa de WeChat como principal atractivo — concretamente, un sistema de gestión de objetivos.

Hay mucha gente que hace esto, por lo que es fácil encontrar modelos maduros para el dominio del problema: herramientas como Worktile, orientada a proyectos; WonderList, orientada a la gestión personal de la vida; My Study Life, orientada a estudiantes; e incluso la app Recordatorios de Apple y otras herramientas que he oído nombrar pero no he usado. Sintetizando las características de estas herramientas, resumimos un clásico sistema de gestión de objetivos con el sello distintivo de WeChat — así nació nuestro Seed.

Características que debería tener

Entonces, ¿qué debería poder hacer Seed?

Tener un sistema de usuarios simple, para facilitar la sincronización y aumentar la fidelidad del usuario.
Los usuarios pueden crear y gestionar libremente objetivos, similares a los proyectos de Worktile.
Los usuarios pueden ser invitados a los objetivos de otros.
Los objetivos se dividen en tipo “check-in diario” (recurrente) y tipo “proyecto/objetivo específico” (único, puede incluir hitos).
El frontend principal son los Mini Programas de WeChat.
También es compatible con otros clientes potenciales.

Visto así, Seed debería ser un servicio práctico, pequeño y minimalista, algo que encaja perfectamente con el propósito original de los Mini Programas de WeChat.

Es necesario enfatizar aquí la característica de ser “pequeño y minimalista”. ¿Por qué pequeño y simple? Primero, porque no tenemos suficiente personal ni tiempo. Segundo, para evitar el error común de los segundos proyectos mencionado en The Mythical Man-Month: la arrogancia ciega que lleva a añadir infinitas características redundantes a un proyecto. Es un esfuerzo inútil y contraproducente, especialmente — ya que no involucramos ingresos por publicidad. Un ejemplo simple: la versión de Mac OS de Xunlei y la versión de Windows; obviamente, a todos les gusta más la versión minimalista y usable de Mac.

También debe tener una buena compatibilidad con los Mini Programas de WeChat. Para ofrecer una transición fluida al usuario, debería admitir tanto el email como nombre de usuario para iniciar sesión, como el openId de WeChat como credencial de acceso.

Estructura del sistema

Como se mencionó antes, queremos hacer una aplicación web con los Mini Programas de WeChat como principal atractivo, lo que significa que Seed tiene la capacidad ~~y la ambición~~ de ser compatible con otros frontends. Por lo tanto, una API con estilo RESTful se convierte en la mejor opción: desacoplamiento total entre frontend y backend, estructura clara y fácil de consumir.

Por lo tanto, Seed debería consistir en un frontend formado por Mini Programas de WeChat y otras formas potenciales, que consuman los recursos proporcionados por el backend a través del protocolo HTTP.

El backend proporciona servicios seguros y fiables a través de la API.

Para ello también he aprendido algunas cosas, y me he encontrado con la idea de HATEOAS (Hypermedia As The Engine Of Application State). Aunque aún no está madura, representa un posible futuro.

Implementación

Dado que solo participé en la codificación del servidor API, aquí solo hablaré de la implementación del backend.

Me gusta clasificar el diseño en el nivel estratégico (el “Tao”), y el resto del trabajo en el nivel táctico (la “Técnica”). Por lo tanto, la elección de tecnologías y cómo implementar concretamente un sistema entrarían aquí.

Tecnología

Debido a los requisitos de las prácticas, y también por el deseo de usar el lenguaje Java de manera adecuada, elegimos Spring Framework como framework backend, aprovechando también el ecosistema Spring:

Spring Boot como contenedor de la aplicación.
Spring Framework para implementar la lógica de negocio.
Spring Data como DAO.
Spring Session para gestionar las sesiones.
Spring Test para pruebas.

Además, utilizamos herramientas como Git, TravisCI y Heroku para mejorar la experiencia de desarrollo.

Proceso de desarrollo

Como mencioné antes, la experiencia de escribir controladores en Spring es muy similar a la del framework web Flask de Python. ¿Quizás Flask tomó alguna inspiración de Spring? Creo que las clases controladoras orientadas a recursos son mucho más compactas que la forma tradicional de Java Web de escribir un Servlet para cada recurso.

Spring promueve el desarrollo guiado por pruebas (TDD), pero llevarlo a la práctica no es fácil, ya que escribir pruebas no suele ser una tarea popular. Asignar a una persona específica para escribir código de pruebas tiene un alto costo de aprendizaje y también plantea algunos problemas interpersonales. Por lo tanto, durante el desarrollo decidí que cada persona fuera responsable de probar su propio código. Finalmente, yo revisaría el código.

Resumen

Ya he hablado de los aspectos más destacables de Seed en sí. Ahora hablemos de otras cosas.

Resumen personal

He aprendido mucho durante las prácticas, pero aún hay problemas.

Como gestor de proyecto, soy bastante inexperto. El control del progreso, la asignación de personal y la atención a otros detalles tienen muchas deficiencias.

Por ejemplo:

Mi falta de conocimiento sobre tecnologías frontend hace que probablemente solo el servidor API sea funcional al final del proyecto.
Solo la mitad de las personas en el grupo del proyecto participaron realmente.
La formación para quienes participaron en el trabajo fue vaga y careció de paciencia.

Obviamente, todavía necesito seguir formándome. Pero el hecho de actuar tanto como gestor de proyecto como desarrollador me llevó a reflexionar sobre otro tema.

Discusión sobre las dos capacidades de un Ingeniero de Software

La capacidad de arquitectura y control global de un sistema y la capacidad de elegir, adaptar y utilizar algoritmos para implementar una funcionalidad concreta.

La educación en las aulas de nuestra facultad de ingeniería de software parece centrarse solo en lo segundo. Esto no es extraño, ya que el dominio de los algoritmos es fácil de medir; se podría decir que las diferencias en habilidad son evidentes, como resolver problemas matemáticos: bajo condiciones y restricciones estrictas, la creatividad de las personas es muy fácil de evaluar. Sin embargo, la capacidad de establecer racionalmente esas “condiciones y restricciones estrictas”, aunque es importante, es difícil de medir.

En cuanto a por qué digo que es contradictorio, pongamos un ejemplo simple y comprensible, aunque quizás no del todo apropiado: todo el mundo sabe que es ingenuo e irreal que los padres prohíban a sus hijos tener relaciones tempranas con la excusa de que afectan a los estudios, pero esperen que formen una familia inmediatamente después de graduarse. Esperar implícitamente que los estudiantes, solo con buenas calificaciones, se conviertan en personas completas y versátiles después de graduarse es también una idea ligeramente distorsionada. La diferencia entre estos dos casos es que la contradicción en el segundo no es tan aguda como en el primero.

Creo que este tipo de prácticas son efectivamente una compensación por las deficiencias de la educación en el aula, y representan una oportunidad para evitar la contradicción entre el rendimiento académico como medio de formación y la capacidad como objetivo de formación, que estos dos símbolos representan.

/Diario/ /Prácticas/ /Reflexiones/