[프로그래머스 level 2] 오픈채팅방 - Java

문제

카카오톡 오픈채팅방에서는 친구가 아닌 사람들과 대화를 할 수 있는데, 본래 닉네임이 아닌 가상의 닉네임을 사용하여 채팅방에 들어갈 수 있다.

신입사원인 김크루는 카카오톡 오픈 채팅방을 개설한 사람을 위해, 다양한 사람들이 들어오고, 나가는 것을 지켜볼 수 있는 관리자창을 만들기로 했다. 채팅방에 누군가 들어오면 다음 메시지가 출력된다.

"[닉네임]님이 들어왔습니다."

채팅방에서 누군가 나가면 다음 메시지가 출력된다.

"[닉네임]님이 나갔습니다."

채팅방에서 닉네임을 변경하는 방법은 다음과 같이 두 가지이다.

• 채팅방을 나간 후, 새로운 닉네임으로 다시 들어간다.
• 채팅방에서 닉네임을 변경한다.

닉네임을 변경할 때는 기존에 채팅방에 출력되어 있던 메시지의 닉네임도 전부 변경된다.

예를 들어, 채팅방에 "Muzi"와 "Prodo"라는 닉네임을 사용하는 사람이 순서대로 들어오면 채팅방에는 다음과 같이 메시지가 출력된다.

 

"Muzi님이 들어왔습니다."
"Prodo님이 들어왔습니다."

 

채팅방에 있던 사람이 나가면 채팅방에는 다음과 같이 메시지가 남는다.

 

"Muzi님이 들어왔습니다."
"Prodo님이 들어왔습니다."
"Muzi님이 나갔습니다."

 

Muzi가 나간후 다시 들어올 때, Prodo 라는 닉네임으로 들어올 경우 기존에 채팅방에 남아있던 Muzi도 Prodo로 다음과 같이 변경된다.

 

"Prodo님이 들어왔습니다."
"Prodo님이 들어왔습니다."
"Prodo님이 나갔습니다."
"Prodo님이 들어왔습니다."

 

채팅방은 중복 닉네임을 허용하기 때문에, 현재 채팅방에는 Prodo라는 닉네임을 사용하는 사람이 두 명이 있다. 이제, 채팅방에 두 번째로 들어왔던 Prodo가 Ryan으로 닉네임을 변경하면 채팅방 메시지는 다음과 같이 변경된다.

 

"Prodo님이 들어왔습니다."
"Ryan님이 들어왔습니다."
"Prodo님이 나갔습니다."
"Prodo님이 들어왔습니다."

 

채팅방에 들어오고 나가거나, 닉네임을 변경한 기록이 담긴 문자열 배열 record가 매개변수로 주어질 때, 모든 기록이 처리된 후, 최종적으로 방을 개설한 사람이 보게 되는 메시지를 문자열 배열 형태로 return 하도록 solution 함수를 완성하라.

 

 

제한사항

• record는 다음과 같은 문자열이 담긴 배열이며, 길이는 1 이상 100,000 이하이다.
• 다음은 record에 담긴 문자열에 대한 설명이다.
  • 모든 유저는 [유저 아이디]로 구분한다.
  • [유저 아이디] 사용자가 [닉네임]으로 채팅방에 입장 - "Enter [유저 아이디] [닉네임]" (ex. "Enter uid1234 Muzi")
  • [유저 아이디] 사용자가 채팅방에서 퇴장 - "Leave [유저 아이디]" (ex. "Leave uid1234")
  • [유저 아이디] 사용자가 닉네임을 [닉네임]으로 변경 - "Change [유저 아이디] [닉네임]" (ex. "Change uid1234 Muzi")
  • 첫 단어는 Enter, Leave, Change 중 하나이다.
  • 각 단어는 공백으로 구분되어 있으며, 알파벳 대문자, 소문자, 숫자로만 이루어져있다.
  • 유저 아이디와 닉네임은 알파벳 대문자, 소문자를 구별한다.
  • 유저 아이디와 닉네임의 길이는 1 이상 10 이하이다.
  • 채팅방에서 나간 유저가 닉네임을 변경하는 등 잘못 된 입력은 주어지지 않는다.

 

 

문제풀이

• 오픈채팅방은 가장 최근의 닉네임 변경값을 모든 채팅방 메세지에 반영한다.
• 따라서 각 회원의 가장 최근 닉네임 변경값을 알면 문제를 쉽게 풀 수 있다.
• 이를 위해 sortMap을 정의하여 각각의 회원의 모든 메세지를 담았다.
• 이후 sortMap을 조회하여 각 회원의 가장 최근의 닉네임 변경값을 구해 nicknameMap에 넣었다.
• 각 회원의 가장 최근 변경 닉네임값을 얻었으니, myMessageResolver라는 메소드를 만들어 최종적인 메세지를 생성하였다.
• 이후 생성된 최종 메세지를 답안으로 제출

 

import java.util.*;

public class OpenChat {

    private final Map<String, ArrayList<String>> sortMap = new HashMap<>();
    private final Map<String, String> nicknameMap = new HashMap<>();

    public List<String> solution(String[] record) {

        getNicknameMap(record);
        return myMessageResolver(record);
    }

    private List<String> myMessageResolver(String[] record) {
        List<String> answer = new ArrayList<>();
        for (String r : record) {
            String username = r.split(" ")[1];
            String userNickname = nicknameMap.get(r.split(" ")[1]);

            String command = r.split(" ")[0];
            switch (command) {
                case "Enter":
                    command = "들어왔습니다.";
                    break;
                case "Leave":
                    command = "나갔습니다.";
            }

            if (!command.equals("Change")) {
                answer.add(userNickname + "님이 " + command);
            }
        }
        return answer;
    }

    private void getNicknameMap(String[] record) {
        for (String r : record) {
            String username = r.split(" ")[1];
            if (sortMap.get(username) == null) {
                sortMap.put(username, new ArrayList<>());
            }
            sortMap.get(username).add(r);
        }

        for (ArrayList<String> value : sortMap.values()) {
            for (int i = value.size() - 1; i > -1; i--) {
                String target = value.get(i);
                String command = target.split(" ")[0];

                if (!command.equals("Leave")) {
                    nicknameMap.put(target.split(" ")[1], target.split(" ")[2]);
                    break;
                }
            }
        }
    }
}

 

 

느낀 점

문제를 풀면서 테스트코드는 맞았는데 본 문제에서 런타임 에러가 나는 경우가 있었다. 나중에 알고 보니 Leave 메세지에는 split 배열의 3번째 값이 존재하지 않는다는 것을 알게 되었다.

 

• ex. "Enter user1234 Ryan" / "Leave user1234"

 

문제는 코드에는 Leave 메세지에 대해서도 3번째 배열 값을 구하는 로직이 있었는데, 실제 Leave 메세지에는 3번째 값이 없으니 런타임에러가 발생했던 것!

 

컴파일 오류는 코드를 작성하는 시기에 컴파일러가 검출해서 에러를 알려주니 개발자가 코드를 작성할 때 조치를 취할 수 있지만 위와 같은 런타임 에러는 대응하기가 매우 어렵다는 것을 알게 되었다. 만약 실제 서비스를 런칭하였는데 고려하지 않은 경우의 수로 인해 런타임 에러가 발생해 서버가 죽어버리는 상황이 발생한다면? 생각만해도 끔찍한 것! 고강도의 테스트를 두려워하지 않는 자세가 필요할 것 같다. (그러나 고강도의 테스트는 늘 너무 무섭다............)