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

Server 이전 글에서는 Path를 설계해봤었다.Path는 어디로부터 왔는 지 알기 위해 서버 출처가 필요하다.를 만족시키기 위해 서버를 관계시켜뒀는데, 이번 글에서는 해당 테이블을 설계해볼 것이다. 가장 먼저 떠오른 핵심적인 건, 서버 이름이다.사용자가 API를 등록할 때 서버 이름을 보고 해야되기 때문이다. 따라서 겹치지 않도록 고유하게 만들어둬야 한다.이제 뭐가 더 필요할까... 를 고민할 때 점점 그림이 복잡해지므로좋은 설계는 실제 현상을 기반으로 만든다. 원칙을 떠올려서 사용자 시나리오를 만들어보자.에서 서버가 필요한 부분은 여기다아래처럼 구분해두면 조회 성능에서 큰 차이가 있을 것이기 때문이다.그리고 관리자 입장에서 서버로 구분해두면 편리하다.특히 서버 도큐먼트 주소를 입력하는 부분을 어느정..

Drawing 나름 Swagger 결과 데이터를 보면서 만든 인터페이스를 소개하자면interface SwaggerPath { path: string; method: string; operationId: string; parameters?: SwaggerPathParameter[]; requests?: SwaggerPathRequest[]; responses: SwaggerPathResponse[]; tags: string[];}interface SwaggerPathParameter { name: string; required: boolean; type: string;}interface SwaggerPathRequest { contentType: ..

Scratch 좋은 설계 카테고리의 시작은 Swagger API를 이용해 인증 & 인가 서비스를 만드는 것에서 출발했다.아래는 나름 Swagger 결과 데이터를 분석해 만든 다이어그램이다.먼저 한 일은 Swagger 결과 데이터를 타입스크립트 기반으로 파싱하는 일이었는데, 결과는 뻔하지만 좋았다.구조적으로 잘 분리했기 때문에 테스트 코드나 케이스를 만드는 것도 어렵지 않았다.여기서 느꼈던 점은좋은 설계는 쉽고 정확하게 코드를 작성하게 해준다.     사실 위와 같은 구조를 만드는 것도 어렵지 않았다. 실제 팩트(fact)를 보면서 만들었기 때문이다.이런 관점에서 본다면 빠져나갈 예외 케이스도 없었다. 만족할 만한 구조가 나온 것이다.두 번째로 느낀점은좋은 설계는 실제 현상을 기반으로 만든다.    역시 ..

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

Easy Naming 이번 글은 조금 어려운 이야기를 하려고 한다. 내용 뿐만 아니라 마음도 살짝 어렵다. 이 글을 곡해하는 것보다 더 난감한 일이 없기 때문이다. 좋은 프로그래밍 책들을 보면 코드를 역할 또는 모듈 단위로 코드를 분리하라고 한다. 나는 이를 쉽게 생각해서 같은 장소에 있는 코드는 같은 세상에 있다고 해석한다. 즉, 같은 장소에 있는 코드가 갑자기 저 세상 코드가 되면 안되는 것이다. 이때 세상을 먼저 정의하면 이름 짓기가 하늘의 별따기 처럼 쉬워진다. 이름 읽기도 누워서 떡먹기 처럼 바뀐다. 그러나 내가 경계하는 건, 잘못된 세상을 만드는 것이다. Our World 예를 들어 상품 원화 가격을 달러로 변환하는 코드를 개발한다고 하자. fun convertWonToDollar(won: i..