코드 문제를 푼다. 의사코드를 작성한다. 의사코드를 바탕으로 간략한 코드를 작성한다. 최종 코드를 작성하고 테스트 버튼을 누른다. 오류가 없다. 꿈이다. 현실은 오늘도 역시 기대 희망과는 다른 결과. 딱! 한 번에 푸른색만 나오는 경우가 없다. (푸른색은 모든 조건을 만족하는 코드를 제출했다는 뜻이다.) 도대체 왜 그럴까? 첫 단추부터 틀렸다. 코드의 큰 흐름을 잘못 잡았다. 시작부터 꼬인다. 결과도 당연 꼬인 코드다.
오늘의 꼬인 이유는 배열로만 생각해서다. 문자열이고 객체고 뭐든 배열로 바꿔서 생각한다. 순서가 있고 인덱스 번호가 있는 배열이 편하기 때문이다. 문자열 문제도 배열로 바꿔서 푼다. 'split, splice ...' 다시 결과를 문자열로 'join...' 배열과 문자열 사이를 여행하는 기분이다. 'for 문'과 혼합, 거기다 'if 문'은 양념으로 추가한다. 배열과 문자열을 넘나드는 대서사시. 코드가 복잡해지기 시작한다. 복잡한 코드로 어떻게든 테스트를 통과한다. 제출 버튼 그리고 레퍼런스 확인. (아 ~ 나의 뇌는 아직도 386 컴퓨터다.) 업그레이드가 시급하다.
배열과 문자열을 오가는 여행에서 좋은 점도 있다. 배열, 문자열의 메소드들을 왔다 갔다 연습할 수 있다는 것. 뭐가 좋은지는 모르겠다. 문자열이면 문자열로 푼다. 배열이면 배열로 푼다. 레퍼런스를 보면 굳이 타입을 변화시키지 않는다. 주어진 타입으로 푸는 경우가 많다. 그래서 "주어진 타입으로 푸는 방법이 좋은 게 아닐까?" 하는 생각이 든다.
이제 타입을 변화시키지 않고 문제를 푸는 방법을 생각한다. 그런 이후에 타입을 변화시키는 것도 생각해야 한다. 레퍼런스와 같은 코드는 아니더라도, 최소한 근접한 코드를 쓰고 싶다. 말도 글도 코드도 같은 점이 있다. 모두 같은 내용을 짧게 전달하면 좋다는 것이다. 그래서 이 글의 핵심은 무엇이냐? '코드의 큰 흐름을 잘 잡고 시작하자.' 즉, 시간이 들더라도 의사코드에 힘을 좀 쓰자. 이렇게? 저렇게? 요렇게? ... 그 생각을 비교해서 더 나은 방향을 잡자. 뼈대를 잡아야 코드라는 살을 예술적으로 붙일 수 있다.
어제는 코드스테이츠 'Day-8'. 아무 말 대잔치로 막 쓴다. '양질전환의 법칙' 일단 매일 쓰자! 이게 제일 중요하다고 생각하자.