|
El primer paso es tener un administrador de código fuente. Git & Mercurial son los mejores al día de hoy. Aparte de sus ventajas naturales, si cada vez que haces un "commit" de los cambios colocas la razón del mismo o que hiciste, tenes una historia no solo en código, sino en los porqués de esos cambios.
Hacer búsquedas en los repositorios se vuelve muy fácil, incluso, buscar en cambios hechos meses atrás.
La 2da es propiamente organizar los proyectos en subproyectos/modulos. Eso es MUY difícil de hacer manualmente o con un software como subversion o JediCVS. Pero con uno distribuido es mas fácil. La "trampa" es subdividir el código en funcionalidades lógicas y separa lo que es general de lo que no.
Pero al contrario de lo que parece, es un error darle MUCHO énfasis a eso. De hecho, hasta se PUEDE ignorar. Solo vale la pena si realmente algo es tan comun y generico que valga la pena (ej: Un modulo de Logs).
Lo que comentas "Antes hacia así, ahora asa" muestra que si tienes un enfoque ágil del desarrollo, no es tan vital preocuparse por rehusar el código. Es MUCHO mejor NO TENER MIEDO de cambiarlo. Mientras progresas como programador, serás mas veloz y eficiente en rehacer la rueda una y otra vez, en vez de seguir con la misma siempre.
Eso te vuelve al punto 1. Si tienes GIT/Mercurial, hacer cambios es sin miedo. Y como tienes historia, sabras el porque y que exactamente hacías antes y como se diferencia del ahora.
Hay varias cosas extras que se pueden hacer. Como aplicar documentación automática del código y otros adornos. Pero, eso puede ser innecesario: La documentación es mas importante sobre lo que es estatico, lo que es una plataforma o framework. Y si eres solo o tienes un equipo de trabajo cerrado, quizas solo sea necesario de en casos específicos.
Mejor aun, es tener unit testings. Y hacer refactoring. Simplificar código. Eliminar lineas. Usar tecnicas mas modernas. Aplicar nuevos paradigmas que ayuden. Estar a la vanguardia.
|