[Feat/#3] Github API 데이터 처리를 위한 프로토타입 Demo 서버 구현

[SHKim55]

구현사항

• 서버의 동작 결과를 보여줄 test page 생성
• Service 내 테스트 데이터 기반 CRUD 일부 기능 구현 (C, R)
• GitHub API로 데이터 요청 (commit 데이터)
• 요청 받은 API 데이터 페이지에 출력

설계 중점사항

• Spring LayredArchitecture 적용을 위해 구현 코드를 Controller/Service/Domain/Others(Exception 등)로 구분 (참고: https://hudi.blog/layered-architecture/)
• 깃허브 API 관련 Controller 로직은 MainController에서 분리하여 작성

기타 사항 및 향후 발전 방향성

• 현재 빠른 기술 시현만을 위해 아키텍쳐 및 객체지향적 설계, 코드 컨벤션 등을 일체 고려하지 않은 raw code임을 인지하고 리뷰해주셨으면 좋겠습니다.
• 코드를 실행하면 단순히 api에서 가져온 데이터를 String을 변환하여 출력하는 것 밖에 없기 때문에 추후에 정제 작업이 들어갈 예정입니다.
• 페이지에 표시할 내용, API에서 가져올 데이터 범위, 항목별 가중치를 통한 유저 경험치 설정 등 좀 더 세부적인 기획안이 나온 이후에 추가 구현이 가능할 것으로 보입니다.
• 전체적인 Code Convention, Documentation Convention (PR, Issue, commit log 작성 포함)과 같은 협업 세부사항 또한 다음 회의에서 정해져야 될 것 같습니다.

[dmstjdhdh]

의문점 몇가지 여쭤봐도 괜찮을까요?

1. Spring LayredArchitecture는 Spring을 사용하는 소프트웨어에서 효율적인 개발과 유지보수를 위한 방식 중 하나일까요? 프로젝트의 요구사항이나 팀 선호도를 고려하였을 때, 상세한 정보가 주어져있지 않았을 때, 기본적으로 잡고가기 좋은 아키텍쳐이기 때문에 선택한 것 같아 맞는지 확인해보고 싶었습니다!
2. raw code는 코드 컨벤션, 객체지향적 설계를 고려하였을 때 수정되는 코드일까요? 삭제, 혹은 dummy 코드일 가능성도 있는 코드인걸까요?
3. 코드 컨벤션은 누가 작성해야 효율적일까요?

[SHKim55]

1. 해당 아키텍쳐의 경우 현재 Spring 개발에서 주로 사용되는 아키텍쳐 중 하나로, '관심사의 분리'(Separation of Concerns)라는 설계적 목표에 최대한 다가갈 수 있는 아키텍쳐입니다. Controller와 Service, Domain은 프로그램 내에서 수행하는 역할이 극명하게 나누어지며, Controller와 Domain은 서로 절대로 상호의존 할 수 없다는 특징을 가집니다. 프로젝트나 Spring에 대한 제반 지식이 없어도 디렉토리에 따라 클래스 별 기능들을 명확하게 구분할 수 있기에 현재로서는 해당 아키텍쳐를 채택하였습니다. 향후 MVC나 다른 아키텍쳐로의 전환도 고려할 예정입니다.

2. 기존에 사용했던 코드를 최대한 재사용하는 것을 목표로 하기 때문에 Dummy 코드로 처리되어 아얘 없애는 일은 없을 것으로 보입니다.

3. 실제 개발진들이 작성하는 것이 효율적이지만 모든 구성원들이 개발에 다 참여하는 저희 프로젝트의 특성 상 정기회의 시간에 같이 정하는 것이 좋아보입니다.

[dmstjdhdh]

핑프짓 한번 하겠습니다... domain, controller, service가 각각 어떤 단위로 나눠지는거죠? 각각 이름마다 뭘 하는 단위인지 이해가 먼저 되면 좋을 것 같다는 생각이 있습니다!

[SHKim55]

Controller(Web): 사용자와 직접적으로 상호작용하는 로직이 위치한 계층 (입출력, GUI 등) Service: 핵심 비즈니스 로직, Core 로직을 담고 있는 계층 Domain(Repository): Service의 기반이 되는 데이터들이 위치한 계층 (도메인 객체, 엔티티 등)