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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюс несколько сквозных:

• ведение журнала KPI
• управление исключениями

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

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