[알고리즘] How do you improve? 문제 해결 접근법

알고리즘 풀이를 나름 해왔지만, 

알고리즘 공부는 따로 해본적이 없다. 

 

그래서 지금 1단계 후반으로 넘어가는 시점에서 알고리즘을 제대로 푸는 법을 (지금이라도)

배워보기로 했다.

 

1단계. 문제 이해하기

1.  문제를 나만의 언어로 표현할 수 있는가? 

2. 어떤 자료가 들어오는가?

3. 도출되어야 결과는 무엇인가? (출력 값이 어떻게 나와야 하는가)

4. 문제를 해결할 충분한 정보가 주어졌는가? (주어진 데이터만 가지고 원하는 값을 출력할 수 있는가)

5. 문제의 일부인 데이터의 중요한 부분에 어떻게 라벨을 지정할 수 있는가 => 문제에서 정말 중요한 것이 무엇인가

 

실제로 문제를 파악했다면, 

예시를 1-2개 만들어보기. 

쉬운 예시 -> 복잡한 예시

Empty inputs, Invaild inputs 에 대한 고민은 해결 능력을 길러줄 수 있다.

 

 

문제 파악이 문제를 그냥 푸는 것보다 훨씬 중요하다고 한다.

 

 

Break it Down 문제를 세분화 하기.

- 해결책의 기본적인 구성요소만 작성하면 됨. -> 코드를 실제로 입력하기 전에 한 번 더 생각해볼 수 있게 해줌.

- 대충 이해한 부분을 파악하거나, 이해할 수 있게 해줌. 

- 단계를 작성한다는 건, 방법을 확신하지 못해도 수행할 작업을 알고 있다는 의미가 된다. 

=> 적어도 접근 방법을 공식화 한다는 것을 면접관에세 보여줄 수 있는 것. (방향성이나 기본은 어필할 수 있음)

(답을 도출하지 못한 사람들도 합격하는 것을 많이 보았다고 함)

 

 

문제가 잘 풀릴 때도 있지만, 

80%도만 확신이 있거나, 정말 어려운 한두가지가 남아 있을 수 있다.

그럴 땐 '단순화 하기' 를 떠올려야 한다.

 

해결할 수 있는 건 해결하고, 

해결 못하는건 더 단순화 해야한다.

=> 모든것에 집중하기 위해 시간이 많이 소요되는 부분을 무시해야 한다.

 

1. 면접에서 문제를 모두 몰아넣고 해결을 못한느건 좋은 모습이 아니다.

설령 가로막는 어려운 부분이 있더라도, 

해당 부분을 다시 통합해야 한다는 것을 염두에 두고

가능한 작업을 수행하기 위해 코드를 작성하는 편이 훨씬 낫다.

 

2. 보통 문제를 단순화 하는 과정에서 실제 해결책을 깊이 이해하고 문제의 어려운 부분을 파악하면서 점점 해결된다.

 

즉, 어려운 부분보다 해결할 수 있는 부분 먼저 단순화해서 해결해보고, 

그 다음에 어려운 부분을 가능하면 다시 통합시키는 것. 

그리고 그렇게 단순화 시키는 단계에서 어려운 부분이 어떻게 작동하는지 이해하게 된다. 

 

 

 

이제 얻은 해결책을 좋든 형편없든 되돌아보고 Refactor 해야한다.

귀찮아도 시간을 내서 코드를 살펴보고, 되돌아보고, 성찰해야한다.

-> 각 구성요소를 한 줄씩 살펴보면서 마음에 들지 않는 부분이나, 

코드의 형태, 해석 방법, 이해하기 쉬운지에 대해 살펴보기. 

대부분의 사람들이 중요하게 생각하는 것은 코드를 볼 때의 효율성. 

하지만 대체로 효율성과 가독성 사이에 균형을 맞춰야 할 필요가 있다. 

 

 

1. 결과를 도출할 수 있나요?
2. 해결 방법 이외에 생각나는 다른 방법이 있나요? (앞서 생각하지 못한 다른 방법을 적용할 수 있나요?)
3. 한 눈에 코드를 볼 수 있나요? (직관적인가요)
4. 결과나 방법을 다른 문제에도 적용할 수 있을까요?
 - 문제를 해결함으로써 얻을 수 있는 큰 이점 중 하나는 직감을 발달시켜 다른 문제를 해결할 수 있는 직관력을 길러준다는 것. 
- 이전에 접했던 다른 문제와의 유사점이 있는지 자문해보는 것이 좋다. (해결했던 문제가 다른 프로젝트나 다른 회사의 다른 문제에 대한 해결책을 열어주기도 한다!)
5. 더 나은 성능을 이끌어낼 수 있을까? - 주로 시간복잡도 & 공간 복잡도로 분석함


💡 회사에 근무하는 경우
- 코드를 향상시킬 수 있는 다른 방법이 있는가?
- 회사의 스타일 지침을 따라 코드를 작성하는가?
- 언어의 규칙을 따라 작성하는가?
- 간격은 일정한가?

면접시엔 깔끔하지 않다는 것을 인정하고, 시간은 없지만 깔끔하게 만들 의향이 있다는 것을 알리는 것이 중요하다.


6. 다른 사람들은 이 문제를 어떻게 해결하는가?
- 실제로 다른 사람의 코드를 먼저 풀고 해결책을 강구해야하는 경우가 꽤 있기 때문에, (회사에서)
- 다른 언어로 된 해결책이라도 다른 사람이 어떻에 풀었는지 보는게 중요하다.

 

꼭 리펙토링이 아니더라도

코드를 분석하고 성찰하고 되돌아보는 것이

그저 작동하도록 코드를 작성하고 하루를 마감하는 것보다 가치가 있다..!

 

 

 

이 코드를 -> 이렇게 바꿀 수 있다.

값이 이미 존재한다면 1을 더하고,

 값이 없다면 값을 1로 설정

 

리펙토링 후, 

JS에서 정규 표현식이 수행중인 작업과 사용중인 브라우저에 따라 성능이 달라질 수 있다는 말을 들은 적 있다는 말도 덧붙일거라고 함. 

특히 크롬은 정규 표현식 사용에 문제가 있었는데 (지금은 없는 것 같은디)

 

정규식보다 일반 문자가 더 빠르다고 한다.

문자를 구분하는 방법으로 아스키 문자로 숫자의 범위를 이용해도 됨.