이건 형이 하는 수법이다.

먼저 문제를 보면 제일 중요한 놈은 항상 하나다.

거창하게 알고리듬 들어가는 건 드물지만, 문제가 "모든 경우의 수에서 답을 찾아내는" 스타일이면 제대로 된 알고리듬이 필요하므로 약간 여기저기 뒤지고 젖절한 알고리듬을 택하고 그 알고리듬을 잘 이해할 수 있어야 된다. 형이 한 한달전 한거는 Levenshtein 알고리듬으로 연산을 찾아낸 후, 연산을 문제에 적용하기위해 변환을 시키는 그런 걸 함. 예전에 조팝이 지가 생각한 나름의 알고리듬(이라 쓰고 버그 범벅 걸레라 부른다)을 형이 싹 고쳐버림.

위와같은 알고리듬 이외엔, 일단 제일 중요한 부분을 잘 파악하고 간단하고 이해가 팍 되며, 인간 노가다는 최소로하고 컴퓨터 노가다를 극대화한 해결책을 찾아야 한다. 형은 대체로 재귀를 많이 씀.

예를들어 이번 주엔 로그를 남길때 데이터 구조에서 주어진 필드 이외엔 기록을 안하는 (암호 등) 메카니즘을 구현했다. 하나는 데이터 구조를 정의하는 부분에 기록할 필드를 추가하는 방법, 하나는 최말단 로깅 함수에서 콜되는 hide-sensitive-data. 물론 클로져 매크로로 깔끔히 구현함.

이건 그냥 논리적 조합과 나열로, 문제를 해결하는 과정 중에 문제를 더 잘 이해하게 되며, 이름이나 논리적 디테일이 만족할 때 까지 코드는 계속 바뀐다. 나는 이때 컴퓨터에서 컴파일만 되는지, 즉 주로 타이핑 실수 위주로 체크한다. 논리적 오류의 디버깅 이런건 안하는데, 함수 인자 순서나 갯수 이런거는 좀 고쳐줘야됨.
암튼 일주일간 이름만 서너번 바꾸고, 젖절한 추상층을 부여하는데 시간이 허락하는 한 전력을 다함.

주어진 시간 끝나고 딴 새키가 코드리뷰 하는데, 걍 뻑 가드라구 후훗. 형이 짜는 프로그램이 그렇지 뭐.

암튼 열심히 해보고 안되더라도 실망하진 마라. 노력해도 안되는게 있고, 니가 나보다 잘하는게 분명 있을꺼야.