Я много чего читал в Интернете. Действительно сложно найти что-либо об архитектуре программного обеспечения JAVA. Однако архитектура разработки программного обеспечения в основном та же самая. Поэтому я поискал в Интернете множество статей по архитектуре программного обеспечения на других языках. И здесь позвольте мне рассказать о своих взглядах на архитектуру программного обеспечения, особенно на архитектуру проектов JAVA. Возможно, это не так, но это также мой итог за последние несколько лет.
1. Старайтесь не рассматривать возможность повторного использования вне проекта.
Многие люди думают, что лучше всего улучшить возможность повторного использования программного обеспечения. Однако реальная ситуация в каждом проекте будет разной. При разработке определенного модуля или метода в проекте слишком большое внимание к повторному использованию за пределами проекта неизбежно приведет к увеличению их числа. Сложность увеличивает время разработки. Некоторые могут сказать, что это снизит стоимость следующего проекта. Какой следующий проект? Каковы потребности? Какие факторы влияют на различные аспекты? Кто бы мог знать все это в такое время. Если вы действительно хотите повторно использовать, вам следует извлечь повторно используемые части после завершения проекта, изменить и оптимизировать их и использовать в качестве повторно используемых активов предприятия, а не выдавать желаемое за действительное в текущем проекте. Рассмотрите возможность повторного использования вне проекта. Это распространенная ошибка, которую допускают многие программисты, впервые работающие с программным обеспечением. Часто, чем больше они думают об этом, тем больше создаваемое ими программное обеспечение не достигает желаемого эффекта и не выполняет основные функции или не выполняет свои функции. Логические процессы кода Многие, функции программы не идеальны и так далее.
2. Часто проверяйте структуру проекта
Архитектура проекта обычно определяется до начала реализации проекта и представляет собой общий дизайн. Однако в настоящее время понимание требований проекта и оценка сложности все еще находятся на начальной стадии. Если архитектуру невозможно улучшить вместе с пониманием проекта в процессе разработки проекта, участники проекта неизбежно будут разрабатывать проект по неправильной архитектуре. Поэтому архитектуру проекта необходимо часто проверять и проводить необходимые рефакторинги.
3. Рефакторинг
Некоторые говорят, что после того, как вы так много написали, пересматривать — не пустая трата времени. Возможно, он не думал, что один день рефакторинга может ускорить разработку в ближайшие несколько месяцев. Сэкономленное время невообразимо. Более того, посредством рефакторинга обычно можно придумать более простые методы замены существующей реализации. Этот опыт также может упростить разработку других модулей.
4. Избегайте чрезмерной интеграции и позволяйте каждому модулю делать только свое дело.
Распространенным примером разработки открытого доступа является то, что в бизнес-системах обычно много утверждений, и многие люди сразу же подумают о том, чтобы объединить утверждения в универсальный модуль. С этим проблем нет, но обычная проблема в том, что слишком много людей помещают бизнес-обработку после утверждения в бизнес-логику модуля утверждения. По сути, это бизнес-модули каждого бизнес-модуля, и должно быть только утверждение. быть завершено после завершения утверждения. Однако что касается того, что делать после завершения утверждения, пусть модуль, выполняющий этот процесс, справится с этим самостоятельно.
5. Не будьте слишком гибкими
Дизайн и код не всегда настолько гибки, насколько это возможно. Типичным примером является то, что при использовании дженериков классы или методы могут работать с разными объектами. Однако в трехуровневой архитектуре, обычно используемой в JAVA, если серия классов изначально предназначена для работы с конкретным объектом, в этом нет необходимости. Указать его как универсальный тип, а затем указать, чтобы при его использовании использовался определенный класс сущности. Это кажется излишним.
6. Уменьшите вишенку на торте
Отсутствие обновления страницы, более крутые эффекты отображения и т. д. — все это вишенка на торте для бизнес-системы. Если из-за этого бизнес-интерфейс очень сложен, это приведет к ряду проблем в бизнес-обработке. В крайних случаях бизнес-обработка не может быть выполнена. Каким бы красивым ни был интерфейс, он бесполезен, если вы продолжите. Когда дело доходит до одного совета, принимайте во внимание остальные только в том случае, если вы хотите убедиться, что бизнес-процесс выполняется правильно. Обязательным условием для этого является необходимая коммуникация с пользователями. Другими словами, проекты, реализуемые с помощью JAVA, ориентированы на бизнес-обработку. Только когда бизнес-обработка хорошо реализована, можно принять во внимание красоту интерфейса и визуальное восприятие пользователя.
7. Разделите правильно
Это похоже на 4. Постарайтесь максимально снизить сложность каждого модуля и преобразовать умственную работу в физическую. Типичным примером является то, что форма обычно имеет функции добавления, изменения, удаления и просмотра. Однако первые три операции обычно выполняются людьми только в определенной функциональной точке, в определенном состоянии и с определенными разрешениями (возможно, только в единственном интерфейсе системы). Однако операции просмотра будут распределены по всем уголкам проекта. Если эти четыре операции поместить в один и тот же интерфейс, хотя количество интерфейсов может быть уменьшено, сложность этого интерфейса увеличится. Примите необходимые решения, чтобы сделать настройки только для чтения для элементов интерфейса. Увеличение сложности происходит по экспоненте, и если вы разделите представление, рабочая нагрузка будет линейной. Даже если вам придется сделать 10 интерфейсов представления, сложность будет. выше, чем предыдущий. С превращением его в 10*10 справиться гораздо проще, к тому же его можно компонентизировать.
8. Поддерживать хорошее общение с клиентами
Многие люди не обращают внимания на поддержание связи с клиентами. Многие архитекторы считают, что общение и общение с клиентами необходимы только на этапе реализации проекта. Это очень плохая привычка, поскольку требования клиентов со временем меняются. Только поддерживая хорошую связь с клиентами на регулярной основе, мы можем как можно скорее понять изменения в потребностях клиентов, тем самым корректируя план структуры нашего проекта для удовлетворения потребностей клиентов в кратчайшие сроки.
9. Связь между архитектурой проекта и архитектурой базы данных
Многие считают, что база данных не нужна при разработке проекта, если она реализована в памяти. Я лично считаю, что это очень плохая привычка для развития. Хотя база данных определяется в соответствии с конкретными потребностями проекта. Однако, если проект вообще не учитывает архитектуру базы данных в процессе создания архитектуры, вполне вероятно, что реализованные в проекте вещи будет трудно записать в базу данных или проектирование базы данных будет очень хлопотным, что фактически увеличит сложность разработки проекта. Более того, игнорирование базы данных в процессе разработки проекта может вызвать такие проблемы, как невозможность реализации некоторой бизнес-логики, потеря данных и т. д. после того, как проект будет связан с базой данных.
Конечно, у многих людей разные взгляды на архитектуру, основанные на разных архитектурных стилях, и мое мнение может быть неправильным. Я надеюсь, что каждый сможет чему-то научиться из моих материалов, а также надеюсь, что каждый сможет поделиться своим взглядом на архитектуру.