[알고리즘] SW B형 문제 풀이에 있어서의 나의 문제점과 해결방안

지금 문제를 풀 때의 문제는 디버깅하는데 애를 먹고 있다는 점이다. 

디버깅이 힘든 이유를 생각해보면 다음과 같다.

 

1. 코드가 길어진다. 

코드가 길어지기 때문에 어느 한 부분에서 난 오류를 찾아내기가 더 힘들어진다. 

 

2. 중복 코드가 있다.

중복 코드가 있기 때문에 하나를 바꾸면 똑같은 코드도 모두 바꿔주어야 하는데 여기서 실수를 할 가능성이 생긴다.

 

3. 주석이 없다.

코드가 길고 복잡한데 이게 뭐 하는지 기억력에 한계가 있기 때문에 디버깅을 하는 속도가 지연될 수 밖에 없다.

 

4. 어디서부터 시작해야할지 모르겠다.

틀린 이유를 아예 모르는 것이다. 경험상 이는 논리가 틀렸거나 코드에 오타가 있거나 문제 조건을 빼먹었거나 구현을 잘못했거나 중 하나이었다. 

 

5. print로 찍어보기가 어렵다. 객체의 크기가 너무 크거나 메서드가 return하는 값이 없을때 어떻게 찍어야할지 감이 안온다.

 

해결책을 생각해보면 다음과 같다.

1. 코드를 되도록이면 짧게 짧고 이해하기 쉽게 짜자. 스파게티 코드가 되는 걸 방지하자. 
2. 중복 코드를 함수로 만들어버리자.
3. 주석을 달자. 조금 시간이 걸리더라도 적는게 안적었을때보다 무조건 효율적이다.
4. 매뉴얼을 만들자.

 

 

어디서부터 디버깅을 어떻게 시작해야할지 모르겠을때(Runtime Error는 다 잡았다는 가정하에)

다음의 경우 중 하나로 틀린 것이다.

1. 논리가 틀렸다.
2. 코드에 오타가 있다.
3. 문제 조건을 빼먹었다.
4. 구현을 잘못했다

-> 매뉴얼

1. 첫번째 테스트케이스만 가져와서 돌려보자. 이때 return이 있는 메서드라면 각각을 print로 찍어서 예시값과 동일한지 비교해보자.
2. 주석을 달아보며 논리를 재점검해보자. 이를 통해 오타와 구현을 잡자.
3. 논리가 맞는데 안된다면 문제를 다시 보자. 이를 통해 빠진 조건을 챙기자.
4. 문제 조건을 봐도 맞는데 안된다면 코드를 리팩토링하자. 알기 쉽게 다시 짜자. 분명 이상한데서 오타가 났을것이다. 그렇다면 그냥 코드를 읽는 것만으로는 찾기 힘들다. 각 변수가 어떤 건지 명확히 적어보자. 또한 이걸 왜 이렇게 했는지 하나부터 의심해보자. 그러지 않으면 찾을 수 없다.
5. 그래도 못찾겠으면 디버깅툴과 print를 이용해서 각 과정에 대한 예상 정답을 만들고 해보자.(이런 일은 없어야 한다. 지푸라기라도 잡는 심정으로 해야하는 작업이기 때문이다.)

 

또 하나의 문제는 설계를 하는 과정이 효율적이지 못하다는 것이다. 논리적인 과정에 따라 진행된다기 보다는 생각을 얕게 해보다가 안되면 넘겼다가 다시 넘어오는 식으로 확실하게 매듭짓지 않아 오버헤드가 발생하는 것 같다. 

이에 대해 시간 복잡도를 확실하게 계산할 필요가 있어보인다.

또한 여러 자료구조를 잘 조합하는 방법도 필요해보인다.

1. O(n)을 O(logn)으로 바꿀 수 있는 것을 고민해보자. 예를 들어, 정렬된 리스트에서는 이분탐색을 활용하면 탐색을 logn으로 할 수 있다. 또한 TreeSet은 원소가 있는지 찾는 과정이 O(logn)이다. 이렇듯 logn으로 바꿔야 하는 문제가 자주 나왔다.
2. 상태가 바뀌는 것은 따로 객체로 만들어서 보관하고 외부에서는 이를 참조만 하도록 하자. 예를 들어, A라는 객체는 A에 대해서만 상태를 보관하고 변경하는 것이다. 그러면 B라는 객체는 A를 통하지 않고 객체의 상태를 변경하면 안되는 것이다. 그리고 관리는 관리하는 객체를 따로 만들어 A와 B의 상호작용을 관리한다.
3. 웬만해서는 있는 자료구조를 활용하자. 이때 어떤 자료구조가 적절한지를 잘 생각하자. (ex) 해시맵보다는 배열이 빠르다. 굳이 배열로 구현할 수 있는 것을 해시맵으로 구현하지 말자.
4. O(logn)와 O(1)은 n이 커지면 커질수록 꽤 체감이 난다. 특히, O(nlogn)과 O(n)의 경우 이 logn의 차이가 통과를 하냐 못하냐의 차이를 만들어낸다.