프로그래머스 프론트엔드 데브 코스 프론트엔드 과정의 기록입니다.
원래 메소드 체이닝에 관하여 코드를 작성하는 것을 별로 선호하지 않았었다. 그러나 오늘 강의 코드와 나의 코드를 비교해보며 적절한 메소드 체이닝을 하여 고차함수를 잘 활용하는 코드를 보며 남의 코드를 이해하는 능력을 키우는데에는 여러 경우의 코드 스타일이 보는게 도움이 되겠다고 생각하게 되었다.
flatMap 메소드에 알게 되었다. map 함수와 함께 활용하면 배열의 평탄화 작업 결과를 잘 도출할 수 있겠다.
이 문제의 경우 특정 값을 찾는 문제가 아니라 특정 조건을 만족하는 경우의 최솟값을 도출하는 문제 유형이다. 흔히 이런 유형의 문제들을 결정 문제로 분류한다.
결정 문제의 유형에 이분 탐색을 통해 문제를 해결해 나가는 것을 파라메트릭 서치라고 부르는데 이 개념에 대해서 이해할 수 있어서 좋았다.
JavaScript에서 큐를 클래스로 직접 구현하여 큐를 활용한 경우와, 클래스가 아닌 배열로 큐를 활용한 경우의 시간을 비교해보았는데 클래스로 큐를 활용한 경우에 시간복잡도가 좀 더 유리했다.
문제에서의 요소가 적었기에 시간복잡도가 조금만 유리했던 것 같다. 문제의 요소의 수가 많아 진다면 배열로 큐를 활용하는 경우에 shift() 메소드를 많이 사용하여 큐 재정비 시간이 늘어나므로 시간복잡도가 불리해 질 것이다. 주어진 문제에 대한 조건을 적절히 활용하여 자료구조를 선택하는 것이 중요하다고 다시 한 번 생각하게 되었다.
shift() 메소드의 경우 자바스크립트 엔진에서 요소의 개수가 적을 경우 최적화를 해준다는 사실을 처음 알았다.
개인적으로 나는 그리디 알고리즘 유형이 다른 유형들보다 좀 어렵게 느껴지는 것 같다. 하지만 오늘 강의를 통해 입력값에 따른 문제 해결 유형의 선택법에 대하여 고민해본 결과 문제들의 해결법이 명확하게 보이는 것을 느꼈다.
그리디 알고리즘의 경우 입력값이 큰 경우의 문제들을 해결할 때 사용되는 경우가 많으며 그 때는 직관적인 방법을 고민해보며 풀어보자.
개인적으로 오늘은 깨달은게 너무나도 많았던 하루이다. 내가 해왔던 코딩테스트 문제 풀이 방법들을 되돌아보며 생각해보면 막상 외우기식의 방법들이 여기저기 포함되어 있는 것 같다.
강사님이 작성한 코드에 왜? 라는 질문을 던질 경우 그 상황에 적합한 자료구조들과 알고리즘을 선택하여 문제를 해결해나가는 것을 보고 이게 진정한 코딩테스트에서 바라는 문제 해결 능력이 아닐까? 라는 생각을 하게 되었다.
나의 코드에 왜? 라는 질문을 던졌을 때 적합한 답변이 떠오르지 않는 코드들이 많았다. 정말 좋은 공부법에 대하여 알게 된 하루이다. 내 생각을 표현한 코드에 질문을 스스로 던져보자. 내 질문에 대한 답변만으로도 충분한 공부가 될 것 이다.
멘토님이 하신 이야기 중에 T자형 경험의 빈도를 늘리려고 노력해야 한다라는 말이 인상적이였다. T 모양 처럼 단단한 기반을 다져 놓고 더 깊게 문제를 해결하려고 시도하며 노력하는 경험이 중요하다는 이야기였다.
처음에 나로써는 그 깊이에 대하여 감이 잡히지 않았었다. 그래서 멘토링이 끝나고 멘토님께 깊이있는 경험에 대하여 질문을 하였고 어려운 이야기를 천천히 들려주셨다.
내가 개발을 진행하였을 때 문제를 직면하는 경우에서 해결법을 모르는 경우에 더 많은 자료들을 보고 공부하면서 직면하는 문제들을 차츰차츰 해결하여 나가는 과정에서의 경험으로 나는 이해하였고 그 문제들을 더 심화되게 직면해나간다면 깊이 있는 T자 경험을 할 수 있겠다 라는 생각을 하게 되었다.
돌아보며 생각해보면 내가 개발을 하면서 문제에 직면하지 않는다면 그게 더 이상하다라는 생각이 들었다. 수 많은 개발자들이 문제에 직면하여 끊임없이 고민하는데 나 역시 그들과 동일한 문제에 같이 고민을 하려면 그 수준까지 능력을 올려야 된다고 동기부여가 되었다.
CS 스터디 모임에서 내가 담당한 주제 발표하기
Programmers Web Devcourse 1주차 학습 내용 전체 복습 및 포스팅 하기