99클럽 코테 스터디 3일차 TIL + 스택/큐(기능개발)

오늘의 과제

프로그래머스 Lv.2 스택/큐로 분류된 기능개발 문제 입니다.

 

전날과 마찬가지로 이미 작년에 풀어본 문제이나 복기 차원에서 다시 풉니다.

 

문제

https://school.programmers.co.kr/learn/courses/30/lessons/42586

프로그래머스

 

 

이전과 마찬가지로 문제의 분류인 "스택/큐"에서 힌트를 얻고 시작합니다.

 

스택은 LIFO(Last In First Out) 구조로 가장 마지막에 입력된 값이 먼저 나오는 구조이며

큐는 FIFO(First In First Out) 구조로 들어간 순서대로 나오는 구조입니다.

 

문제를 읽어보며 스택을 써야할지 큐를 써야할지 판단해보면 되는데

이번 문제에서는 두 번째 단락에서 어떤 자료 구조를 선택해야 할 지에 대한 힌트를 얻을 수 있습니다.

빨리해라!! 줄 길어진다!!

 

"뒤"에 있는 기능은 "앞"에 있는 기능이 끝나야만 한다.

↓

개발이 시작된 순서대로 배포되어야 한다.

↓

먼저 들어간게 나와야 한다.

 

위 예시를 보면 아셨겠듯 시작한 순서대로 배포되어야 하니 자료구조로는 큐가 적당하겠네요.

 

이제 큐를 쓰면 된다는 것은 알았으니 진척률을 체크하고, 배포되는 기능의 수를 카운트 해 봅시다.

 

먼저 문제에서 배포의 조건을 살펴보면 아래와 같습니다.

 

문제의 조건처럼 진척률이 100% 이상이어야만 배포할 수 있다고 하니 조건은 다음과 같이 적을 수 있습니다.

 

현재 진척률 + (하루 최대 개발속도 * 경과일) >= 100

 

이제 큐를 써서 위 조건대로 코드를 짜면 되는데 혹시나 일부 이해가 가지 않는 부분은

아래 주석을 보면 이해가 더욱 쉬울 것 같습니다.

import java.util.*;

class Solution {
    public ArrayList<Integer> solution(int[] progresses, int[] speeds) {
        ArrayList<Integer> answer = new ArrayList<>();
        
        // 1. 힌트는 스택/큐. 즉 둘 중 하나는 쓴다.
        // 2. 뒤에 있는 기능이 먼저 개발되도 앞에 기능이 끝나야 같이 배포된다.
        //    == 먼저 시작한게 먼저 끝나야 한다. == FIFO == Queue
        Queue<Integer> Q = new LinkedList<>();
        for (int i : progresses) Q.add(i);
        // 3. 진척률을 확인하여 배포한다.
        //    진척률 = speeds[idx] + 개발기간
        int idx = 0, days = 1;
        while(!Q.isEmpty()) {
            // 배포되는 기능의 수를 카운트한다.
            int cnt = 0;
            // 진척률이 100% 이상 되어야 배포가 가능하다.
            while(!Q.isEmpty() && Q.peek() + (speeds[idx] * days) >= 100) {
                Q.poll();
                cnt++;
                idx++;
            }
            days++;
            // cnt가 0보다 크다 == 배포된 기능이 하나 이상 존재한다.
            if (cnt > 0) answer.add(cnt);
        }
        return answer;
    }
}

 

배운점

사실 SI라 그런지 모르겠어도 실무에서 Queue를 쓰는 경우가 없었습니다.

 

자료 구조는 기억해도 관련 API를 까먹어서 그런지 내부 반복문의 조건에서

자료를 출력하지 않고 확인만 하는 peek을 까먹고 poll만 하며 맞왜틀? 을 외치고 있었습니다.

 

사실 알고리즘 문제를 떠나 아무리 헤매며(삽질) 고생해서 구현한 기능이나, 오랜 공부를 통해

도입한 기술들도 반복해서 쓰지 않으면 머리에서, 손에서 잊혀지는 것 같습니다.

 

이전에 사내 프레임워크 개발 리딩을 진행하며 Spring Boot + react 를 사용했었습니다.

 

연차에 맞지 않게 과중한 업무가 주어져 취준시절 개발 기억을 다시 상기시키며

고생하며 정말 열심히 만들었던 경험이 있었는데  최근 인프라쪽 프로젝트로 인해

6개월 이상 개발을 놓고 있었습니다.

 

그러던 와중 오늘 고객 요청으로 인해 신규 API 개발하려 Controller 클래스를 열었다가

도저히 Flow가 기억이 나질 않아 이전 진행했던 사내 개발건 repo를 열어

과거의 내가 개발해 놓은 템플릿을 가져다 사용했습니다.

 

잡설이 길었는데 왜 과거 취준시절 대다수의 기업에서 면접 단골 질문과 피드백들이

아래와 같았는지 몸으로 느껴지는 하루였습니다.

 

"업무 외 사이드 프로젝트를 진행한 경험이 있나요?"

"업무 경험은 많은데 좀 더 다양한 토이 프로젝트를 진행해본 경험이 있으면 좋겠어요"

 

네. 그렇습니다. Github의 commit은 지원자의 코딩 역량을 파악할 수도 있지만

"이런걸 해봤어요!" 의 경험도 중요하지만 "지금도 할 수 있어요!" 를 조금 더 중요하게 보는 것 같습니다.

 

 

 

그래서 결론은...

뭐가 되었든 안쓰면 잊혀진다.