2013-05-10

97/6 cosas que todos los programadores deberían saber


En algún momento, todos los programadores tendrán que refactorizar código existente. Pero antes de hacerlo así que por favor piense en lo siguiente, ya que usted y otras personas podría ahorrar una gran cantidad de tiempo (y el dolor):
  • El mejor enfoque para la reestructuración comienza por hacer un balance de la base de código existente y las pruebas escritas contra ese código. Esto le ayudará a entender las fortalezas y debilidades del código en su estado actual, por lo que puede garantizar que se mantengan los puntos fuertes y evitar los errores. Todos pensamos que podemos hacer algo mejor que el sistema actual ... hasta que nos encontramos con algo que no es mejor - o peor aún - que la anterior encarnación, porque no hemos podido aprender de los errores del sistema existente.
  • Evite la tentación de volver a escribir todo. Lo mejor es volver a utilizar tanto código como sea posible. No importa lo feo es que ya se ha probado el código, revisado, etc tirar el código antiguo - sobre todo si era en la producción - que significa que va a tirar meses (o años) de la prueba, el código aguerrido que pueden haber tenido ciertas soluciones y correcciones de errores que no son conscientes. Si usted no toma esto en cuenta, el nuevo código que se escribe puede llegar a mostrar los mismos errores misteriosos que fueron corregidos en el código antiguo. Esto hará perder mucho tiempo, esfuerzo y conocimientos adquiridos a través de los años.
  • Muchos de los cambios graduales son mejores que un cambio masivo. Cambios incrementales le permite medir el impacto en el sistema con mayor facilidad a través de comentarios, por ejemplo, de pruebas. No es divertido ver a un centenar de pruebas fallidas después de realizar un cambio. Esto puede conducir a la frustración y la presión que pueden a su vez dan lugar a malas decisiones. Un par de fallos en la prueba es fácil de manejar y proporciona un enfoque más manejable.
  • Después de cada iteración, es importante asegurarse de que las pruebas existentes pasan. Añadir nuevas pruebas si las pruebas existentes no son suficientes para cubrir los cambios realizados. No tire las pruebas desde el código anterior sin la debida consideración. En la superficie de algunas de estas pruebas pueden no parecen ser aplicables a su nuevo diseño, pero sería bien vale la pena el esfuerzo de cavar profundamente en las razones por las que se añadió esta prueba en particular.
  • Las preferencias personales y el ego no deben ponerse en el camino. Si algo no está roto, ¿para qué arreglarlo? Que el estilo o la estructura del código no se ajusta a sus preferencias personales no es una razón válida para la reestructuración. Pensando que podría hacer un mejor trabajo que el programador anterior no es una razón válida tampoco.
  • La nueva tecnología es razón suficiente para refactorizar. Una de las peores razones para refactorizar es debido a que el código actual está muy por detrás de toda la tecnología de frío que hoy tenemos, y creemos que un nuevo idioma o marco puede hacer las cosas mucho más elegante. A menos que un análisis de costo-beneficio muestra que un nuevo idioma o marco dará lugar a importantes mejoras en la funcionalidad, facilidad de mantenimiento, o la productividad, lo mejor es dejarlo como está.
  • Recuerde que los seres humanos cometen errores reestructuración no siempre garantiza que el nuevo código será mejor -. O incluso tan bueno como - el intento anterior. He visto y he sido parte de varios intentos fallidos de reestructuración. No fue bonito, pero era humano.