오늘 사부와의 미팅에서 배운 것들.
에러가 뜨면 막무가내로 실행하지 말고, 한 번 더 논리적으로 천천히 생각해보자. 본질에 입각해서 생각하자.
어떠한 process중에서 에러가 발생하면 그 process의 하나하나의 단계를 MECE(Mutually Exclusive and Collectively Exhaustive)하게 테스트한다.
편한 Tool을 항상 알아보자. ex) Reactotron, Vscode(plug in), Atom eslint, Atom terminal, Zsh 생산성을 상승 시키자.
기회가 있으면 꼭 참여해보자.
오랜만에 사부와 미팅을 했다.
방학동안에 한 번도 보지 못했는데, 여전히 사부는 사부였고, 나 역시 배운 것이 참 많았다.
위에 내가 배운것을 정리해 놓았다.
사고 정지의 위험성
파인만 알고리즘, Do not study programming과 같은 글들을 보면 프로그래밍을 잘 하는 방법은 참 간단하고 명쾌하다.
‘손부터 움직이지 말고, 문제를 올바르게 파악하여 해결책에 대하여 숙고한 뒤에 해결하기 위한 코딩을 한다.’ 라는 것이다.
이미 위와같은 글을 몇번이나 읽고 ‘아 프로그래밍을 할 떄는 반드시 이러한 마음가짐으로 해야지’라고 다짐까지 했건만, 정작 내 앞에 ‘익숙하지 않은’문제들이 다가오면 불쑥 손부터 움직이기 시작한다.
아마 초보 코더의 본능과 같은 것일까?
이번 웹뷰 에러를 디버그 하는 상황에서도 아무런 논리적 근거도 없이 나는 ‘이걸 이렇게 변경하면 되겠지’라는 마음가짐으로 일단 iphone의 simulator를 실행시키려고 했다.
그 때 사부가 잠깐만요! 좀더 천천히 생각해봐요 하는 말에 ‘아 그렇구나 너무 조급했구나’ 싶었다.
그리고 논리적으로 따져나가니 결국에는 거짓말같이 전혀 단서가 없어보이는 문제가 해결되었다.
이렇게 문제가 해결되는 것을 보며 나는 몇해전 학교 세미나에서 교수님이 하신 말씀이 생각났다.
사고 정지야 말로 가장 위험한 것이다.
아무런 생각없이, 아무런 논리적 근거없이 일을 행하는 것은 위험하다는 말씀이었다.
이 말씀을 생각하니 또 세미나에서 교수님이 하신 다른 말씀이 생각났다.
아무리 복잡해보이는 일이라도 하나하나 MECE(빠짐없이, 중복없이)하게 행한다면 논리적인 문제는 반드시 특정할 수 있다.
어찌보면 당연한 말이고 나 역시 말을 들을때 마다 고개를 끄덕였던 기억이 있지만 이번에는 언제 그 말을 들었냐는 듯이 망각해버리고 말았다. 사실 이번 뿐 아니라, 다소 어려운 Euler Project문제를 풀 떄도 항상 잊어버리고 만다.
앞으로는 사고정지가 일어날 때 마다 MECE를 떠올려야겠다.
프로그래밍의 신비
이번에 내가 사고정지에 대한 글을 쓰면서 생각난 프로그래밍의 재미있는 특징은, 프로그래밍에서 나오는 문제는 대부분 ‘끊임없이 생각하는 한 반드시 풀린다’는 점이다.
프로그래밍이 각종 작은 도구들을 조합해서 큰 물건을 만드는 것이기 때문에, 작은 도구들을 논리적으로 이리저리 조합하다 보면 반드시 해답이 나온다는 것이다.
하지만 해답을 찾는 과정을 위에 언급했듯이 문제를 올바르게 파악하여 해결책에 대하여 숙고한다면 더더욱 정확하고 빠르게, 그리고 간결하게 해답을 찾을 수 있을 것이다.