Uncategorized

Programando en C: Refactorización

Capítulo 12: Re factor izada Cion

En las 2 U anteriores, de manera más o menos consciente, menos hemos preocupado tanto de implementar nuevas funcionalidades, como de reestructurar y mantener el código limpio, mantenía ble, y entendible.

Éstas operaciones forman parte de un proceso más amplio llamado refacturación.

Lo importante en este caso es entender la utilidad de la refacturación y la necesidad de, cada poco tiempo, pararse por un momento y preguntarse si el código tiene una forma óptima, o podríamos reestructurarlo para hacerlo más fácil  de trabajar

En el día a día del desarrollo de programas informáticos, es muy común que, aunque se parta desde una planificación, finalmente se acaben implementando características sobre la marcha, en base a las necesidades que van surgiendo, y que desgraciadamente, muchas veces no pueden ser tenidas en cuenta en la planificación inicial.

esto provoca que, por muy ordenado y estructurado que pretendemos tener el código al principio de un proyecto, es totalmente común y normal que el código acabe ensuciándose, y que acabe adoptando una forma nada clara ni mantenimle.

El objetivo de la refacturación es detenerse cada poco tiempo y preguntarse de qué manera el código, manteniendo por supuesto su funcionalidad, podría ser más entendible para el ser humano, y estar estructurado de manera que, mantenerlo y ampliarlo, no resulte un esfuerzo titánico después de la realidad de cómo queda el código Al desarrollarlo poco a poco cada día.

Sin pretender entrar en esta publicación en demasiada profundidad con los principios y las técnicas de la refacturación, técnicamente, lo que hemos realizado en las 2 U anteriores, son dos técnicas bastante conocidas de esta filosofía de trabajo.

En primer lugar, la primera estrategia consiste en en capsular.

En cápsula amos porciones de códigos que tienen sed sentido como 1 U. Es decir, a lo largo del desarrollo de un programa, finalmente podemos ver fácilmente como hay porciones de código del programa que tienen sentido dentro de esa porción, y que podrían ser independientes del resto de la aplicación.

Por otra parte, como hemos comentado anteriormente, otra necesidad fundamental de crear funciones es cuando tenemos código que se repite.

Así que, el encapsulamiento de código en funciones, es una técnica de reorganización y reestructuración del código.

Antes de esta primera aplicación, generalmente, solemos tener un programa estructurado, es decir, un programa que puede perfectamente ocupar 500, 1000,2 1000 líneas de código, que va a lanzando instrucciones desde la primera hasta la última línea del programa. Fácil de entender, fácil de escribir, pero difícil de mantener, ya que cada vez que buscamos una porción del programa, tenemos que hacer Scroll a lo largo del código a través de miles y miles de líneas.

Al finalizar la refacturación que consiste en aislar segmentos en funciones, lo que acabamos teniendo es básicamente las mismas líneas de código, esos 500, 1000, o 2000 líneas de código, o quizás a veces mucho más, pero organizadas en burbujas, organizados en una serie de funciones, que anteceden a la función principal.

El código es más óptimo, pero la longitud del archivo no varía, así que acaba siendo aproximadamente igual de molesto tener que hacer Scroll a lo largo de miles de líneas cada vez que buscamos un segmento para modificar o cada vez que queremos implementar una nueva funcionalidad. Éste es verdaderamente uno de los problemas de la mantenía Billy dad de aplicaciones informáticas, que provoca que muchas veces tengamos que reescribir aplicaciones, simplemente porque nos cuesta menos Riesco reescribirlas, que mantenerlas, cuando el código se ha ensuciado demasiado. Evidentemente, lo que pretendemos es no tener que llegar a este.

es por esto que otra estrategia consiste en lo que hemos visto en la unidad anterior, básicamente extraer las funciones a archivos externos, incluirlas, en el caso del lenguaje que nos ocupa en esta publicación en las cabeceras.

Al hacer esto, el código podría pasar a tener aproximadamente esta forma:

tenemos un archivo principal que contiene la mínima expresión del código posible, y que, con suerte, puede verse todo en una sola pantalla, sin necesidad de hacer Scroll, o haciendo una cantidad mínima de Scroll a lo largo de las líneas.

Además, se visualiza la ejecución de las funciones, con lo cual, tenemos una idea muy aproximada mente de lo que hace el programa, aunque no necesariamente tenemos que estar viendo el código que contiene cada una de las funciones.

luego, por otra parte, si en un momento dado queremos profundizar en el código de alguna función concreta, simplemente tenemos que abrir la carpeta que contiene las funciones.

De un vistazo, podemos ver las funciones que contiene la carpeta, y si las hemos nombrado correctamente, podemos averiguar de un vistazo cuál es el archivo que tenemos que abrir para evitar.

cuando abrimos el archivo, estamos accediendo únicamente a la porción de código que nos interesa, y por tanto, estamos obviando todo ese código del resto de funciones que no nos interesa para implementar una nueva función concreta, o para retocar una parte de una función.

esta manera de trabajar, que solo nos ha exigido realizar dos operaciones de Rafa actualización, es totalmente conveniente, ya que nos permite aumentar enormemente nuestra productividad, trabajando más rápido, trabajando más cómodos, y en definitiva, permitiendo que, en un momento dado, el programa sea más fácil de extender, de hacer más grande, y de evolucionar

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *