[WIL] 7월 4주차

토이 프로젝트 MLB

7월 3주차때 요구 사항 분석 및 트랜잭션 분석을 마치고, 4주차 부터는 본격적인 설계를 하기 시작했습니다.

• 개념적 설계: ERD, 트랜잭션 모델링
• 논리적 설계: 릴레이션 스키마
• 물리적 설계: 내부 스키마

이후 DB 개설까지 완료했습니다.
혼자서 진행하는 토이 프로젝트이다 보니 React나 Vue 같은 CSR 기술이 아닌 타임리프를 통해 진행되는 SSR로 진행하기 때문에 기본적으로 화면을 직접 구성하기 위해 부트스트랩을 이용한 화면을 만들어서 진행했습니다.

여기까지는 무난했으나, MyBatis를 이번에 처음 프로젝트에 적용해 보았기 때문에 연동 테스트를 진행하던 도중 문제가 발생했습니다.

1. Controller에서 DAO 객체를 찾을 수 없어 NPE의 발생

   • 오류 발생 경위
     프로젝트에선 편의를 위해 Lombok을 사용하고 있었습니다. 따라서 DAO 구현체를 Lombok의 Annotation인 @RequiredArgsConstructor를 이용해 자동으로 주입하는데 NPE 발생
   • 원인
     해당 어노테이션은 field에 반드시 final 키워드를 붙여줘야 하는데 붙여주지 않아 NPE가 발생했습니다. 단순한 실수였지만, 내가 공부를 헛되게 한 건 아닌지 약간의 아쉬움이 남았던 삽질이었습니다..

2. FileNotFoundException

   • 오류 발생 경위
     Spring Boot로 MyBatis의 초기 Mapper 경로와, mybatis-config.xml을 설정하는 MySQLConfig 클래스를 작성하고 실행하는 과정에서 오류가 발생했습니다.
   • 원인
     Spring의 PathMatchingResourcePatternResolver 사용하며 classpath에서 Mapper의 경로를 등록하는데 getResource() 메소드와 getResources() 메소드를 혼돈하여 발생했습니다. getResource() 메소드는 파일의 직접적인 이름을 매개변수로 넘겨주어야 하고, 후자는 경로와 대략적인 파일의 형태들을(ant style pattern) 매개변수로 넘겨주어야 합니다.
     저의 경우 경로와 대략적인 파일의 형태인 classpath:mappers/*.xml를 getResource() 메소드를 이용해 넘기며 당연하게도 오류가 발생했습니다.

위의 두 삽질의 경우 너무너무 단순하고 간단한 오류였지만, 다시한번 기본의 중요성을 깨닫게 해주는 것 같습니다. 계속 프로젝트를 진행하며 또 어떤 삽질이 있을까 두렵기도 하지만, 많은 삽질이 있어야 성장할 수 있다는 믿음이 있기에 기대되기도 합니다!

Problem Solving(백준)

4주차도 그리디 및 BFS, 이분탐색 관련문제를 풀었는데 거의 대부분의 문제들에서 어려움을 느끼고 풀이를 참고하거나 원리를 참고하여 풀었던것 같습니다.

특히 골드 급의 그리디 문제는 거의 풀지 못했던 경우가 많았습니다. 왜 풀지 못했을까..? 풀이를 보면 이해가 가지만 정작 다른 문제를 풀때면 그리디적인 사고가 많이 부족한것 같아서 아쉬웠습니다.

더하여 오늘의 문제를 추천받아서 풀 수 있는 저장소를 이용해 유형을 보지 않고 풀어보기도 했습니다.
이 부분이 이번주 알고리즘을 풀면서 가장 좋았던 부분이기도 했는데, 유형을 보지 않고 알고리즘 문제를 푼다는 것 자체가 꽤나 체계적인 사고를 요하는것 같았습니다. 지금까지는 특정 문제집에서 문제를 풀었고, 해당 유형이 어떤것인지 알고 풀었습니다.

이것의 가장 큰 단점은 모든 코딩테스트는 문제의 유형을 알려주지 않는다는 겁니다.
따라서 유형을 모르고 문제를 정리해가며 해당 문제의 조건과 알맞은 알고리즘을 선택할 수 있는 능력을 기르는것이 가장 중요한데 이 부분을 조금이나마 그런 연습할 수 있어서 아주아주 좋았습니다!!

인프런 강의 수강

타임리프의 기본 기능에 대해 학습했습니다.
확실히 JSP와 달리 내츄럴 템플릿의 장점들을 느낄 수 있었습니다만, 이 문법을 전부 외우는 것은 무리라는 생각도 들었습니다.

다시한번 필요한걸 찾아서 사용할 수 있는 능력을 기르는것이 정말 중요하겠다는 생각이 들었습니다.

라이브 스터디

상속과 관련된 공부를 진행했습니다!
조금 부끄럽지만 Dynamic Mehod Dispatch라는 부분을 처음 알게 되었습니다.
완전히 몰랐던 것은 아니고, 저런 동적 디스패치 현상을 동적 바인딩 이라는 용어로 알고 있었습니다.

동적 바인딩과 동적 메소드 디스패치는 약간의 차이를 보이는데 아래 게시물에서 그것을 확인할 수 있었다.
Differences between Dynamic Dispatch and Dynamic Binding
결과적으로 두 개의 용어는 동일 하다 생각할 수 있으나

• 동적 바인딩은 메소드가 특정 인스턴스(또는 인스턴스 클래스)에 "바인딩"되어 있다는 개념으로, 이를 식별하는 방법
• 동적 디스패치의 아이디어는 실제로 호출할 메서드 또는 호출할 객체를 보기 위해 함수 포인터를 따르는 것이다.

위와 같이 약간의 차이를 보입니다. 따라서 위키 백과에서는 이를 동일하게 취급하기도 합니다.