Reutilización de código, mantenimiento de aplicaciones (I)
Introducción
No me voy a andar con grandes tecnicismos, más bien todo lo contrario.
Voy a ir directo al asunto y de forma concisa, planteando los problemas habituales con los que podemos encontrarnos los desarrolladores y cómo hacerlos frente.
Como avanzar y mejorar nuestro código basándonos en un proyecto teórico inicial y como ir salvando los diferentes obstáculos con los que podemos encontrarnos.
¿Seremos capaces?… ¡veámoslo!.
Punto de partida
Partiremos de un ejemplo muy sencillo de entender.
Empieza el proyecto de desarrollo y nos dicen que preparemos una aplicación que lea como entrada el contenido de un fichero de texto, y como salida, que escriba también en un fichero de texto.
Vamos a obviar de momento el proceso intermedio.
Sería algo similar a lo que se indica en la siguiente imagen:
Como podemos apreciar… algo muy sencillito de realizar.
Implementación de partida
Ante esto, la idea parece muy clara y evidente.
Vamos a crear un proyecto de aplicación Windows y sobre él vamos a llevar a cabo nuestro desarrollo.
Dentro del formulario Windows hemos insertado un control Button.
Todo muy sencillo.
El código quedaría de la siguiente manera:
1: namespace UI_Sample
2: {
3:
4: using System;
5: using System.Collections.Generic;
6: using System.ComponentModel;
7: using System.Drawing;
8: using System.Windows.Forms;
9:
10: public partial class MainForm : Form
11: {
12:
13: public MainForm()
14: {
15: InitializeComponent();
16: } // MainForm Constructor
17:
18: private void btnSampleTest_Click(object sender, EventArgs e)
19: {
20: string data = Read();
21: // Hacemos algo con el texto leído.
22: // ...
23: // Escribimos el resultado del supuesto proceso anterior.
24: Write();
25: // Mostramos un mensaje en pantalla tipo fake.
26: MessageBox.Show(
27: data +
28: Environment.NewLine +
29: "Lectura y escritura realizada.");
30: } // btnSampleTest_Click
31:
32: private string Read()
33: {
34: // Abrimos el fichero y leemos su contenido.
35: return "Texto leido";
36: } // Read
37:
38: private void Write()
39: {
40: // Escribimos el fichero en su lugar destino.
41: } // Write
42:
43: } // MainForm
44:
45: } // UI_Sample
Posibles problemas
La solución anterior no está mal, sin embargo, puede presentarnos a futuro una serie de problemas que dependiendo de la complejidad del proyecto y otras circunstancias como por ejemplo si el código de nuestra aplicación cambia frecuentemente, etc., puede acarrearnos serios contratiempos.
Por otro lado, el principal problema que aporta el ejemplo anterior, sería el mantenimiento de la solución propuesta.
Mezclar lógica e interfaz de usuario debería ponernos los pelos como escarpias de antemano.
En otro orden de cosas, separar la lógica en una biblioteca de clases para apartarla de la interfaz de usuario, podría resolver parte de este problema, pero se nos presentación otro adicional.
¿Qué ocurriría si en lugar de querer leer desde un fichero de texto y escribir en un fichero de texto queremos cambiar ese fichero de texto por una hoja Excel?.
Esto es lo que resolveremos en la siguiente parte del artículo siguiendo con la inercia de desarrollo marcada aquí.
8 Responsesso far
Jorge, es un tema interesante, puede dar para varios artículos.
En relación a la reutilización y también a la compartición de código, del blog de Javier Suárez:
http://javiersuarezruiz.wordpress.com/2013/04/04/windows-phone-tecnicas-para-compartir-codigo-2o-parte/
Saludos.
De momento, y con los requisitos que tienes, parece una solución magnífica (solo superada por «copy entrada.txt salida.txt»).
YAGNI! 🙂
Tengo ganas de ver cómo evoluciona esta serie.
@Kiquenet, no conocía las entradas de Javier Suárez. Las echaré un vistazo. ¡Gracias por compartir!. 🙂
@Juanma, jajajaja me ha hecho mucha gracia lo de «solo superada por copy entrada.txt salida.txt. ¡Que grande!. :)))
Hay varias entradas más en la bandeja de salida.
Irán apareciendo por a poco.
A ver si me da tiempo a sacar todo lo que tengo en mente
Sobre todo a ver si no estoy espeso, lo explico bien, se entiende bien, y resulta interesante.
¡Muchas gracias por comentar!
@Jorge, me gustaría hacer una reflexión haciendo un poco de abogado del diablo, partiendo de la base de que entiendo que siempre es bueno seguir los principios SOLID, aplicar patrones de diseño, utilizar separación de capas, etc, etc. Pero creo que es también necesario reflexionar sobre el principio Kiss, el programa que pones de ejemplo cumple con los requerimientos que se proponen y entiendo que puede ser una aplicación perfectamente válida, creo que muchas veces somos los desarrolladores los que complicamos las aplicaciones, programas que utilizan WCF sin necesidad pensando en que un día van a ser extensibles y que cuando llega el momento quizás ni siquiera se utilice esta tecnología, aplicación de arquitecturas DDD para programas que solo funcionan en una plataforma, desacoplamiento y otras lindezas que frente a todo hacen que muchas veces las aplicaciones solo sean legibles por auténticos expertos o gente que haya participado en los proyectos desde el inicio, creo que los programadores tendemos a escribir auténticas aberraciones con tal de que nuestra aplicación sea perfecta y al final solo hacemos que complicarlas y entiendo que debemos reflexionar en este punto, creo que muchas veces deberíamos centrarnos en buscar una solución rápida y funcional antes de complicarla sin necesidad. Cuantas veces escribimos código sin necesidad, complicando nuestras aplicaciones, todas las aplicaciones tienen dependencias es imposible eliminarlas todas, en algunos casos como en aplicaciones Web mezclamos un montón de tecnologías, XML, Html, JavaScript, Jquery, Servicios Web, etc, etc, no hay más que ver que la programación tiende a ser cada vez más compleja y difícil y creo que esto es porque los programadores somos los que complicamos los desarrollos pensando en dar solución a muchos problemas sin necesidad. ¿Por qué hacer algo que no necesitamos?. Creo que muchas es mejor centrarse en dar una solución simple y eficaz y pensar menos en el futuro de nuestras aplicaciones, porque muchas veces este no llega o cuando llega la tecnología a utilizar es completamente nueva y rompe con todos nuestros principios haciendo de esta una aplicación menos legible y mantenible.
Un saludo.
@Juan jajajaja ¡¡¡acabas de matarme el resto de entradas que ya están preparadas y terminadas para salir sólo cuando llegue el momento!!! 🙂
Aquí aplica también aquella máxima de que no existen balas de plata.
Ni todo tiene porqué ser blanco ni todo tiene porqué ser negro.
Aquí comienza una serie de entradas de tipo reflexión y «mundo ideal», pero que todos sabemos que no tiene porqué ser así. De hecho, estas conclusiones también las trato en otra entrada de la serie.
Hay unas cuantas preparadas que saldrán en los próximos días… pero no te quito la razón en lo que dices porque la tienes, como también sabes que la pueden tener quienes consideren desarrollar siguiendo todos los patrones y principios de diseño existentes.
Siempre digo lo mismo,… cada proyecto informático es único, y lo que para unos es la solución ideal, para otros puede ser el fracaso del proyecto. 🙂
Coincido con Juan y Jorge.
Ni blanco ni negro, ni complicar las aplicaciones, hacerlos lo más simples posible, y mantenibles a lo largo del tiempo. Lo cual no es fácil.
Seguro que las futuras entregas de Jorge nos aportarán luz y reflexión.
Saludos.
upsss, lo siento, borra mi comentario, olvídalo todo…
@Juan no pienso borrarlo.
Estas entradas están escritas para que sirvan de reflexión, y tú por tu experiencia has llegado a conclusiones muy acertadas porque ya ves por donde voy.
Todas las ideas, propuestas, comentarios, etc., son bienvenidos vengan en la parte I de este conjunto de entradas o en la VI como verás la semana que viene. 😉