Насколько важна модульность программных проектов

Question

Модуляризация, безусловно, важна в программных проектах, но я хочу узнать мнение людей о , как важно и по каким причинам это важно. Очевидно, у меня есть свои идеи, так как я спрашиваю об этом, но думаю, что это «общий мозговой штурм» причин, по которым нужно модульно воплощать свои программные проекты ...

Answer 1

Мы, люди, ограничены, когда речь заходит о сложных проблемах одновременно. Тем не менее, мы наделены способностью разложить сложную проблему на (возможно, очень большое) число отдельных проблем, которые не слишком сложны для решения большой проблемы.

Это в основном то, что приводит к ответам, таким как «повторное использование», «разделение интересов», «более простое обслуживание».

Все эти причины верны, будь то один человек, решающий сложную задачу для решения по частям, или это команда людей, разбивающих ее для распределения сложности.

Answer 2

Я думаю, что одним из основных аспектов является повторное использование . Когда вы строите вещи модульно, вряд ли есть что-то вроде: «О, я уже делал это раньше, но чтобы использовать это, мне также придется получить эту и эту функциональность, которая абсолютно не связана с моим приложением».

Кроме того, это легче понять. Я не могу одновременно держать в уме тонны вещей. Когда код является модульным, легче установить «область» вещей, которая имеет смысл сама по себе. И как только эта область становится маленькой, я могу понять ее целиком, а не ее части.

Наконец, когда вещи меньше, легче тестировать и обслуживать. Кроме того, ваши тесты быстрее показывают, где находится ошибка, когда они будут тестировать только небольшую часть приложения.

Answer 3

Мои основные причины для размещения кода в разных модулях:

• Разделение интересов : Мне кажется, что легче ограничить знания о внутренностях классов на разных уровнях или с разными задачами, если они организованы в отдельные модули. Просто кажется более «грязным» полагаться на внутренние органы, если они хорошо спрятаны.
• Легче поддерживать меньшие компоненты : Обычно я нахожу среду разработки более отзывчивой, если я работаю над проектом с меньшим количеством файлов кода, чем если проект содержит сотни и сотни файлов. *
• Предотвращение столкновений пространства имен : При правильной модульности, например, используя пространства имен в Java, вы можете иметь одно и то же имя функции для той же функции, не беспокоясь о том, что функция printout () в компоненте Foo будет конфликтовать с функцией printout () в компоненте Bar.
• Разделение проблем безопасности : потенциальный ущерб легче минимизировать, когда один компонент наступает на пальцы другого компонента. В зависимости от используемой технологии вы можете ограничить область воспроизведения каждого модуля в памяти.

Answer 4

Модуляризация и развязка важны по многим причинам, некоторые из них:

• Повторное использование: намного проще повторно использовать программные модули, предназначенные для определенных целей
• Управление сложностью: Работа с отсоединенными модулями (написание кода, отладка, сопровождение и т. Д.) Позволяет сосредоточиться на определенной проблеме домена, не отвлекаясь на другие аспекты приложения или программного обеспечения.

Answer 5

Это также можно рассматривать как базовое действие Архитектура приложения , которая:

• требует некоторых деловых и функциональных спецификаций
• и сгруппировать основные функции в приложения, идентифицируя нефункциональные модули и чисто технический поперечный модуль

Именно поэтому «расчет финансового портфеля» будет фактически разделен на:

• вычислительный модуль
• модуль диспетчера (поскольку портфель слишком велик для вычисления на одном сервере)
• модуль запуска (для запуска всех вычислений)
• GUI (чтобы увидеть, что на самом деле происходит)

Плюс несколько трансверсальных:

• Регистрация KPI
• Управление исключениями

Рассмотрение такого рода функциональных требований как одного большого монолитного модуля заставило бы разработку реализовать все подпрограммы в последовательности как все.
Принимая во внимание, что с четкой архитектурой приложения вы можете начать работать с более общими и трансверсальными модулями, в то же время улучшая другие более ориентированные на бизнес модули.

Это также заставляет вас определять больше интерфейсов и анализировать проблемы взаимодействия, которые придется решать вашим различным модулям (прямая типология n-to-n? Bus ?, ...)