나는 인터넷에서 많은 것을 읽었습니다. JAVA 소프트웨어 아키텍처에 대한 정보를 찾는 것은 정말 어렵습니다. 그러나 소프트웨어 개발 아키텍처는 기본적으로 동일합니다. 그래서 인터넷에서 다른 언어로 된 소프트웨어 아키텍처에 관한 많은 기사를 검색했습니다. 여기서 다시 소프트웨어 아키텍처, 특히 JAVA 프로젝트 아키텍처에 대한 나의 견해에 대해 이야기하겠습니다. 정확하지 않을 수도 있지만 이는 지난 몇 년간의 요약이기도 합니다.
1. 프로젝트 외부에서 재사용을 고려하지 마십시오.
많은 사람들은 소프트웨어의 재사용성을 높이는 것이 최선이라고 생각합니다. 그러나 프로젝트에서 특정 모듈이나 방법을 설계할 때 프로젝트 외부에서 재사용에 대한 고려가 너무 많으면 프로젝트마다 실제 상황이 다를 수 있습니다. 프로젝트의 복잡성으로 인해 개발 시간 오버헤드가 늘어납니다. 어떤 사람들은 이것이 다음 프로젝트의 비용을 줄일 것이라고 말할 수도 있습니다. 필요한 것은 무엇입니까? 다양한 측면에서 영향을 미치는 요인은 무엇입니까? 지금 이 시간에 누가 이 모든 것을 알겠습니까? 정말로 재사용하고 싶다면 현재 프로젝트에 대한 희망적인 생각보다는 프로젝트가 완료된 후 재사용 가능한 부분을 추출하고 수정, 최적화하여 기업의 재사용 가능한 자산으로 활용해야 합니다. 프로젝트 외부의 재사용성을 고려하십시오. 이는 소프트웨어 작업을 처음 접하는 많은 프로그래머가 흔히 저지르는 실수입니다. 종종 생각할수록 자신이 만드는 소프트웨어는 디자인 효과를 달성하지 못하거나 기본 기능을 완료하지 못합니다. 코드 논리 프로세스. 많은 프로그램 기능이 완벽하지 않습니다.
2. 프로젝트 구조를 자주 확인하세요
프로젝트 아키텍처는 일반적으로 프로젝트 구현이 시작되기 전에 결정되는 것이며 전체 설계입니다. 그러나 현재로서는 프로젝트 요구사항에 대한 이해와 복잡성 추정이 아직 초기 단계입니다. 프로젝트 개발 과정에서 프로젝트에 대한 이해와 함께 아키텍처를 개선할 수 없다면, 프로젝트 구성원은 필연적으로 잘못된 아키텍처에 따라 프로젝트를 개발하게 됩니다. 따라서 프로젝트 아키텍처를 자주 확인하고 필요한 리팩토링을 수행해야 합니다.
3. 리팩토링
어떤 사람들은 너무 많이 쓴 후에 그것을 수정하는 것이 시간 낭비가 아니라고 말합니다. 그는 어느 날 오후의 리팩토링으로 향후 몇 달 동안 개발 속도가 빨라질 수 있다고는 생각하지 못했을 것입니다. 또한 리팩토링을 통해 일반적으로 기존 구현을 대체할 수 있는 보다 간단한 방법을 생각할 수 있습니다. 이러한 경험을 통해 다른 모듈의 개발도 단순화할 수 있습니다.
4. 과도한 통합을 피하고 각 모듈이 자체 작업만 수행하도록 하십시오.
일반적인 OA 개발의 예는 일반적으로 비즈니스 시스템에 많은 승인이 있으며 많은 사람들이 즉시 승인을 범용 모듈로 만드는 것을 생각할 것입니다. 이는 문제가 없지만, 일반적인 문제는 너무 많은 사람들이 승인 이후의 비즈니스 처리를 승인 모듈의 비즈니스 로직에 넣는 것입니다. 사실 그것들은 각 비즈니스 모듈의 비즈니스 모듈이며, 승인은 오직 다만, 승인이 완료된 후 해야 할 일은 이 과정을 수행하는 모듈에서 자체적으로 처리하도록 하세요.
5. 지나치게 융통성 있게 행동하지 마세요.
디자인과 코드가 항상 가능한 한 유연하지는 않습니다. 일반적인 예는 제네릭을 사용할 때 클래스 또는 메소드가 다른 객체에서 작동할 수 있다는 것입니다. 그러나 JAVA에서 일반적으로 사용되는 3계층 아키텍처에서는 일련의 클래스가 원래 특정 엔터티에서 작동하도록 의도된 경우에는 필요하지 않습니다. 제네릭 타입으로 지정한 뒤, 사용 시 특정 엔터티 클래스를 사용하도록 지정하는 것입니다. 이것은 불필요한 것처럼 느껴집니다.
6. 케이크 장식 감소
페이지 새로 고침 없음, 더 멋진 디스플레이 효과 등은 모두 비즈니스 시스템에 금상첨화입니다. 이로 인해 비즈니스 인터페이스가 매우 복잡해지면 비즈니스 처리에 일련의 문제가 발생하게 됩니다. 인터페이스가 아무리 아름다워도 계속하면 아무 소용이 없습니다. 한 가지 조언에 관해서는 비즈니스 프로세스가 올바르게 수행되도록 하려는 경우에만 다른 조언을 고려하십시오. 이를 위한 전제조건은 사용자와의 소통이 필요하다는 것입니다. 즉, JAVA로 구현되는 프로젝트는 비즈니스 처리에 중점을 두어 비즈니스 처리가 잘 구현되어야 인터페이스의 아름다움과 사용자의 시각적 감각을 고려할 수 있습니다.
7. 적절하게 분할
이는 4와 유사합니다. 각 모듈의 복잡성을 최대한 줄이고 정신적 노동을 육체적 노동으로 전환하도록 노력하세요. 일반적인 예는 일반적으로 양식에 추가, 수정, 삭제 및 보기 기능이 있다는 것입니다. 그러나 처음 세 가지 작업은 일반적으로 특정 기능 지점, 특정 상태 및 특정 권한을 가진 사람들에 의해서만 수행됩니다(아마도 시스템의 유일한 인터페이스에서만). 그러나 보기 작업은 프로젝트의 모든 부분에 분산됩니다. 이 네 가지 작업을 동일한 인터페이스에 배치하면 인터페이스 수는 줄어들 수 있지만 이 인터페이스의 복잡성은 다양해져야 합니다. 인터페이스 요소에 대한 읽기 전용 설정을 수행하기 위해 필요한 판단을 내리면 복잡성이 기하급수적으로 증가하며, 뷰 인터페이스를 10개 만들어야 하더라도 작업량이 선형적으로 늘어납니다. 10*10으로 변환하는 것이 훨씬 쉬우며, 컴포넌트화도 가능합니다.
8. 고객과의 원활한 의사소통을 유지하세요
많은 사람들이 고객과의 커뮤니케이션을 유지하는 데 관심을 기울이지 않습니다. 많은 건축가는 고객과의 커뮤니케이션이 프로젝트의 수요 단계에서만 필요하다고 생각합니다. 고객 요구 사항은 시간이 지남에 따라 변경되기 때문입니다. 정기적으로 고객과 원활한 커뮤니케이션을 유지해야만 고객 요구 사항의 변화를 최대한 빨리 이해하고 이를 통해 최단 시간 내에 고객 요구 사항을 충족할 수 있도록 프로젝트 구조 계획을 조정할 수 있습니다.
9. 프로젝트 아키텍처와 데이터베이스 아키텍처 간의 연결
많은 사람들은 데이터베이스가 메모리에 구현되어 있는 한 프로젝트 개발 중에 데이터베이스가 필요하지 않다고 생각합니다. 저는 개인적으로 이것이 매우 나쁜 개발 습관이라고 생각합니다. 데이터베이스는 프로젝트의 특정 요구에 따라 결정됩니다. 그러나 프로젝트가 아키텍처 과정에서 데이터베이스 아키텍처를 전혀 고려하지 않는다면, 프로젝트에서 구현한 것들이 데이터베이스에 기록되기 어렵거나 데이터베이스 설계가 매우 번거로울 가능성이 높아 사실상 프로젝트 개발의 어려움. 또한, 프로젝트 개발 과정에서 데이터베이스를 고려하지 않으면 프로젝트가 데이터베이스에 연결된 후 일부 비즈니스 로직 구현 실패, 데이터 손실 등의 문제가 발생할 수 있습니다.
물론 많은 사람들이 각자의 건축 양식에 따라 서로 다른 건축적 견해를 갖고 있고, 내 의견이 정확하지 않을 수도 있다. 모두가 내 작품에서 뭔가를 배울 수 있기를 바라며, 또한 모두가 건축에 대한 자신의 견해를 공유할 수 있기를 바랍니다.