230208 TIL (알고리즘, 프로젝트)

알고리즘

올바른 괄호

코딩테스트 연습 - 올바른 괄호

프로그래머스

나의 풀이

문제의 카테고리가 스택/큐로 되어 있는 걸로 보아 스택이나 큐를 사용하여 풀어야 한다는 것을 느꼇는데 다른 방법으로 한번 풀어 보았다. 괄호가 열리는 것을 open에 카운팅하고 닫히는 것을 close에 카운팅 하여 담아준 뒤 둘이 같고, 마지막 괄호가 닫혀 있으면 true를 반환하는 것으로 작성을 해봤다.

class Solution {
    boolean solution(String s) {
        String[] arr = s.split("");
        int open = 0;
        int close = 0;
        for (String ss : arr) {
            if (ss.equals("(")) open++;
            if (ss.equals(")")) close++;
        }
        if (open == close && arr[arr.length - 1].equals(")")) 
            return true;
        else return false;
    }
}

두개의 케이스를 통과하지 못하였고, 원인은 “())(()”등과 같이 둘의 갯수가 일치하고 마지막이 닫히는 것으로 끝났지만, 중간에서 닫히지 않은 경우를 고려하지 못한 것 같았다.

둘로 나누었던 두개의 변수를 하나로 합치고 스택처럼 괄호가 열렸을 경우 1을 더해줘서 stack의 push처럼 구현하였고, 괄호가 닫혔을 경우 1을 차감해줘서 stack의 pop처럼 구현하였다. sum이 0인 경우는 stack이 비어있는 것처럼 아무것도 안하고 중간에서 닫히지 않은 경우를 고려해주려고 pop을 하지 못한 닫히는 개체를 extra에 1을 더해주었다.

class Solution {
    boolean solution(String s) {
        String[] arr = s.split("");
        int sum = 0;
        int extra = 0;
        for (String ss : arr) {
            if (ss.equals("(")) sum++;
            if (ss.equals(")")) {
                if (sum > 0) sum--;
                else extra++;
            }
        }
        if (sum == 0) return true;
        else return false;
    }
}

모든 케이스에서 통과를 하였지만, 효율성 테스트에서 통과하지 못하였다. 많은 시간을 할애하기에 프로젝트 기간이고 하여서 질문하기에 효율성 테스트를 통과하지 못하는 이유를 찾아보았는데, split을 이용하여 String의 배열을 만들어서 반복문을 돌리는 것보다 toCharArray를 사용하여 반복문을 돌리는 것이 빠르다는 것을 알게 되었다.

저번 알고리즘을 풀면서 알게된 방법을 사용하고자 하였으나, 단순히 배열로 만들어 그것을 확인할 목적이면 char 타입이 더 빠르다는 것을 알게 되었고, 적절한 부분에서 사용해야 한다는 것을 깨닫게 되는 계기가 되었다.

class Solution {
    boolean solution(String s) {
        int sum = 0;
        int extra = 0;
        for (char ch : s.toCharArray()) {
            if (ch == '(') sum++;
            if (ch == ')') {
                if (sum > 0) sum--;
                else extra++;
            }
        }
        if (sum == 0 && extra == 0) return true;
        else return false;
    }
}

---

프로젝트

오늘 S.A.문서를 완성할 수 있을 것으로 기대했지만, 생각보다 프로젝트 주제가 복잡하고 관련 기능들이 필요한 요소들이 많아서 ERD를 작성하면 할수록 팀원들 간의 회의가 필요한 부분들이 많아서, 회의와 투표를 통한 결정으로 고민이 필요한 부분들에 대해 작성해 나가면서 오늘 ERD를 완성할 수 있었다. 완성을 했다고 해서 확정된 것은 아닐 것이지만, 일단 S.A.문서 작성과 MVP 기능들을 구현하면서 필요한 테이블들은 얼추 작성이 완료되었다.

S.A.문서에 대한 피드백의 사항들을 추가하고, 피드백에서 언급되었던 유스케이스를 작성하려고 했으나, 지금 단계에서 유스케이스를 작성하는 것은 아니라고 팀원들과 판단이 되어 시퀀스 다이어그램을 작성하려 했지만, S.A.문서의 완성이 늦어질 것 같아서 일단 API 명세서를 작성하면서 전체적인 기능들을 살펴보고 구조적인 것을 나눠보기로 했다.

S.A.문서에 그저 나열되어 있던 기능들을 넘버링 하여 정리하면서, 기능들을 API 명세서에 작성해 나갔다. 오늘 안에 다 할 수 있을 것 같았지만, 시간이 조금 부족하여 내일은 정말로 S.A.문서를 완성할 수 있을 것 같다. 그라운드 룰에 9 to 9을 지키자는 것이 포함되어 있어서 완성을 못했어도 다음 날로 미룰 수 있었고, 덕분에 알고리즘을 풀거나 강의를 듣는 개인 시간도 생긴 것 같다. 프로젝트 막바지에 가도 9 to 9을 지킬 수 있을지 의문이지만, 순탄하게 프로젝트를 마칠 수 있기를 기원한다.

---