일정표를 만들어 보자!

트러블 슈팅

1. 배경

• 드디어 웹 개발의 기초에 입문하였다.
• 사용 기술은 spring, jsp, jdbc, mysql이다.
• 웹 개발의 기초를 위한 일정표를 만드는 발제를 진행하였다.

2. 발단

• 처음부터 끝까지 문제가 상당히 많았다.
• 데이터의 타입 정의는 문제가 없었다
• 예외처리에서 예외처리가 무한으로 재귀되는 문제가 있어 확인해 보았다.
• 매핑 형식에 대한 오류가 등장하였다.
• 데이터 로드 형식, 범위에 대한 문제가 발생하였다.
• SQL문의 경우 오랜만에 사용하다보니, 조금 익숙한 감이 떨어졌다.

3. 전개&위기

1. Service

• 이 파트는 단순히 클라이언트의 요청을 처리하는 파트였어서 큰 문제는 없었다.
• 다만 지금 보니 파일이나 폴더명이 service로 되어있어야했다.

2. exception

• 위와 같이 대분의 오류를 판단하고 메시지 형태로 페이지에 띄우는 코드를 작성했다.
• 다만 여기서 문제가 있었던 것이, 맨 처음에는 페이지로 연동을 안 시켜주어서 에러를 띄우기 시작하였다.

3. controller

• 여기 파트의 경우 데이터를 불러오고 처리하는 직접적인 메인에 가까운 코드였다.
• 여기서는 다양한 문제가 발생하였는데, 데이터를 외래키를 사용하기 위해 테이블을 2개로 나누고나니, 요청에서 문제가 다수 발생하였다.
• 그 이외에도 post,get만 사용하였지만 다양한 방식을 사용하지 못했다는 점도 문제로 잡혔다.
• 가장 큰 문제는 사실 위의 문제보다는 2개가 나타났었다
• 하나는, 그저 시연에 있던 코드를 정확히 이해하지 못하고 치기만 했다는 점에서 이해가 부족해 보인다.
• 둘, 여기는 서버라서 그런건지 인터럽트가 안걸린다. 이게 엄청난 시간을 딜레이 시킨 요인이 되기 시작했다.

4. repository

• 데이터를 불러오는 형식이나 양, 직접적인 jdbc를 이용한 sql문 처리를 담당했다.
• 여기서 가장 큰 문제는 sql일것이라 생각했으나, 이미 해본 적이 있던 부분이라 차라리 할만했다.
• 오히려 외래키가 들어오고 나서 부터 생기는 join 문제가 발목을 잡았다.
• 가장 큰 문제였던 점은, mysql에서는 직접 데이터를 불러오고 삭제하지만 여기서는 다른 java코드에서 요청하다보니 정확히 어디서 요청하고 어디서 문제가 난 것인지 몰랐다는 점이 너무 시간을 잡아먹었다.

• 여기는 딱히 막히는 부분은 없었지만, 저 위의 태그의 사용방식을 정확히 알지 못한게 좀 시간을 잡아먹었다.

5. 절정

1. controller

• 처음에는 잘 몰랐지만, 하면서 controller의 역활은 생각보다 복잡하면서도 명확하다는 것을 파악할 수 있었다.
• 우선 필요한 데이터를 수집하고, 데이터를 통해 문제를 처리한다. 혹시모를 예외를 처리하면서 다른 코드와 가장 밀접하게 많이 연동되는 곳이라는 것을 파악할 수 있었다.
• 과제의 내용에 외래키를 꼭 사용하는 것이 포함되어 있었다보니, 원래의 코드를 수정하여 postRepository를 2가지 테이블에 같이 걸어 데이터를 제공받는 코드로 작성하였다.
• 예외는 exception 테이블에 있는 GlobalExceptionHandler에서 처리할 수 있도록 예외를 해당 클래스와 연동된 페이지로 페이지 이동을 걸어두었다.
• 모든 클래스는 요청하는 것이 어떤 데이터인지 형식인지의 차이는 있었지만 위의 형태를 유지하도록 코드를 구성했다.

 

2. repository

• 여기서는 조인외에는 거의 다 데이터베이스 자체적인 오류로 인해 문제가 많이 발생하였다.
• 외래키를 첨가하고 나서부터, user_id라는 외래키를 직접 입력을 받는 형식을 처음에는 사용하였으나,
• 사실 옆 테이블의 기본키라는 것을 깨닫고 그냥 옆에서 데이터를 불러오는 형식으로 바꾸려 했더니 기존 코드와 충돌이 어마무시하게 일어났다.
• user_id가 입력이 안되어서 무결성 오류로 데이터가 저장이 안되는 경우부터, 데이터가 한 테이블만 저장되고 다른 테이블에는 외래키로 인해 저장이 안되는 등 여러 문제가 있었다.
• 결론적으로 대부분 외래키에 대한 무결성 보존 오류였다. 이 점은 항상 주의하는 수 밖에 없을 것 같다.

 

3. exception

• 여기서 의존성 문제가 가장 많이 등장했던 것 같다. 
• 다만 이 부분은 코딩적인 문제라기보단, 지식의 문제라 많이 하다보면 괜찮을 것 같다.

 

6. 결말

• 이번 코드에서 걱정했던 클린 코드의 문제가 조금씩 드러나고 있는 것 같다.
• DB,서버,클라 이렇게 3개가 통신하다보니 더 코드가 복잡하고 읽어내기 힘들었다고 생각한다.
• 왜 사람들이 폴더를 정확히 나눠서 코드를 짜라는지 알 수 있었고 앞으로도 처음부터 잘 배치하는 것을 목표로 해야할 것 같다는 생각이 들었다.
• 이번 코드하면서 테스트를 하면서 하진 않았다. 다만, 서버의 경우 반드시 테스트를 통해서 점검을 해야하는 점을 생각하면 추후 반드시 한번은 해봐야겠다.
• 위의 에러들이 가장 알기 어려웠지만, 지금와서 보면 체계를 잘 잡는게 중요한 것 같다.
• 웹 개발의 로드맵을 머리에 저장해 두면 앞으로 이런 문제는 좀 덜 생길 것 같다.
• 하면서 가장 어려웠던게 어디서부터 어떤 순서로 만들어야하는지 감이 전혀 안왔기 때문이다.
• 각 프로그램들이 하는 일에 대한 정의가 머리에서 흐릿하게만 떠올라서 배치하는 것 조차 어려웠기 때문이다.
• 그리고 다양한 개념이 갑자기 쓰이다보니, 또 머리속에서 개념이 흔들리고 있다. 이 부분도 함께 채워야할 것 같다.