¿Cómo analizar datos?

El análisis de datos es un proceso en las primeras etapas del desarrollo de software, cuando examinas una actividad comercial y encuentras los requisitos para convertirla en una aplicación de software. Esta es una definición formal que puede llevarte a pensar que el análisis de datos es una acción que sería mejor dejar en manos de los analistas de sistemas, mientras que tú, el programador, deberías enfocarte en codificar lo que alguien más ha diseñado. Si seguimos estrictamente el paradigma de ingeniería de software, esto podría ser correcto. Los programadores experimentados se convierten en diseñadores y los diseñadores más agudos se convierten en analistas de negocios, teniendo así derecho a pensar en todos los requisitos de datos y darte una tarea bien definida para llevar a cabo. Sin embargo, esto no es del todo preciso, porque los datos son el valor central de cada actividad de programación. Sea lo que sea que hagas en tus programas, ya sea mover o modificar datos. El analista de negocios está analizando las necesidades en una escala más grande, y el diseñador de software está apretando aún más esa escala para que, cuando el problema llegue a tu escritorio, parezca que todo lo que necesitas hacer es aplicar algoritmos inteligentes y empezar a mover datos existentes.

Pero no es así.

No importa en qué etapa empieces a mirarlo, los datos son la principal preocupación de una aplicación bien diseñada. Si observas de cerca cómo un analista de negocios obtiene los requisitos de las solicitudes del cliente, te darás cuenta de que los datos desempeñan un papel fundamental. El analista crea los llamados Diagramas de Flujo de Datos, donde se identifican todas las fuentes de datos y se da forma al flujo de información. Una vez que se han definido claramente qué datos deben formar parte del sistema, el diseñador dará forma a las fuentes de datos en términos de relaciones de base de datos, protocolos de intercambio de datos y formatos de archivo, para que la tarea esté lista para ser entregada al programador. Sin embargo, el proceso no ha terminado, porque tú (el programador), incluso después de este exhaustivo proceso de refinamiento de datos, debes analizar los datos para realizar la tarea de la mejor manera posible. La línea de fondo de tu tarea es el mensaje central de Niklaus Wirth, el padre de varios lenguajes. "Algoritmos + Estructuras de Datos = Programas". Nunca hay un algoritmo que esté solo, haciendo algo por sí mismo. Se supone que cada algoritmo debe hacer algo al menos a un fragmento de datos.

Por lo tanto, dado que los algoritmos no giran sus ruedas en el vacío, necesitas analizar tanto los datos que alguien más ha identificado para ti como los datos necesarios para escribir tu código. Un ejemplo trivial aclarará el asunto. Estás implementando un procedimiento de búsqueda para una biblioteca. Según tus especificaciones, el usuario puede seleccionar libros por una combinación de género, autor, título, editorial, año de impresión y número de páginas. El objetivo final de tu rutina es producir una declaración SQL válida para buscar en la base de datos del servidor. Según estos requisitos, tienes varias opciones: verificar cada control a su vez, usando una declaración "switch" o varias declaraciones "if"; hacer un array de controles de datos, verificando cada elemento para ver si está establecido; crear (o usar) un objeto de control abstracto del cual heredar todos tus controles específicos y conectarlos a un motor de eventos. Si tus requisitos incluyen también ajustar el rendimiento de la consulta, asegurándote de que los elementos se verifiquen en un orden específico, puedes considerar el uso de un árbol de componentes para construir tu declaración SQL. Como puedes ver, la elección del algoritmo depende de los datos que decidas usar o crear. Tales decisiones pueden marcar la diferencia entre un algoritmo eficiente y uno desastroso. Sin embargo, la eficiencia no es la única preocupación. Puedes usar una docena de variables nombradas en tu código y hacerlo tan eficiente como sea posible. Pero dicho código puede no ser fácilmente mantenible. Quizás elegir un contenedor adecuado para tus variables podría mantener la misma velocidad y, además, permitir que tus colegas comprendan mejor el código cuando lo vean el próximo año. Además, elegir una estructura de datos bien definida puede permitirles ampliar la funcionalidad de tu código sin tener que reescribirlo. A largo plazo, tus elecciones de datos determinan cuánto tiempo sobrevivirá tu código después de que hayas terminado con él. Permíteme darte otro ejemplo, solo un poco más de comida para el pensamiento. Supongamos que tu tarea es encontrar todas las palabras en un diccionario con más de tres anagramas, donde un anagrama debe ser otra palabra en el mismo diccionario. Si lo piensas como una tarea computacional, terminarás con un esfuerzo interminable, tratando de trabajar todas las combinaciones de cada palabra y luego comparándolas con las demás palabras en la lista. Sin embargo, si analizas los datos disponibles, te darás cuenta de que cada palabra puede estar representada por un registro que contiene la palabra en sí y una matriz ordenada de sus letras como ID. Armado con dicho conocimiento, encontrar anagramas significa simplemente ordenar la lista en función del campo adicional y recoger aquellos que comparten el mismo ID. El algoritmo de fuerza bruta puede llevar varios días en ejecutarse, mientras que el inteligente es solo cuestión de segundos. Recuerda este ejemplo la próxima vez que te enfrentes a un problema intratable.

Siguiente Habilidades de Equipo - ¿Cómo gestionar el tiempo de desarrollo?