
문제를 잘못 읽는 실수를 범하지 않도록, 문제를 공격적으로 읽으면서 문제가 원하는 바를 완전히 이해하려는 노력이 필요하다. 사소한 제약 조건을 놓치게 되는 경우 풀 수 없게 되는 경우도 많으며, 대회에서는 작은 실수도 용납하지 않는 경우가 대부분이기 때문이다.
자신이 다루기 쉬운 개념을 사용하여, 문제를 자신의 언어로 풀어쓰는 것, 문제가 요구하는 바를 직관적으로 이해하기 위해서 필요한 과정이며 복잡한 과정일수록 더욱 중요하다.
문제의 본질을 어떤 방식으로 재구성하느냐에 따라서 같은 일을 하는 프로그램이라도 전혀 다르게 받아들여질 수 있다.
어려운 문제를 쉽게, 쉬운 문제를 어렵게 풀 수 있기 때문에 추상화가 프로그램이 나아갈 방향을 결정한다고 볼 수 있음
추상화: 현실세계의 개념을 우리가 다루기 쉬운 수학적 / 전산학적 개념으로 옮겨 표현하는 과정
문제를 어떤 식으로 해결할지 결정하고, 사용할 알고리즘과 자료구조를 선택하는 과정. 가장 중요한 과정이라고 할 수 있으며, 문제를 보고 바로 해결 방법이 떠오르지 않는 경우, 이 과정에서 가장 많은 고민을 하게 됨.
구현을 시작하기 전에 계획을 검증하는 단계를 거쳐야 함. 이 과정에서 우리가 설계한 알고리즘이 모든 경우에 대해 요구 조건을 정확히 수행하는지 증명하고, 수행에 걸리는 시간과 사용하는 메모리가 문제의 제한 내에 들어가는지 확인해야 한다.
구현에 있어서는 효율성과 정확성을 항상 챙길 것.
당장 직접적인 영향은 없지만 장기적으로 가장 큰 영향을 미치는 단계.
한 번 풀어봤던 문제를 다시 풀어보는 경우에 더 효율적인 알고리즘을 찾거나 간결한 코드의 작성이 가능해지기도 하며, 같은 알고리즘을 유도할 수 있는 더 직관적인 방법을 찾아낼 수도 있다.
효과적으로 회고를 수행하는 방법으로는 문제를 풀 때마다 자신의 경험을 기록으로 남기는 것이 제일 유효하다고 본다.
접근 방식, 결정적인 깨달음, 오답 원인 등을 기록하는 것으로 실수를 줄이고 패턴화에 도움을 줄 수 있기도 함. 해결한 다른 사람의 코드를 확인하는 것으로 생각치 못했던 통찰을 얻을 수도 있음
해결하지 못했을 경우에도 일정 시간이 지나면 다른 사람의 코드나 풀이를 참조하되 반드시 복기를 동반할 것
비슷한 문제를 풀어본 적이 있는가?
단순한 방법에서 시작할 수 있을까?
내가 문제를 푸는 과정을 수식화할 수 있을까?
문제를 단순화할 수 없을까?
그림으로 그려볼 수 있을까?
수식으로 표현할 수 있을까?
문제를 분해할 수 있을까?
뒤에서부터 생각해서 문제를 풀 수 있을까?
순서를 강제할 수 있을까?
특정 형태의 답만을 고려할 수 있을까?