Directory 간단하게 디렉터리 이야기이다.요즘 IDE는 검색 기능이 좋아서 이름들을 클릭해주면 어디에 있는 지 알아서 찾아준다.그러나 대부분의 사람들은 그게 어떤 경로에 있고 어디에 속하는 지는 딱히 관심 없고, 문서나 구현 내용을 보기에 바쁘다.그렇기에 날이 갈수록 정리하는 습관이 무뎌지고, 어느 순간 난장판이 된 모습을 본 게 적잖아 있었다. 또 필자는 신입 때 querydsl를 보고 감동받아 직접 소스코드를 일일이 열어보고 공부했던 적이 있었는데,가장 큰 난관은 바로 프로젝트 구조였었다. 여기서 말하는 프로젝트 구조는, 각 디렉터리와 파일들이 역할과 기능에 따라 정리된 형태를 말한다. types 디렉터리를 보자. (다행히? 아직 그대로이다.)처음보면 도통 이해하고자 하는 엄두가 안난다.  우리..

Consistency 내가 실무에 있으면서 가장 좋아하고 많이 사용하는 용어는 일관성이다. 물론 일관성에 대한 사전적 정의가 있지만, 개인적으로 어떤 상황과 장소에 있든 지 똑같은 것이라고 정의한다. 예를 들어 물을 생각해보자. 일반적으로 물은 Water이다. 그러나 본인이 화학자라면 H2O라고도 부를 수 있다. 여기서 일관성을 찾자면, 당신이 누구든 간에 그냥 water라는 이름으로 통일하라는 말이 아니라 본인이 이름을 한 번 정했으면 죽을 때까지 그 이름으로 부르라는 이야기이다. 경험적으로 대다수의 코드는 정해진 범위 안에서 이름에 대한 일관성을 너무 잘 지킨다. 그러나 조금만 벗어나거나, 다른 서비스를 개발할 때는 다소 깨진다. 똑같은 의미임에도 다른 이름을 쓰거나, 다른 의미임에도 똑같은 이름을 ..

Frustrating 우리는 우리가 직접 만든 코드에 대해 엄청난 이해도를 가지고 있다. 의식의 흐름대로 착실히 한 줄 한 줄 써내려갔기 때문에, 다시 위로 스크롤해서 처음부터 읽어도 잘 읽힌다. 내 코드에 피드백 올 것들은 아마 디자인 패턴이나 문법적 우려에 기반할 것이다. 어쩌면 병렬 프로세싱에 대한 지적일 수도 있고, 효율적으로 시스템 자원을 사용하지 않아서 그러겠거니 한다. 그리고 이렇다할 피드백이 없으면 역시 더 고칠 게 없었겠거니 생각한다. 까지가 우리의 착각이다. 인정하자. 그 코드는 안 읽힌다. 그래서 아무도 그 코드를 보려고 하지 않는 것이다. 애정 깊게 쌓아 올린 코드는 결국 나한테도 잊혀져 생명이 다 할 것이다. 나는 읽히지 않는 코드는 답답하다고 표현한다. 이렇게 답답했던 경우는 2..