Principios del Diseño de Software


El diseño de la arquitectura de software es una fase muy importante en el ciclo de vida del software. Es absolutamente necesario desempeñar ésta tarea con demasiada cautela, ya que un error en ésta fase del desarrollo puede lastrar todo un proyecto y llevarlo a caer en una espiral de  constantes cambios.

Existen algunas reglas las que podríamos considerar a la hora de diseñar la arquitectura del sistema.

Reusabilidad – Cada fragmento de software debe ser lo más reutilizable posible (a menos que sea aplicativo), y reutilizar otros componentes lo mayor posible.

Extensibilidad – Cada fragmento de software deberá ser lo más extensible posible, es decir, tener todos los lugares posibles para añadir más funcionalidad.

Funcionalidad – Cada fragmento de software debe hacer la vida mas fácil al usuario, la regla 80-20 debe encajar aqui (por lo menos un 80 % del tiempo…).

Orden – Cada pieza de software debe estar organizada para encontrar fácilmente cada fragmento de código, y estructurado de forma fácil para poder añadir un nuevo fragmento.

Trazabilidad – Cada fragmento de software deberá registrar sus acciones en detalle, preferentemente en diferentes niveles de detalles. Utilizar librerías de logging facilitarán tu trabajo.

Seguridad – Cada pieza de software no debe revelar sus debilidades de seguridad, eso permitiría que se abusara maliciosamente del sistema, como inyección de código, modificación de privilegios no autorizados, denegación de servicios del sistema, etc.

Portabilidad – Cada fragmento de software debe ser lo más portable posible. No necesariamente entre diferentes sistemas operativos, pero generalmente entre diferentes ordenadores. La no-instalación (despliegue xcopy) es bienvenida en la portabilidad.

Reusabilidad

Cuando desarrollas software, el factor de reusabilidad es crucial, especialmente cuanto tienes plazos que cumplir. Divide tu código en varias librerías bien definidas, que te permita utilizar en otros proyectos, por lo general te costará menos en conceptos de tiempos, esfuerzo y dinero cuando varios proyectos están involucrados.

Si solamente tienes un proyecto, aún así deberías reutilizar. Deberías separar código reutilizable en una librería lo que te permitirá simplificar aún más el código a mantener.

Cuando no Reutilizar

Un caso donde no es bienvenida la reutilización es en un proceso muy específico.

Otro caso donde no se recomienda reutilizar, es la falta de entendimiento para encontrar el la forma correcta de construir código reutilizable. Por lo general, el código en cuestión se escribió sólo una o dos veces.

Te lo explicaré: escribes un fragmento de software que hace una determinada tarea, y crees que esta tarea podría repetirse en el futuro, lo exportas a una biblioteca. Entonces, después de un tiempo, deseas volver a utilizarlo, en otro lugar, pero ya ves que no es lo suficiente extensible, lo suficientemente portátil, no responde a sus requisitos de funcionalidad, etc.

Todavía tienes que escribir tu propio código. O tienes que fijar la biblioteca para adaptarse a los dos proyectos, y luego ir y arreglar el viejo proyecto que ya lo utiliza. La fijación de la biblioteca en este momento sería difícil, ya que las necesidades del nuevo proyecto no se tuvieron en cuenta en el diseño original. Cuando un proyecto de tercera que lo necesita, esto podría repetirse de nuevo.

Por lo general, una buena idea esperar hasta que haya requisitos de al menos tres proyectos diferentes antes dedecidirse a hacer una pieza de código de una biblioteca reutilizable.

Extensibilidad.

La extensibilidad te permite añadir nuevas funcionalidades en el futuro. Existen muchos tipos de extensibilidad, tanto internas como externas.

Extensibilidades externas son las más importantes. El desarrollador de software reutilizable deberá tener en cuenta la necesidad de otro desarrollador para añadir funcionalidad o hacer las cosas un poco diferentes de su propio punto de vista.

Por ejemplo, supongamos que tienes una clase que contiene un control de usuario, y ese control de usuario es visible para el usuario final.  Puedes agrupar por completo, solamente la funcionalidad que consideres útil. Pero en algunos casos un desarrollador puede querer ajustar este determinado control, y puede ser que no le han dado la opción de hacer su pequeña modificación.

Mejores Prácticas de Extensibilidad.

Una regla de oro de extensibilidad sería exponer la funcionalidad de siempre a través de interfaces, y si desea que el usuario sea capaz de llevarlas a la introducción de los objetos creados a tu librería, utilice el patrón de fábrica, y permitir al usuario el registro de sus propios tipos. Esto le permite reemplazar el código detrás de la interfaz como todo lo que quieras sin que el usuario tiene que desconfiar de él, y también permite al usuario introducir sus propios tipos.

Por lo general, prefieren introducir interfaces en lugar de las clases base. Si el usuario necesita integrar en su proyecto en curso un código, una clase de base puede que le impida hacer lo que necesite, puede ser que quiera agregar funcionalidad a una clase actual que ya tiene, que hereda de otra clase base. Con interfaces, esto siempre es posible.

Si tienes un método que devuelve un resultado, prefieres crear una clase que de resultado especializado y llenarla con los datos pertinentes. Si deseas añadir datos en el futuro, esto sería tan fácil como agregar campos a la clase ya existente.  Crea un método con un parámetro extensible (Array de String…) de entrada aunque se encuentre vacío, probablemente se utilice en un futuro.

Funcionalidad.

Cuando desarrollas software, asegúrate que cada parte del software hace lo que se necesita que haga, y no lo que no se necesita que haga. Parece obvio, pero no lo es.

Cuando piensas donde situar cada método del software que implementa algunas de las funcionalidades requeridas, intenta agrupar los métodos que se encuentren relacionados en funcionalidad. Intenta evitar funcionalidades duplicadas, simplemente por pequeñas diferencias. Si tienes que hacerlo, hazlo de la forma más inteligente, reduciendo la duplicidad de código a lo mínimo necesario. Utiliza clases de soporte, o métodos de soporte lo más que puedas, y hazlos estáticos, así reducirás el costo y optimizarás los recursos del sistema.

La funcionalidad expuesta, deberá encajar con las necesidades del usuario. El código reutilizable, no debe cubrir el 100% de los casos. Al menos el 10% de los casos son tan extraños, que nunca habrás pensado en ellos.

Realiza una búsqueda exhaustiva y encuentra el 80% de los casos que son relevantes para ti. No mires lo que no se encuentre relacionado con el negocio. Esos casos hacen las cosas de una manera diferente, y tienen un ámbito diferente. Mira implícitamente en tu negocio. Incluso en tu negocio, hay mucha información al respecto y deberás encontrarla. Si no la encuentras, simplemente significa que quizás esa funcionalidad no necesites hacerla reutilizable. Simplemente hazla de forma aplicativa.

No utilices tecnología intrusiva en tu código, si lo haces, documenta porque lo haz hecho.

Orden y Estructura.

Cuando desarrollas la estructura de tu proyecto, hazla significativamente separada por la logica, no en terminos físicos. Piense en alguien que no conoce el proyecto y necesita un fichero determinado, si no puede encontrarlo es que la estructura no sigue una lógica determinada.

De la misma manera se pueden utilizar directivas de región. Si veo miles y miles de métodos públicos, como podré encontrar lo que necesito realmente. Sería óptimo separar las funcionalidades por región, considérese por el tipo de interacción con el usuario, diseño de lógica, construcción e inicialización.

Trazabilidad.

El software debe registrar las acciones y los errores, estos registros serán luego utilizados para analizar el uso de la aplicación tanto para evaluar el performance, los errores, los comportamientos inesperados, etc.

Utiliza un método común para registrar todas las partes de la aplicación. Un método altamente configurable y extensible en lo posible, porque en el caso inesperado de que una tercera persona desee extender ésta funcionalidad, deberá poder hacerlo.

Seguridad.

La seguridad es una cuestión muy importante en las aplicaciones, especialmente cuando el software es expuesto a una larga lista de usuarios, y realmente no puedes saber a ciencia cierta quien desea hacer daño a tu empresa o a tus clientes.

Cuando creas consultas de base de datos, asegúrate de limpiar las consultas para prevenir inyecciones SQL, éstas pueden hacerte perder muchísima información.

Cuando tienes parámetros de entrada de cualquier tipo, asegúrate de que tienes suficiente espacio para almacenarlo, limitar lo que debes limitar y evita la inyección de código.

Portabilidad.

Un software portable es mucho mejor que un software que necesitas instalar. Copiar ficheros a un lugar es mucho más fácil que seguir un procedimiento de instalación.

Acerca de fabiancouto

Nacido en Montevideo, Desarrollador de software en @brujula_talk & owner de @TrabajoBalear. Adicto a la ironía y al sarcasmo. En busca de sabiduría y felicidad.

Publicado el 2 junio, 2010 en Buenas Prácticas, Tecnología y etiquetado en , , , , , , , , , , . Guarda el enlace permanente. 3 comentarios.

  1. Hi there, You’ve done an excellent job. I will certainly digg it and personally recommend to my friends. I am sure they’ll be
    benefited from this site.

  1. Pingback: Fundamentos del diseño | veramarycela

  2. Pingback: Bitacoras.com

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: