[WIL] 7월 2주차

이번주도 크게 3가지의 카테고리를 병행하며 공부했습니다.
진행이 잘 됐던 날도 있고, 아쉬웠던 날도 있었지만, 제때에 이 글을 작성할 수 있는걸 보면 제법 잘 살아갔던 한 주라고 생각하겠습니다 ㅎ

알고리즘

현재 알고리즘 공부는 Github tony9402 님의 저장소 에서 부족하다 생각하는 카테고리를 풀고 있습니다.

지난주는 이분탐색을 위주로 풀었다면, 이번주는 이분탐색을 좀 더 진행하고, 중반부터는 그리디를 풀기 시작했습니다.

처음 그리디를 접했을때는 도대체 그리디적 사고가 무엇일까 고민이 많았고, 백준 실버 수준의 문제에서도 많은 난항을 겪었는데, 지금은 어느정도 풀이에 감이 잡힌것 같습니다.

개인적으로 같은 난이도였지만 유독 어려웠던 문제가 있었습니다.

• 그리디
  • 백준 - 13305 주유소
  • 내 풀이 - GitHub
  • 노션 정리

• 이분탐색, 파라메트릭 서치
  • 백준 - 1300 K번째 수
  • 내 풀이 - GitHub
  • 노션 정리

[주유소]

// <초기 생각>
 1. 현재 주요소와 다음 주유소의 리터당 가격을 비교한다.
        - 현재 주유소가 더 비싸다면, 현재 주유소에서 다음 주유소로 갈 수 있는 금액만 구매
        - 현재 주요소가 더 싸다면, 다음 주유소에서 다음 다음 주유소로 갈 수 있는 금액까지 구매하고,
          또 그 다음다음다음 주유소와도 비교한다(반복문) 그러다가 비싼 주유소를 만나면 정지
          여기서 바깥 for문의 인덱스를 현재 for문에서 탐색한 인덱스로 교체해줘야 함
          
// <실제 필요했던 접근법>
       - 위의 말이 결국 각 주유소의 리터당 기름값이 내림차순이면 그대로 구매하지만 그렇지 않은경우
         직전도시에서 기름을구매하면 된다.
         주유소 가격이 8 9 7 10 2 3 -> 8 8 7 7 2 2로 가격을 책정하고 거리값을 곱하면 된다.

위의 주석의 첫번째 문단은 문제를 풀기 전 직접 분석했던 문제 풀이 방식입니다.
문제를 풀 수 있는 원리는 생각했으나 그것을 구현한 로직을 너무 복잡하게 생각하여 풀지못했습니다.

두번째 문단을 보면, 단순히 내림차순 배열로 만들어주면 되는 부분을 이중 for문까지 가지고 오게 된 이유가 무엇일까 생각해볼 수 있던 문제였습니다.

PS를 하면서 많이 접했던 말이 빠른 시간안에 짤 수 없는 방향으로 생각을 했기 때문에 코드가 빠르게 완성되지 못한다 는 말이었다. 이 문제를 풀면서 크게 느낄 수 있었다.

다음주도 그리디를 조금 더 공부해보고, 다른 알고리즘 공부로 넘어가야겠습니다..!

[k번째 수]
대표적인 파라메트릭 서치 문제 중 하나였던것 같고, 문제의 설명에 비해 이해하는데 상당히 많은 시간이 걸렸던 문제였습니다. 파라메트릭 서치에서 가장 우선적으로 해야할 부분은, 결정문제를 찾는 일인데 이 문제에선 결정문제를 어떻게 찾아야 할 지 감이 잡히지 않았습니다.

풀이를 봤을때도 오랜시간동안 명쾌하게 이해가 되지 않았던 문제는 오랜만이어서 많이 당황하기도 했습니다만..
이해를 하고 문제를 다시 살펴보니, 이런 유형의 경험치가 많이 부족하다는 생각이 듭니다.

스프링 MVC

인프런 김영한님의 스프링 MVC 1편을 마지막 챕터인 웹 페이지 만들기를 수강하고 있습니다.

스프링 MVC 앞부분에서 배웠던 개념들을 토대로 간단한 웹 페이지를 만드는 과정입니다.
개념이란것이 뒤돌아보면 금방 잊어지는 느낌이 들어, 역시 가장 좋은것은 무엇을 만들면서 자신의 것으로 만드는게 제일이구나 라는 생각도 들었던 한 주 였습니다.

강의를 수강하며 정답 코드를 보기전에 직접 고민해보고 스스로 먼저 로직을 작성하고, 확인하는 방식으로 들었는데, 시간은 조금 오래 걸리지만 조금 더 제것이 되는것 같아 좋았습니다.

또, 라이브 스터디에서 JUnit5를 공부하며 느꼈던, 모든 정보는 공식문서에 있구나를 실감해서 개인의 블로그 보단, Spring Docs에서 최대한 정보를 찾으려는 노력을 했습니다. 처음에는 어떤 키워드로 찾아야할지 감도 잡지 못했지만, 지금은 많이 발전한것 같습니다!

그럼에도 가장 어려웠던것은 영어의 장벽.. 이었습니다. 거의 영포자였던 저는.. 문서를 볼때마다 아 영어권의 사람이었으면.. 하고 한탄하며, 열심히 파파고를 돌렸습니다 ㅎㅎ ㅜ

자주보는 단어는 적어놓고 외우는 습관도 가지고 있다면 정말 많은 도움이 될것같아 조만간에 시도해보려 합니다!

라이브 스터디 Week04 - 제어문

스터디라 읽고.. 과제 폭탄의 한 주 였다..
개인적으로 지금까지 진행하면 가장 많은 것을 얻었던 스터디라 생각됩니다.

공식문서는 만능이다!

JUnit5를 학습하는 과제가 있었습니다. 과거 존경하는 개발자의 말을 빌려오자면 모든 정답은 공식문서에 있다는 말을 듣고, JUnit5의 공식문서를 살펴보았습니다.

영어라는 큰 장벽이 있었지만, 적응을 하고나니 사람들이 설명하는 글은 공식문서의 범주에서 크게 벗어나지 않는다는 점을 느꼈습니다.

나는 아직 자바를 모른다.

조금 슬픈 주제입니다.. 자바 공부 열심히 했다고 자부했지만, 간단한 과제겠거니 하고 시작했던 과제들에서 좌절했던 부분들이 많았습니다.

• 대쉬보드 만들기

  • 이 부분에선 실제 과제와 크게 관련없는 부분에서 아주아주 많은 시간을 날리는 삽질을 했습니다.
  • 첫번째 삽질은 OAuth 토큰을 이용해 시간당 60번의 API 호출 제한을 5000번까지 늘리는 과정이었는데, 이상하게 GIT Bash에선 암호를 입력하는 화면이 나오지 않아 cmd를 이용했습니다.
  • 두번째는 Java Docs에서 원하는 키워드를 찾는 과정이었는데, 이슈 목록을 가져오고, 각 이슈 목록의 댓글, 사용자를 모두 조회해야 했었기에 각각에 맞는 클래스와 메소드를 찾는데에서 삽질을 경험했습니다.

• ListNode 만들기

  • 간단하게 할 수 있겠지 하고 접근했지만, 선장님이 조건을 거신
    ListNode add(ListNode head, ListNode nodeToAdd, int position)이 부분에서 전체적인 LinkedList를 어떻게 구현해야 될지 감을 잡는데 시간이 걸렸습니다.

  • 특정 ListNode 객체가 이 메소드를 실행할때 리스트의 맨 앞인 head를 넘겨주고, 추가할 노드와 위치를 받는데 그렇다면 이 메소드를 실행하는 주체는 어떤 ListNode 모두 가능해야 하는지, 혹은 head만 실행할 수 있게 제약을 걸어야 하는지가 가장 헷갈렸던것 같습니다.

  • 이를 해결하는데 가장 큰 도움이 됐던것은 실제 내가 구현하려는 형태를 그림으로 도식화하고, 규칙을 정했던것이 가장 컸던것 같습니다.

정리

개발자의 실력은 삽질을 해온 시간과 비례한다는 말을 오랜만에 다시금 체험할 수 있었던 한 주였습니다 ㅎㅎ
확실히 삽질을 하던 문제를 해결하면, 어떤것도 해결할 수 있겠다는 자신감이 생기지만, 또다른 삽질이 그 자신감을 무너뜨리기도 하는데요.. 그게 개발자라는 직업의 숙명이자 매력이지 않을까 조심스럽게 생각해봅니다..