Cita: Originalmente Escrito por
manolazo
soy un poco desastre ya que programo de forma un poco desordenada , empiezo con algo sencillo y poco codigo al que voy añadiendo mas funciones y mas clases a medida que voy agrandando el proyecto y al final se convierte en algo que es dificil de mantener y actualizar. La verdad que cuando hay tanto codigo no se como organizarlo.
¿Acaso se puede empezar de otra forma? Empezar con algo sencillo e ir ampliando es lo habitual salvo que tengas un proyecto con una especificación cerrada o todas tus apps tengan el mismo molde. En apps que van refinándose conforme a lo que piden los usuarios, comentarios, ideas nuevas e incluso lo que tú mismo vas aprendiendo con la experiencia, no queda otra.
Da igual el nivel que tengas, en cuanto pase un tiempo el código anterior te hará daño a la vista y además pensarás "esto ahora lo haría de otra forma". A veces porque la propia tecnología cambia y favorece ciertas prácticas, otras simplemente porque nos falta una bola de cristal que te diga cómo va a evolucionar el proyecto.
Y al final, si la app evoluciona mucho, que se convierta en algo difícil de mantener es inevitable. A mí me pasa con el cuatro en raya que lleva cinco años ya... creo que las únicas líneas que se mantienen de siempre son unas pocas líneas muy feas de la inteligencia artificial que funcionan muy bien y "mejor no tocar". El resto, reescrito más de una vez.
Curiosamente hace poco reescribí el online aplicando el modelo MVP sin saber su nombre
Quería separar completamente el comportamiento online de la gestión de sockets y del apartado gráfico en previsión de dejar de usar custom views y pasarme a un motor de juegos tipo libgdx y algún día quitar los sockets y usar websockets. Como también estoy preparando la versión de iOS, si la lógica es independiente de la parte gráfica y de la conexión puedo tener un código que a grandes rasgos sea el mismo en Java y en Swift (cambiando la sintaxis, pero el "pseudocódigo" sería el mismo). La parte específica de cada sistema estará en su clase independiente, más fácil de probar también y de intercambiar (hoy uso una biblioteca de conectividad, mañana otra y al resto de la app no le importa porque la interfaz se mantiene).
Es más código y más interfaces, pero es un caso claro donde merece la pena desacoplar.