코딩 잘하는 법에 대한 단상

글쓰는 법에 대한 가이드는 있어도 코딩하는 법에 대한 가이드는 보지 못한 것 같다.
글을 쓸 때에도 탑다운으로 (워드의 개요 모드outline mode 활용할 때처럼) 쓸 때와 글 가는 데로 붓 가는 데로 쓸 때가 다르듯이 코딩도 유사함을 가지고 있다.

논리적 설계와 아키텍처의 중요성을 강조하다가 막상 아키텍처 설계가 일단락되어 실제 코딩 단계로 넘어가면 어쩔줄 몰라하는 친구들이 있다.

물론 코딩 못하는데 설계만 아주 잘하는 건 일반적으로 가능한 이야기는 아니고 이런 이들의 설계는 구멍들이 있거나 현실성이 부족한 경향이 있다.

코딩을 설계를 기반으로 topdown 방향으로 진행하려면 인터페이스나 메소드 시그너처 혹은 커멘트 등을 통해 계속 논리 진행을 코드화해나가야 한다.
아주 디테일한 구현을 하나씩 해나가면서 그야말로 코드 가는 데로 하는 방식은 코드 몰입이 좋을 때 별다른 문제없이 잘 된다.
하지만 디테일 코딩을 하기에 논리적 분량이 많고 여러 가지 고려할 경우의 수가 많은 경우는 메소드 시그너처를 먼저 작성하고 (여의치 않은 경우 소스코드에 커멘트로 디테일 계획을 적어둔다) 디테일은 하나씩 채워나가는 형태가 더 효율적이다.
한마디로 코딩할 땐 구현해야할 모든 걸 코드에 반영하는데 한꺼번에 다 상세 구현으로 반영할 수없는 부분은 윤곽만 코딩하는 것이다.

이것은 그림을 그리는 과정과도 유사하다. 기본 스케치를 먼저 하는 것은 설계 후 주요 인터페이스 시그너처를 정의하는 것이라 볼 수 있고 실제 상세 터치는 어떤 부분은 아주 세밀하게 한번에 그리고 어떤 부분은 윤곽부터 조금씩 구체화하는 방식을 사용한다.
대부분 두 가지 방식이 모두 사용되어야 효율적인데 한번에 상세로 그리는 집중력이 필요한 부분은 그렇게 하고 생각이 끊어지는 여러 부분들은 그 포인트만 먼저 윤곽을 잡는 식인 것이다.

스스로 코딩도 하지만 멤버들의 교육과 성장을 함께 고민하면서 스스로에게 여러 가지 실험을 하게 된다.
논리적 사고의 방법, 창의 도출의 방법, 설계의 방법, 코딩의 방법, ...
결과물을 만드는 것만 목적이 아니라 결과물을 만드는 방법을 확인하고 공유하는 것도 중요한 미션이다.

안타깝게도 이러한 부분들이 대화로 전달될 수 있는 건 아닌 것 같다. 가이드일뿐이지 체득은 스스로들 해야 하는 것.

어떤 이에겐 너무 당연하겠지만 답답하게도 이를 몰라서 잠재력을 발휘못하는 사람들도 상당히 많은 것 같다.
코딩을 잘한다는 게 프로그래밍 언어를 잘 이해하는 것만이 아닌 것이다.