Conozco muy bien esta situación. Cuando me quedo atrapado de esa manera, trato de tomar diferentes puntos de vista sobre el proyecto.
1.) Punto de vista del usuario / cliente: utilizar comentarios
Desafortunadamente, estamos atrapados en nuestro código de una manera que no podemos ver nuestros propios defectos porque usamos nuestras aplicaciones de la manera que las hemos codificado.
Observe cómo lo usa la gente y trate de averiguar cuál sería la guía de usuario más intuitiva.
Juega un poco con prototipos de interfaz de usuario.
Esto parece ser divertido, pero si descubre que se vería obligado a recodificar grandes partes de su código simplemente cambiando la lógica de uso, es hora de comenzar un ciclo de rediseño.
2.) Haga un análisis funcional de su código y visualícelo
Algunos IDE y marcos te empujan a, por ejemplo, mezcla de interfaz de usuario y código de backend. Si deja que esto suceda, algún día enfrentará la situación de que su base de código difícilmente se puede mantener debido a las dependencias nebulosas y difíciles de romper. Especialmente mezclar código UI con otro código puede llevar a código spaghetti y funcionalidad redundante.
Divide tu código en bloques funcionales como, por ejemplo, clases de base de datos, clases de comunicación, clases de UI, clases principales, etc. y asignan nombres a los bloques de funciones.
Luego visualice la funcionalidad con una herramienta gráfica (yo uso una herramienta de mapeo mental) para descubrir si su estructura es lo suficientemente lógica y modular como para poder reutilizar grandes bloques de código para diferentes proyectos y puede reemplazarlos con versiones más nuevas sin gran dolor.
La mejor manera de hacer esto en mi experiencia es crear un documento que visualice todas las dependencias entre sus clases y sus llamadas desde su código. El resultado es una visualización de su diseño de interfaz.
Si este mapa de código parece un clusterf *** completo, es hora de actuar.
Si aún no ha sucedido, debe pensar en una convención de nomenclatura adecuada que represente la estructura de su código de una manera que no tenga que pensar en cómo llamarlo y en qué hace.
3.) Utilice enfoques comunes para el control de calidad
Mi favorito es el FMEA. En términos de codificación, esto significa no solo analizar lo que salió mal en el pasado sino también pensar en lo que podría salir mal. Un ejemplo bastante común es una conexión de red caída repentinamente. Una vez que haya hecho esto, puede clasificar las condiciones de error por consecuencias como pérdida de datos, bloqueo, cálculo incorrecto y juzgar el impacto en el usuario.
Si aún no lo ha hecho, la definición de errores simplificados y las clases y rutinas de excepción puede ayudarlo a mantener su código limpio y directo. La mejor manera es implementarlas en cada nueva tranquilidad de código antes de comenzar a escribir cualquier otra cosa. (Bueno, soy culpable de no seguir siempre este consejo).
Además, me ayudó a generar y actualizar con frecuencia una "lista de propuestas de mejora" para mi propio código. (Para ser honesto, todavía hay mucho código en mis proyectos del que no estoy orgulloso).
También trato de tomarme el tiempo para recopilar y echar un vistazo al código de mejores prácticas de las documentaciones de API, las conferencias de desarrolladores o las revistas de desarrolladores.
Hasta este punto no es necesario que toque su código. Se trata simplemente de saber qué está mal y encontrar una manera de definir cómo mejorar su código.
Finalmente, algunos consejos para el trabajo diario de un viejo pedo. Intenta evitar morder más de lo que puedes comer.
Esto conduce a demasiada presión para una codificación limpia. Rara vez tienes tiempo para hacerlo bien, pero tendrás que tomarte el tiempo para corregir los defectos después.
Nada es tan duradero como la solución provisional, pero cuando se rompe, a menudo es demasiado tarde para solucionarlo a tiempo. Los ejemplos son hacks desagradables o extrañas excepciones que solía hacer que algo funcionara, p. Ej. una falla en el marco subyacente o sistema operativo. Y luego se solucionó el error o la nueva versión simplemente elimina la API ...
Si está atascado y se ve obligado a encontrar una solución alternativa, haga comentarios y tome notas que deberían revisarse de vez en cuando.
Normalmente nos mejoramos y mejoramos por aprender algo nuevo.
Si encuentras una manera mejor implementarla tan rápido como puedas.
De lo contrario, es posible que se encuentre codificando la solución para la solución y la excepción de la excepción algún día.
(El que está sin pecado entre vosotros, que me lance el primer byte).