---

📝 과제 개요

---

✔️ 개발 환경

• Java: 17
• JDK: 17.0.1
• IDE: IntelliJ
• Spring Frame Work : 3.4.4
• API 테스트 도구 : postman

✔️ 공통 조건

• 일정 작성, 수정, 조회 시 - 비밀번호 안 보이게
• 일정 수정, 삭제 - 요청 비밀번호와 비밀번호가 같을 때
• 3 Layer Architecture 활용
• CRUD 필수 기능은 데이터 베이스 연결 + JDBC 활용

---

🎨 구현한 내용

---

🌟 Git Hub 링크 & ReadMe / API 명세서

필수기능	단계별	요구사항
✅	Level 0	API 명세서 작성하기, ERD 작성하기, SQL 작성하기
✅	Level 1	일정 생성 (고유 식별자 자동 생성하여 관리)
		전체 일정 조회 (수정일, 작성자명 바탕으로 일정 조회)
		선택 일정 조회 (고유 식별자로 조회 )
✅	Level 2	선택 일정 수정 (비밀번호 검증)
		선택 일정 삭제 (비밀번호 검증)

---

📋 고민했던 부분

---

1️⃣ 적절한 관심사 분리를 적용했는가?

• Controller
  최대한 요청에 대한 응답을 반환하는 역할만 하도록 분리했다

• Service
  비즈니스 로직을 담당하고, 검증이나 예외처리를 여기서 하려고 노력했다.
  (생각해보니 전체 일정 조회-조건부 필터링 할 때 null 검증을 이곳 저곳에서 한 것 같다🥲)

• Repository
  DB를 입력하고 꺼내오고 기존 DB와 비밀번호가 일치하는지 등등..
  JDBC를 기반으로 sql을 활용해 조건을 필터링했다

2️⃣ RESTful한 API를 설계했는가?

• ✔️ RESTful API 체크리스트

  항목	준수 여부
  리소스 명사 사용	✅
  복수형 사용	✅
  동사 허용 조건	동사 사용 없음
  자원 계층 관계 표현	✅ 공통 계층/schedules사용, 기능에 따라/{id} 사용
  끝에 슬래시 금지	✅
  (언더바 사용 금지)하이픈 사용	하이픈 사용 없음
  소문자 사용	✅
  파일 확장자 포함 금지	✅
  CRUD 함수명 미사용	✅ POST, DELETE 등 HTTP 메서드 사용
  필터/정렬/페이징	✅ 일정 전체 조회(필터)시 query param 사용 /schedules?user=Surin&date=2025-03-25

3️⃣ 수정, 삭제 API의 request를 어떤 방식으로 사용했는가?

• id : Path로 전달
• 비밀번호 : Body 내의 dto로 전달
  수정과 삭제 API 모두 ID는 @PathVariable로 전달하고
  비밀번호는 query나 param에 노출하지 않고 @RequestBody로 전달하여 repository에서 검증했다

---

🛠️ TroubleShooting

---

❶ 관심사 분리

📌 문제

• 아직 모든게 미숙했기에 강의 내 '메모장 프로젝트'를 참고해서
  모든 로직을 컨트롤러에 다 넣어 만들고 ➝ 관심사를 분리하고 ➝ DB에 연결하며 더 확실하게 역할을 나누는 과정으로 작성했다.

💡 해결방법

• Controller는 요청/응답 담당
• Service는 검증 및 로직 담당
• Repository는 DB와 직접 통신
• 강의대로 하다보니 Service, Repository 인터페이스를 만들었는데,
  생성자나 매개변수가 바뀔때마다 인터페이스에서 한번에 수정하고 임플리먼트하니까 편했다

---

❷ 수정 / 삭제시 비밀번호 처리

📌 문제

• 공통 조건 충족을 위해 수정이나 삭제시에는 비밀번호를 받아 검증해야 했고,
  반환될 때는 응답되어선 안됐다... 이건 해본 적이 없었다..! 실습예제에 없다..😂

💡 해결방법

• id는 @PathVariable / 비밀번호는 @RequestBody를 통해 dto로 받아 전달했다

  

• 둘다 비밀번호를 활용해야 해서 ScheduleRequestDto를 활용하고
  강의에서 나온대로 Service에서 int타입을 사용해서 예외 상황을 가정했다

• Repository에서 비밀번호가 일치하는지 검증하기 전에 Service에서 예외상황에 대한 상태코드와 메세지를 나타냈다

  

---

❸ 비밀번호 검증하기

📌 문제

• 수정 / 삭제시 받아온 비밀번호가 기존 테이블의 비밀번호와 일치하는지 확인해야했다.
• java에서 sql문 활용이 익숙치 않아 생각보다 시간이 많이 걸렸다

💡 해결방법

• 비밀번호를 검증하는 sql쿼리를 작성했다.
• 입력값들은 쿼리 내에 직접 작성하지 않고 placeholder ? 로 대체하고 파라미터로 바인딩했다
• placeholder

---

❹ 수정일 미반영 문제

📌 문제

• 수정후에 수정일이 null이거나, 수정 완료후에 작성일이 null이거나..
  계속 null 파티였는데 심지어 테이블 생성시에 날짜는 전부 NOT NULL로 등록해둬서 exception 파티였다

💡 해결방법

• 일단 DB에 DEFAULT값을 추가해줬다 TIMESTMAP = CURRENT_TIMESTAMP 사용

  
  ALTER TABLE schedule 
  MODIFY created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP;
  
  ALTER TABLE schedule 
  MODIFY updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP;

• 일정 생성시 : 작성일 수정일을 둘다 현재시간으로 초기화 해주고 데이터에 저장했다

  

• 일정 수정시 : 수정일만 사용하고 현재시간으로 업데이트 했다

  

---

❺ 조건부 조회 설계

📌 문제

• 조건을 작성자명이나 수정일로 필터링을 해야하는데 이 조건이 둘다 있을 수도, 하나만 있을 수도, 둘다 없을 수도 있었다.
• 조건에 따라 sql문을 다르게 사용해야 했다.

💡 해결방법

• 일단 Controller에서는 둘다 null이 들어올 수 있게 해놓고 required = false
  

• Repository에서 user만 있을때, date만 있을때 각각 다르게 sql문을 이어붙였다
  

• sql문 동적으로 생성하는 방법을 찾아 작성했다

@Override
    public List<ScheduleResponseDto> findAllSchedules(String user, String date) {

        StringBuilder sql = new StringBuilder("select * from schedule where 1=1 ");
        List<Object> fillteringSql = new ArrayList<>();

        if (user != null){
            sql.append("AND user = ?");
            fillteringSql.add(user);
        }

        if (date != null) {
            sql.append("AND DATE(updated_at) = ?");
            fillteringSql.add(Date.valueOf(date));
        }

        sql.append("Order by updated_at desc");

        return jdbcTemplate.query(sql.toString(),scheduleRowMapper(), fillteringSql.toArray());
    }

---

🌟 나의 회고

---

• Spring 기초에서 가장 중요한 개념은 ‘관심사 분리라는 걸 이번 과제를 통해 확실히 알게 되었다.
  처음에는 어떻게 시작해야 할지 몰라서, Spring이 처음인 나는 4주차부터 6주차 강의 중 실습 위주로 반복하며 따라 만들었다.
  처음엔 코드를 통으로 짜고, 그걸 분리하고, 또 분리하고… 데이터를 연결하면서 구조를 바꾸다 보니
  자연스럽게 Controller, Service, Repository의 역할 분리가 왜 중요한지를 체감했다.
  한 번 잘 분리해두니까 이후 기능을 추가하거나 수정할 때도 훨씬 편했다.

• 데이터를 다루면서 JDBC 방식의 장단점도 느꼈다.
  DB 연결 자체가 처음이라 application.properties 설정부터 많이 헤맸고,
  사전캠프 때와 달리 이번에는 java에서 SQL 쿼리를 사용하느라 구글링하면서 하나씩 해나갔다.
  특히 조건에 따라 데이터를 필터링하는 부분이나 테이블 구조를 계속 바꾸는 과정이 쉽지 않았다.
  직접 쿼리를 써야 한다는 점은 좋았지만, 반복적으로 구조가 바뀔 땐 번거로운 점도 있었다.

• 그리고 이번 과제를 하며 API 명세서와 ERD의 중요성도 크게 느꼈다.
  튜터님이 “API 설계와 ERD 작업에 전체 개발 시간의 80%를 쓸 수도 있다”고 하셨는데,그 말이 정말 맞았다 !
  중간중간 막힐 때마다 내가 임의로 정리해둔 API 명세서를 계속 참고하면서
  코드를 짤 수 있었고, 덕분에 시간을 아낄 수 있었다.
  특히 ERD를 처음부터 그려두고 사용하니 Repository 단에서 설계에 집중할 수 있어 훨씬 수월했다.
  물론 이번엔 테이블이 하나라 단순했지만, 앞으로는 테이블이 여러 개로 늘어날 거고,,
  이번처럼 대충 작성해두면 중간에 계속 수정하게 될 것 같다 😂
  앞으로는 요구사항을 정확히 파악하고, 초반에 ERD를 더 꼼꼼히 설계해두면 정말 유용하게 활용할 수 있을 것 같다.