¿Qué importancia tiene la modularización de los proyectos de software

Question

modularización es obviamente importante en los proyectos de software, pero yo quiero saber opiniones de la gente sobre cómo importante y por qué razones es importante. Obviamente tengo mis propias ideas desde que estoy preguntando esto, pero piensen en ello como una "lluvia de ideas común" sobre las razones por las cuales uno debería modularizar los proyectos de software ...

Answer 1

Mis principales razones para poner el código en diferentes módulos :

• separación de las preocupaciones: siento que es más fácil de limitar el conocimiento sobre el funcionamiento interno de las clases en diferentes niveles o con diferentes tareas si están organizados en módulos separados. Simplemente se siente más "sucio" para confiar en las partes internas si están bien escondidas.
• Más fácil de mantener componentes más pequeños: Normalmente encuentro que el entorno de desarrollo es más receptivo si estoy trabajando en un proyecto con menos archivos de código que si el proyecto contiene cientos y cientos de archivos.
• Prevención de conflictos de espacios de nombres: Cuando se modulariza adecuadamente, p. utilizando espacios de nombres en Java, puede tener el mismo nombre de función para la misma funcionalidad sin tener que preocuparse de que la función de impresión() en el componente Foo entre en conflicto con la función printout() en el componente Bar.
• Separación de cuestiones de seguridad: Es más fácil minimizar el daño potencial cuando un componente se para en los dedos de otro componente. Dependiendo de la tecnología que se utilice, puede limitar el lugar donde cada módulo puede reproducirse en la memoria.

Answer 2

Creo que uno de los aspectos principales es reutilizar. Cuando construyes cosas de forma modular, casi no hay cosas como: "Ah, ya he hecho esto antes, pero para usarlo, también tendré que obtener esto y esta funcionalidad, que no tiene absolutamente nada que ver con mi aplicación".

Además, es más fácil de entender. No puedo tener muchas cosas en mi mente al mismo tiempo. Cuando el código es modular, es más fácil establecer un "área" de cosas que tenga sentido en sí mismas. Y una vez que esta área tiende a ser pequeña, puedo entenderla como un todo y no como partes de ella.

Finalmente, cuando las cosas son más pequeñas, es más fácil de probar y mantener. Además, sus pruebas indican más rápido dónde está el error, una vez que probarán solo una pequeña parte de la aplicación.

Answer 3

Los humanos somos limitados cuando se trata de comprender problemas complejos a la vez. Sin embargo, estamos dotados de la capacidad de descomponer un problema complejo en un número (posiblemente muy grande) de problemas individuales que no son demasiado complejos para abordar el gran problema.

Esto es fundamentalmente lo que impulsa respuestas como "reutilización", "separación de preocupaciones", "mantenimiento más fácil".

Todas estas razones son verdaderas ya sea que una persona se deshaga de un problema complejo para abordar pieza por pieza, o si se trata de un equipo de personas dividiéndolo para distribuir la complejidad.

Answer 4

modularización y el desacoplamiento son importantes por muchas razones, algunas son:

• Reutilización: Es mucho más fácil de reutilizar módulos de software que se dedican a fines específicos
• gestión de la complejidad: Trabajando en módulos desacoplados (escritura código, depuración, mantenimiento, etc.) mantiene su enfoque en un cierto problema de dominio sin distraerse por otros aspectos de la aplicación o el sistema de software.

Answer 5

También puede ser visto como una actividad básica de Application Architecture cuales:

• toma algún negocio y especificación funcional
• y el grupo de las principales funciones en las aplicaciones, mientras que la identificación de los módulos no funcionales y puros técnico módulo transversal

Es por eso que un "cálculo de cartera financiera" se dividirá realmente en:

• un módulo de cálculo
• un módulo despachador (a causa de una cartera es demasiado grande para ser computada en un servidor)
• un módulo lanzador (para poner a prueba todos los cálculos)
• una interfaz gráfica de usuario (para ver qué que realmente está pasando)

Plus varios más transversales:

• KPI de registro
• gestión de excepciones

Para tratar ese tipo de requisito funcional como un módulo monolítico grande obligaría al desarrollo para poner en práctica todas las sub-rutinas en secuencia como un todo.
Considerando que con una arquitectura de aplicación clara, puede comenzar a trabajar en los módulos más generales y transversales mientras refina los otros módulos más orientados al negocio.

También obliga a definir más interfaces, y para analizar las interrelaciones comunicaciones Incidencias de sus diferentes módulos tendrán que resolver (directa-n-n a la tipología? Autobús ?, ...)