Como afrontar un proyecto de software

Archivado
Por poneros un poco en antecedentes: En su día realicé estudios de desarrollo de aplicaciones informáticas, y justo me incorporé al mercado laboral cuando empezaba la peor época de la crisis. Fui trabajando en empresas ruinosas medio muertas que vivían a base de subvenciones que ya no existían, con uno o dos trabajadores, a veces sin contraro, a veces sin cobrar... Con el resultado de que sólo gané malas experiencias y ningún conocimiento.

Después por motivos personales me tuve que aferrar a un trabajo que nada tenía que ver con la programación y después de dos años me surgió la oportunidad de volver a la informática y aquí estoy de nuevo.


Llevo unos años trabajando en una empresa manteniendo aplicaciones bastante antiguas: muchísimos programas independientes, código repetido por todas partes y en cada programa con unas validaciones distintas, algunos programas hay que actualizarlos a mano en cada equipo...

La cosa es que llevo mucho tiempo pensando en hacerlo todo de cero, con una buena arquitectura, reutilizando el código... pero es que no sé por dónde empezar. No tengo experiencia en empresas grandes y no sé qué arquitectura utilizar ni como plantearme algo así, ya que son muchos programas.

Trabajamos con .NET y aplicaciones de escritorio. Entiendo que lo más fácil sería pasarlo todo a Web en un sólo proyecto con distitnas áreas para cada cosa, pero no soy el único trabajador de la empresa y veo muy complicado que el resto acepte trabajar en Web.

Querría empezar a trabajar con POO, pero no entiendo de qué manera puedo reutilizar esas clases si tengo varios proyectos distintos donde enlazarlas. Cada vez que se cambiase algo habría que actualizar el resto de proyectos, y después aplicar esos cambios en los equipos.

También pensé en hacer los proyectos en tres capas, pero entonces reutilizar el código me parece una locura porque por cada clase tienes tres partes, una en cada capa, y tendrías que enlazarlas todas a cada proyecto...


No sé como plantearlo y me frustra muchísimo. Intento aprender pero sin un entorno real en el que ver como se aplican las cosas al final me quedo como estoy, sabiendo que existe tal o cual arquitectura o patrón, pero sin saber como ni dónde aplicarlo, y no consigo avanzar.

A veces he pensado en buscar otro trabajo, pero la verdad es que no me veo a la altura de un trabajo de programador. No tengo nada de experiencia en entornos de trabajo grandes basados en tecnologías actuales, así que no me atrevo a dar el salto.


¿Podríais orientarme un poco?
Deberías ponerte al día para empezar, si trabajas con .NET a chapar un poco de NET 6, que hay mucho cambio, y a estudiar arquitecturas. Haz cursos o tira de documentación y libros, haz pruebas de concepto y cuando ya lo tengas claro puedes ir empezando el proyecto poco a poco.
DevilKeeper escribió:Por poneros un poco en antecedentes: En su día realicé estudios de desarrollo de aplicaciones informáticas, y justo me incorporé al mercado laboral cuando empezaba la peor época de la crisis. Fui trabajando en empresas ruinosas medio muertas que vivían a base de subvenciones que ya no existían, con uno o dos trabajadores, a veces sin contraro, a veces sin cobrar... Con el resultado de que sólo gané malas experiencias y ningún conocimiento.

Después por motivos personales me tuve que aferrar a un trabajo que nada tenía que ver con la programación y después de dos años me surgió la oportunidad de volver a la informática y aquí estoy de nuevo.


Llevo unos años trabajando en una empresa manteniendo aplicaciones bastante antiguas: muchísimos programas independientes, código repetido por todas partes y en cada programa con unas validaciones distintas, algunos programas hay que actualizarlos a mano en cada equipo...

La cosa es que llevo mucho tiempo pensando en hacerlo todo de cero, con una buena arquitectura, reutilizando el código... pero es que no sé por dónde empezar. No tengo experiencia en empresas grandes y no sé qué arquitectura utilizar ni como plantearme algo así, ya que son muchos programas.

Trabajamos con .NET y aplicaciones de escritorio. Entiendo que lo más fácil sería pasarlo todo a Web en un sólo proyecto con distitnas áreas para cada cosa, pero no soy el único trabajador de la empresa y veo muy complicado que el resto acepte trabajar en Web.

Querría empezar a trabajar con POO, pero no entiendo de qué manera puedo reutilizar esas clases si tengo varios proyectos distintos donde enlazarlas. Cada vez que se cambiase algo habría que actualizar el resto de proyectos, y después aplicar esos cambios en los equipos.

También pensé en hacer los proyectos en tres capas, pero entonces reutilizar el código me parece una locura porque por cada clase tienes tres partes, una en cada capa, y tendrías que enlazarlas todas a cada proyecto...


No sé como plantearlo y me frustra muchísimo. Intento aprender pero sin un entorno real en el que ver como se aplican las cosas al final me quedo como estoy, sabiendo que existe tal o cual arquitectura o patrón, pero sin saber como ni dónde aplicarlo, y no consigo avanzar.

A veces he pensado en buscar otro trabajo, pero la verdad es que no me veo a la altura de un trabajo de programador. No tengo nada de experiencia en entornos de trabajo grandes basados en tecnologías actuales, así que no me atrevo a dar el salto.


¿Podríais orientarme un poco?



No todo tiene por qué ser web, aunque sí que es verdad que es la tendencia. Dicho esto, muchos proyectos serían impensables en web (imagina AutoCAD o similares en web, sería un infierno), pero precisamente los que son de gestión son los candidatos perfectos en casi todos los casos.

El problema principal es que cualquier reestructuración de código va a ser un tragadero de horas si el proyecto es notablemente grande en su conjunto. Lo que mencionas de ir actualizando en todos los equipos es algo que debería estar penado con guillotina XD

Dicho esto, y sin saber cómo es la estructura del proyecto, si tira de una o varias bases de datos, etc. lo que yo suelo hacer cuando me tocan estas mierdas de pasar una aplicación a web, es crear un nuevo proyecto web con la versión que te guste, instalar Entity Framework + POCO Generator y cargar cada tabla en un modelo de datos de C#. Luego hago la funcionalidad CRUD muy simple, y me creo unos ViewModels que serán los que vayan directamente a las vistas (o que sirvan únicamente como respuesta en Json para otros microservicios).

Te recomiendo encarecidamente que te mires esta documentación, es bastante directa y te lo pone muy fácil:
https://docs.microsoft.com/en-us/aspnet ... roduction/

Obviamente es un ejemplo muy básico, pero te sirve para entender mejor cómo organizar el código.

Migrar código es muchas veces una tarea titánica que lleva muchísimo tiempo, y para cuando has terminado ya hay 2 versiones más modernas funcionando. No desesperes, las empresas rara vez adoptan algo que sea novedoso, así que SIEMPRE vas a estar a la zaga, salvo que el proyecto lo hagas por ti mismo.
Mi recomendacion es que aprendas sobre patrones de diseño: https://refactoring.guru/es/design-patterns aqui tienes una pagina bastante buena. Eso te ayudara a entender muchisimo y sobretodo amoldar tu cabeza de tal forma que apliques buenas practicas de arquitectura de software.

Aqui tienes el libro en C# que imagino es lo que utilizaras si es que hablas de .NET: https://www.amazon.es/PATRONES-DISE%C2% ... 2746072602 lo podras encontrar gratuito en varias fuentes, pero por razones obvias no te lo puedo ofrecer.

Segundo a eso, actualiza conocimiento en el framework .NET y afianza tu programacion en C# con varios cursos o libros. Es cuestion de echarle tiempo y poco a poco veras la luz al final del tunel creeme.

Te recomendaria cursos de .NET y C# pero yo trabajo con otros lenguajes asi que prefiero no hacerlo antes que recomendarte cualquier castaña.

Un saludo compi, y animo.
@DevilKeeper Creo que como desarrollador de aplicaciones es bastante raro que al trabajar obtengas la experiencia para afontar un proyecto grande. Lo normal cuando una empresa necesita cubrir esa labor es que contrate a un ingeniero, analista o qué sé yo, y que que el desarrollador sea eso, un picateclas.
Para hacer lo que quieres vas a tener que estudiar mucho, y por supuesto no presentes nada sin tener ya un plan completo aún sabiendo que quizás lo cojan y vaya a la basura de cabeza por bueno que sea, y sí, tus compañeros te odiarán porque aunque a largo plazo podría ser mejor tu proyecto, a corto plazo implicará más trabajo.
No tiene nada que ver empresa grande o pequeña. La programación es un acto muy individual porque es todo mental. Y mentes cada una tiene la suya, por lo que hay tantas soluciones como mentes.

Estaría bien que leyeras sobre patrones para tener ciertas ideas, aunque yo no soy partidario del fanatismo que algunos tienen con ciertos patrones. Además, muchos de esos patrones son sentido común que aprendes con la experiencia y otros implican una sobre ingeniería estúpida, muy de moda últimamente, que lo único que hace es complicar las cosas.

El código, cuanto más sencillo, mejor, porque tienes que diseñar las cosas pensando en su mantenimiento y no en lo “bonito” que es. Programa para otros, de manera que cuando otra persona siga tu código lo entienda perfectamente.

Dices que trabajas en .NET pero que quieres hacer POO. Esto me indica que no tienes claros los conceptos básicos.

Si no tienes claro si será web o escritorio empieza creando tus capas de acceso a datos, validaciones, etc. de manera que lo puedas utilizar tanto en web como escritorio. Luego, integra este código como un proyecto aparte dentro de tu solución, ya sea web o escritorio.

Lee un poco y experimenta con el código. Tu solo irás llegando a soluciones cada vez mejores si te lo propones. Por mucho que leas, no tendrás la madurez suficiente como para llegar a buenas soluciones desde el principio.

Programa, programa y programa.

Yo llevo varias décadas en esto y aún me sorprendo a mi mismo al leer mi propio código de hace unos meses y darte cuenta que lo podrías haber hecho mejor.
Sinceramente tu solo afrontar este proyecto mientras trabajas, por decisión propia te va a traer más dolores de cabeza que otra cosa.

Primero tendrías que hacer consultoria, ver que hay, que se necesita ya que lo vas a reimplementar.
Luego decidir la mejor tecnología y programarlo.

Personalmente yo no tocaría gran cosa porque ya sabes lo que pasa que las cosas dejan de funcionar, fallos, quejas... y nadie te lo va a agradecer.
@DevilKeeper

Si no te van a pagar específicamente para que hagas una refactorización de ese calibre, yo no lo haría.

Si te lo han pedido, ya es otro tema.

Por lo que dices, necesitas utilizar una arquitectura DDD y microservicios, utilizando patrón CQRS.

Yo lo que haría, si tienes que repetir o compartir mucha lógica de aplicación, en encapsular en microservicios cada cosa que se repita más de 2 veces y se idéntico.

Por ejemplo nosotros tenemos el servicio de mails como algo común, no? Pues lo que hacemos es enviar un evento al microservicio de mail, con los parámetros que se requieren y el microservicio se encarga de esa parte.

Podrías hacer lo mismo para las entidades que quieras y no solo enviando eventos, si no peticiones directas como si de una API se tratara.

Web lo puedes hacer con .Net, con Python o con lo que quieras, pero para poder reutilizar código y tener 1 única entidad usuario unificada, necesitas un modo de comunicar una aplicación con otra. Lo más sencillo es una API, en el idioma que sea.

Puedes implementar servicios WCF en .NET para que la aplicación pueda recibir peticiones si prefieres no montar una API de 0.

Hay varias soluciones, pero yo lo que montaría, son microservicios y APIs. Más que nada para que todo sea modular y si en algún momento .NET se queda obsoleto (no creo que pase, se actualizarán versiones) puedes sustituir el servicio que quieras, por otro con el lenguaje que quieras, porque la forma de comunicarse, es con JSON.

Esto es super escalable, porque te permite utilizar servicios con diferentes lenguajes y por ejemplo para servicios con cálculos complejos que con un aprendizaje automático en Python, puede ser más eficiente que en .NET.

Contra más modular sea una aplicación, el mantenimiento también es más simple y requiere menos trabajo, porque puedes mantener la compatibilidad de las versiones de una forma simple, todo encapsulado en su microservicio.
Gracias por las respuestas.

Las aplicaciones que tenemos son de escritorio, y son muchísimas. Prácticamente todas con las mismas funcionalidades, o con los mismos modelos al menos, y consultas muy parecidas. Al final todas gestionan muchas de las mismas entidades para obtener datos y luego ya realizar funcionalidades más específicas.

Yo quiero aprender, pero al tener que hacerlo todo de forma autodidacta, y al ser casi el único de la empresa con interés en modernizarnos, pues lo que consigo es frustrarme porque ni sé como empezar ni puedo apoyarme en nadie para irme guiando.

@xDarkPeTruSx Gracias por tu respuesta tan concreta. He seguido mirando estos días y había llegado a la conclusión de que lo mejor eran los microservicios, pero lo veo inviable. La empresa en la que trabajo es pequeña y está muy envejecida en cuanto a conocimientos. Meter algo web seguramente no fuese bien recibido.

Además en mi jornada laboral tengo que atender las incidencias de los clientes además de programar, e implantar algo así sin experiencia me llevaría demasiado tiempo.

Estaba pensando en desarrollar una especie de DLL que poder compartir en todos los proyectos, para tener ahí al menos las cosas mas utilizadas. El problema es mantener luego esa DLL actualizada en todos los equipos. También he estado mirando si había alguna opción de compartir las capas BAL, DAL y entidades entre varios proyectos y soluciones, en lugar de tener que generar una DLL.

Era lo más sencillo e inmediato que se me ocurria.

Si no la otra opción es seguir haciendo todo como hace 25 años e intentar formarme por mi cuenta y buscar otro trabajo.
DevilKeeper escribió:Si no la otra opción es seguir haciendo todo como hace 25 años e intentar formarme por mi cuenta y buscar otro trabajo.


Esa es la mejor opción...


Ya te digo, si son muchas apps de escritorio y las apps son monosistema, no vas a poder comunicarlo. Tienes que tener Backend en un servidor común.

Tanto para API y microservicios como para usar un WCF, necesitas que las apps estén ejecutándoselo en un servidor.

Lo que si puedes hacer, en vez de una DLL es crear dependencias, como un paquete externo que se inyecte en todos los proyectos, de forma que queda compilado y no dependes de los DLL, solo de actualizar el versionado, pero claro. Cuando toques algo de esa DLL interna, todos tendrán que actualizar la versión. No sé como lo tenéis montando en cuando a sistema de updates para desplegar nuevas versiones. Si está automatizado sería sencillo usar esta opción.

Pero si el proceso de actualización es manual.... olvídate, no hay solución mantenible.


Ya digo, cualquier refactorización de algo ya existente a un nuevo lenguaje o una nueva arquitectura es un dolor de huevos.

Nosotros estamos refactorizando todo a microservicios y llevamos 9 meses..... Aún nos queda como 1 o 2 años más para tenerlo todo actualizado, porque los desarrollos nuevos no paran y apenas tenemos tiempo para el mantenimiento. La rueda no para de girar y meterle mano mientras tanto, es difícil y costoso.

PD: Somos 50 developers.
9 respuestas
Archivado
Volver a El rincón del eoliano