하용권

이번에 읽은 책은 좋은 코드, 나쁜 코드입니다.

클린 코드와 비슷한 내용이 많았지만, 저는 이 책이 더 잘 읽혔습니다.

여기서도 당연히 DI(의존성 주입)이 나옵니다. DI를 이용하여 인터페이스에 의존하도록(DIP) 할 수 있고, 이를 염두에 두고 코드를 설계하라고 합니다. 저도 최근에 우아한테크 프리코스 과제를 해보고 있는데, 이를 이용하여 유연한 코드를 작성했습니다. DI를 이용하여 의존성을 느슨하게 하는 것이 매우 중요하다는 것을 다시 알 수 있었습니다.

제일 인상 깊었던 내용은 요란한 실패와 Enum은 확장성을 염두에 두고 코드를 작성하라는 점입니다.

public enum GameName {
	LOL, MAPLE;
}


public String getGame(GameName gameName) {
	switch(gameName) {
    	case LOL:
        	return "LOL;
        case MAPLE:
        	return "MAPLE";
        default:
        	return null;
    }
    
}

만약 새로운 게임이 추가 된다면? null이 반환되고 이 메소드를 이용하고 있던 곳에서는 예상치 못한 에러가 발생할 수 있습니다.

실제 회사에서 제가 만났던 문제였습니다. 새로운 타입이 추가되었고, 이에 관한 log를 db에 남기고 있었는데 db에는 아무런 데이터도 들어가고 있지 않았습니다. 하지만 실패한 줄 모르고 있었습니다. 즉 너무 조용하게 에러를 넘어갔고, 실제로 이 db를 아무도 본 적이 없어서 년 단위 로그가 없었습니다.

이를 해결하기 위해서는 return null이 아니라 throw new Exception(); 처럼 예외를 던져줌으로써 바로 알아차릴 수 있습니다.

저는 이 내용이 너무 좋았습니다. 이를 신경써서 코딩을 하지 않았었는데, 주의할 필요성을 알 수 있었습니다.

유명한 책이라서 읽어봤습니다.

이 책에서 자주 등장하는 것이 의존성 역전입니다.

이미 알고 있던 내용이지만 자주 등장했었고, 의존성 역전이 매우 중요하다는 것을 다시 한 번 알 수 있었습니다.

김영한 님의 스프링 기본편에서도 자주 등장할 만큼 중요한 단어입니다.

인상 깊었던 것은 아키텍처를 먼저 설계하지 말라는 내용이였습니다.

추후에 필요하다면 아키텍처를 수정하거나 설계해야 한다고 강조합니다.

사실 처음부터 redis를 쓰고 kafka를 이용하여 뭐하고 이렇게 설계하면 이러한 기술에 의존도가 매우 높아져서 추후에 유지보수하기 어렵기 때문에 이러한 말을 한 것 같습니다.

잘 기억이 나지 않아서 다시 한 번 읽어봐야겠네요.

그리고 의존성을 보통 화살표로 많이 사용합니다. 여기서 순환이 있으면 유지보수 하기 매우 어렵다고 말한 점도 인상깊었습니다. A -> B -> C -> D ->  A 이렇게 서로 사용하고 있다면, 모든 컴포넌트가 서로 의존하고 있습니다.

A -> B -> C ->  D -> A Interface <- A

이런 식으로 되기 때문에 순환이 사라지게됩니다.

확실히 사람들이 많이 읽는 이유가 있습니다.

다시 한 번 읽어봐야겠네요.

이번에 읽은 책은 "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 입니다.

평소에 대규모 트래픽 처리에 관심이 있어서 읽어봤습니다.

다양한 시스템을 설계하면서 어느 부분이 문제가 될 것이고, 이를 어떻게 해결할 것인지 점차 발전하도록 시스템을 설계합니다.

인상깊었던 점은 알림 시스템 관련 파트였습니다.

이전에 스타트업에서 인턴을 하면서 모바일 푸시 관련해서 프로젝트를 했었습니다.

그 때 kafka를 이용했었는데, 이 책에서도 메시지 큐를 이용하여 설계합니다. 그 당시에는 이 책을 읽기 전인데도 불구하고 제가 구현했었던 방법이랑 비슷한 부분이 많았습니다.

지금까지는 프로젝트를 진행하면, 대규모 시스템에 대한 고려는 잘 하지 않고 설계를 했었습니다.

하지만 대규모 시스템이 된다면 메시지 큐를 이용하여 결합을 낮추고, 캐시를 이용하여 db에 가는 부하를 줄이고 속도를 높일 수 있습니다.

이런 시스템 설계 부분부터 제대로 해야지 성공적인 프로젝트가 가능하다고 느낄 수 있었습니다. 특히 확장 가능하도록 하는 것이 핵심인 것 같습니다.

시니어 개발자 분들은 대부분 아는 내용일 수 있지만, 저처럼 실무에 투입된 지 얼마되지 않은 주니어 개발자에게는 좋은 책이라고 생각합니다.

현재 프로젝트를 진행하고 있는 팀원과 이 책으로 스터디를 진행했습니다.

서로 파트를 정해서 읽고 정리하고, 개인 생각을 말하면서 스터디했었습니다.

저는 이 책에 대해 매우 만족합니다.

인상 깊었던 내용

객체의 핵심과 객체를 어떻게 설계할 것인지에 대해 설명을 해줍니다.

객체 간의 협력이 중요하고, 이를 위해 메시지가 필요하며 객체에 집중하기보다는 메시지에 집중하여 설계하라고 합니다. 객체에 집중하게 되면 객체의 데이터부터 만들게 되고, 이는 객체 내부의 데이터를 안 상태에서 메시지를 설계하기 때문에 캡슐화가 깨질 수 있습니다. 이를 데이터 주도 설계라고 합니다.

그리고 이렇게 함으로써 인터페이스로 분리할 수 있고 이는 TDD까지 이어질 수도 있습니다.

이 내용이 인상 깊었는데, 그 이유는 처음 인턴 하면서 클래스 설계할 때 위에서 말한 데이터 주도 설계를 했었습니다. 그러다보니 다른 객체는 이 객체를 완전히 알아야 수행할 수 있는 코드를 저도 모르게 짰었습니다. 코드 리뷰 하기 전까지는 이 부분이 왜 문제가 있는지도 몰랐습니다.

그리고 클래스에 집중하지 말고 객체의 협력에 집중하라고 합니다. 클래스는 단순한 도구라는 점을 이 책에서 강조를 합니다.

후기

개인적으로 저는 클린코드보다 이 책이 더 좋네요.

클린 코드는 어떻게 책임을 잘 나누고 네이밍을 하며 예외는 어떻게 할 것인지에 대해 말을 합니다. 그 과정에서 잘못된 코드를 보여주고 이를 이렇게 변경하면 된다 그런 식으로 설명을 해줍니다.

하지만 이 책은 설계하는 방법과 왜 그렇게 설계해야 되는지 설명을 해주니까 더 좋다고 느껴지네요.

(물론 주관적인 의견입니다.)

클린코드를 읽을 당시에 제 머리에 든 게 별로 없어서 이렇게 느낀 것일 수도 있습니다.

아니면 이 책 읽고 다시 클린코드를 보는 것도 좋을 것 같습니다. 오히려 이게 제일 좋은 것 같네요.

인턴하면서 한 분이 이 책을 추천해 주셨는데, 추천해 주신 이유가 있네요. (이 분도 클린코드보다는 이 책을....)