내가 누누히 말하지만 프로그래밍 언어는 언어이고, 그래서 프로그래머는 글을 쓰는 사람임.

구조적이고 동작하는 글을 쓰는 사람인 것이지.

그러면 흰백지 위에서 코딩을 시작해야함.

시작을 어떻게 할까? 

코어 부분부터 할수도 있고, 쉽다고 생각 하는 부분 부터 할수도 있겠지.

물론 그 전에 내가 만드는 기능이 무엇인지. 어떤걸 만들고 싶은 것인지 부터 생각해야할거고.

조각가는 물체의 크기를 보고 조각할 형상을 알고, 화가는 도화지를 바라보며 자신의 포현이 드러난다고 하지만

프로그래머에게 화면은 그저 분할의 연속이야.

조각가는 깍아가는 것을 통해 작품을 만들어가고, 화가는 여백을 채워가며 그림이 점차 형태를 드러나지만

개발자에게 제품이란 그저 피어나는 것에 가깝다.

프렉탈 구조를 안으로 파고들면 새로운 무늬가 나타나는 것 처럼.

개발자에게 코딩은 완성되어갈수록, 초기의 문서에서 분해되고 쪼개져서, 여러개의 문서들(함수, 클래스, 패키지)로 나뉘게 된다.

그래서 코딩의 기본기는 쪼개기임. 

초기의 개념과 생각에서 여러개로 쪼개지고 분해되어, 해당 프로그램의 원자로 존재하게 되는 상태가 코딩의 끝이라고 볼수도 있지.

그러면 어떻게 쪼게야 할까? 무엇이 쪼게지는 대상일까?

실력있는 개발자 라는 것은 결국 이런 것들을 더욱 능숙하고 빠르게 하는 사람에 불과함.

이것은 기본적으로 프로그래밍 이라는 것은 분할을 통해 피어나는 프렉탈 구조의 완성이기 때문임.

그렇기에 설계자의 초기의 설계는 수도 없이 목표에서 빗나가게 되지.

프렉탈 구조의 요동을 예측하는 것은 어려우니까.

그래서 나온게 바로 바텀업 방식 개발인거야.

tdd, xp, 리펙토링, oop 원칙.

이런게 모두 프렉탈 요동을 최초에 정의하기가 어려웠기에

프로그래밍에 있어서 설계의 기술이란 존재하지도 않고, 아무도 알려주지도 않고, 문서화 되지도 않지.

항상 너무나 많은 것들이 바뀌고 있으니까.

확실하게 알수있는 것은 요구사항이 온다면 소스는 변경이 된다는 것 뿐이야.

그러니 존재하지 않는 설계에 너무 목매지는 말아라.

어짜피 정형화된 것이 아니라면, 기존에 해봤던 것이 아니라면, 전체 프로그램의 구조는 아무도 몰라.

그저 적당히 목표를 정하고 앞으로 나아가는 것일 뿐이지.

그래서 프로그래밍에 있어서 설계란 머나먼 대해의 나침판이자 항해지도일뿐..

그 끝이 엘도라도 일지. 신대륙을 향할지. 아니면 풍랑에 표류하다 쓰러질지. 아무도 몰라.

그게 프로그래밍이야.