Por supuesto no. No escribe código perfecto la primera vez sin importar el marco, las herramientas o el estilo de codificación. Incluso es difícil obtener todos los nombres de variables correctamente la primera vez.
De hecho, está en gran medida subestimado: las personas escriben por la capacidad de prueba pero no por la capacidad de refactorización, que es al menos tan importante (mi sesgo es que es más importante). Estas son algunas de mis experiencias que lo ayudarán a comprender mi punto de vista.
1.) El cliente declara que mantener una lista maestra de datos del equipo aún no es importante. Unos meses más tarde, él / ella declara que es importante, por lo que debe cambiar todo el nombre del equipo a identificadores y desacoplarlo para todas las tablas / objetos que se refieren a ellos. Esto sucederá para abordar datos, activos físicos como edificios, equipos, etc. y activos de tiempo como semestres, trimestres y horarios planificados. Un campo muerto que consideró “solo un campo de texto” “evolucionará” hacia algo más profundo.
2.) El cliente cambia las reglas de negocio sobre la marcha, lo cual es frecuente. Él / ella declararía que “Algunos clientes solo pueden comprar un producto por marca por estos días” o “Algunos productos tendrían un precio diferente a partir de ahora” o “Poner una excepción de que algunos estudiantes podrían inscribirse sin pagar, pero seguirlo” . Este tipo de solicitudes (si la habilidad de refactorización es baja) contaminaría el código con un millón de declaraciones if / else sin vincular por todas partes en lugar de vincular esas declaraciones if / else en una clase (que tendría un nombre razonable como HolidayConstraints o EnrollmentOverrides) .
3.) El programador A crea una función llamada RenderData que es pequeña y razonable. Sin embargo, el Cliente solicita que se presenten más y más datos. El programador B debe dividir RenderData en RenderHeader, RenderSummary y RenderDetails. Si el Programador A escribió RenderData para ser un chat de lectura-impresión-lectura-impresión (porque las solicitudes se hicieron con el tiempo) en lugar de leer-una vez-e-imprimir una vez, el Programador B debería saber cómo refactorizarlo.
4.) Crea un programa que se localizaría (cambiaría de idioma). ¿Cómo desacoplar el etiquetado de la aplicación? Algunos marcos lo hacen más fácil que otros, PERO esto se vuelve más difícil cuando AJAX se involucra.
5.) El programador A (por cualquier razón técnica) crea un proyecto en el que la estructura del archivo no refleja el programa que se está escribiendo. Simplemente no puede mirar las carpetas / archivos (sin abrirlos) y comprender que es un programa de contabilidad. La estructura de archivos es un trillón de relaciones de archivos de inclusión todas llamadas * .jsp o * .php donde el nombre de archivo no se relaciona con la página real. ¿Cómo refactorizar eso? Cambiar el nombre de los archivos de una manera que tenga sentido en una aplicación por aplicación. O puede convertirlo a MVC, lo que sea más fácil. (Sospecho que cambiar el nombre es más fácil)
6.) Tu amigo escribe una extensión en tu código pero no quieres romperlo. Entonces él escribe sus líneas al final de su función o en otra clase. Debe refactorizarlo para que se ajuste a su estilo de codificación e integrarlo si es una extensión central. En serio, debes recordar hacer esto.
Descargos de responsabilidad:
1.) De ninguna manera estoy diciendo refactoring> testing. Estoy diciendo que deben ir juntos. Las pruebas le permiten detectar errores, la refactorización le permite corregir errores de manera más consistente.
2.) Refactorizar no significa desacoplar todo. Significa acoplarlo si el caso de uso está acoplado y desacoplarlo cuando no lo está. Una solicitud web no debe desacoplarse a las transmisiones y encabezados de solicitud, etc., donde lo único que le interesa es la llamada URL. El estilo de codificación que permite acoplar / desacoplar a voluntad con facilidad es el sello distintivo del código refactible. ¿Cómo es esto posible? Control de estado (no haga variables globales incluso en javascript) y estilo funcional de programación. Mi ejemplo anterior es una función acoplada (la función de orden superior para ser formal) llamada RenderData se puede desacoplar a RenderHeader y RenderDetails y viceversa. En términos simples: divisibilidad y capacidad de ensamblaje.
3.) La refactorización no solo incluye el código sino también la estructura del archivo.
Preguntas finales
1.) ¿Puedes sobrevivir a largo plazo con un código refactible sin pruebas? Sí, para muchos proyectos c y c ++ de hecho. Aquí está el kernel de Linux: NO HAY PRUEBAS DE LA UNIDAD pero es altamente refactible (en mi opinión debido a la estructura del archivo) https://github.com/torvalds/linux
2.) ¿Puede sobrevivir a largo plazo con un gran número de pruebas con un código altamente irrefactible? No lo sé y no quiero asumir nada.