> 진행에 앞서
학생때 개발자(프로그래머)를 꿈꾸는 사람들이 많다.
처음에는 막연히 개발자만 되면 안도감을 갖겠지만, 그도 머지않아 안정감을 갖게 된 이후에는 다시 고민하게 되는 지점이 있다.
개발자는 코드를 생산해내는 사람들이기에, 자신이 만드는 개발 품질을 올리고 싶은 욕구를 갖게 된다.
이러한 욕구에 대해 혹자는 그냥 개발자들의 욕심이 아니냐는 단순한 욕구채우기 정도로 치부하는 경우도 있다.(아쉽게도 이것은 직접 매니저급으로부터 들은 이야기이기 때문에, 현재 개발로 커리어를 쌓지 않고 있는 일부 매니저들의 생각은 이럴지도 모른다고 생각도 든다.)
하지만, 실제 개발해보면 그것이 아니다.
물론 좋은 코드를 작성하는 것은, 마감이 잘 된 건물의 여러 구조를 만드는 것과 비슷한 느낌이 들지만, 그런 구조물들이 모여 튼튼하고 외부의 요인에도 흔들리지 않는 저력을 보여주듯이, 코드로 만든 제품 또한 그러하다.
그러한 행위(Well-Structured)를 단계마다 다양하게 부르지만, 코드 작성 및 수정 단계에서는 클린코드라는 행위라고 부르기도 한다.
코드의 유지보수성을 올리고, 한참 뒤의 내가 보든 혹은 내 후임이나 다른 동료가 보아도 그 코드에 의문을 많이 품을 필요 없이 그냥 줄줄 해석되는 코드가 되는 것이다.
이러한 책을 한번씩 읽고 인사이트를 받는데, 오늘도 그런 느낌을 받았다.
> 책에 대한 간단한 정보
208가지 실전 레시피를 기반으로 책을 저술했음을 알려준다.
실제로 상당한 내용이 하나하나의 요소로 적혀있다.
코드 품질을 개선하고자 하는 자들에게 구미가 당기도록 되어있다.
그리고 나름 책의 품질을 보증하는 오라일리 책이기 때문에 더욱 기대가 된다.
> 인상깊은 부분들
개인적으로 여러 파일이나 클래스를 가진 코드 작성시 중요하게 여기는 부분이 있다. 바로 서로간의 관계이다.
서로간의 관계가 느슨하게 하기 위해 노력해야 한다고 생각한다. 그래서 각 클래스나 인터페이스의 접점(호출부)이 간결하게 되어있는 것을 선호한다. 불가피하게 많이 참조하게 된다고 하더라도 그에 합당하게 읽혀지는 것을 선호하는데, 그에 대한 용어를 처음 알았다. '데메테르의 법칙'이다.
이것은 십수년간 일해온 나도 놓치고 있던 부분이다. 버그라는 용어를 많이 사용하고, 심지어는 회사의 공식 QA 시스템도, BTS(Bug Tracking System)이라고 부르는 것을 보면 말 다했다고 본다. '당연히 버그 아니야? 그래서 버그를 수정하지'라고 생각하며, 릴리즈노트에는 '버그 수정'이라는 항목을 만들어서 기록한 부분도 있으니 말이다.
하지만, 버그란 외부에서 준 요인에 의해 의도치 않은 동작을 일으킨 것이기 때문에, 코드의 부적절성으로 발생한 현상은 엄밀히 말하면 결함(Defect)이라고 하는 것이 맞다.
오류메시지 생성과 관련해서는 생각이 많다. 이 또한 사용자 위주(User Friendly)의 프로그램을 개발한다면, 당연히 메시지는 친절해야 한다. 하지만, 뭘 그렇게 숨기고 싶은지 오류가 발생했다는 정도로만 보여주는 경우는 매우 드물며 그래도 내부 트래킹은 편하게 하고 싶은 생각에 오류코드는 함께 출력하는 경우가 많다. 또한 메시지 뿐 아니라, 선택하는 버튼도 일률적으로 확인/취소 정도만 제공하는 경우가 많은데, 이것으로는 의미를 해석하기 어려운 경우도 많다. 그래서 사용자의 관점에서 뭘 하라는 것인지 명확히 알아야 서로 피곤함을 덜 수 있지 않은가. 그래서 이런 부분에서도 깊이 생각하고 개발할 필요가 있다는 부분에서 깊이 공감하였다.(물론 이것은 UX/기획 측면에서의 역할이 더 크기는 하다. 하지만 개발자도 방치하면 안된다.)
공포영화에서 나올법한 용어였다. 폴터가이스트 객체 제거하기이다.
좀 더 구조를 짜임새있게 작성하려다보면 하나의 객체를 만들기 위해 중간에 다른 객체를 만들어서 그것을 파라미터로 집어넣는 경우가 종종 있다. 하지만, 이것은 잠시 만들었다가 넣을때만 사용할 뿐이라고 봤을 때에는 과연 그것이 필요할지 고민해보라는 부분이다. 잠시 나타났다가 사라진다는 의미에서 '폴터가이스트 객체'라고 표현하였다. 구조상 틀린것은 아니지만, 이 정도로 잠시 나오는 객체는 더 줄일 수 있는 여지가 있기 때문에, 이에 대한 고민이 필요하다는 의미로 해석된다.
이는 내가 자주 사용하는 부분이기도 해서 눈에 띄었다.
인터페이스는 I 접두사를 붙이고, 그것을 구현하는 구현체는 Impl 접미사를 붙여서 해당 인터페이스의 구현체임을 표현하는 방법에 사용한다. 하지만, 여기에서는 실제 세계에서 하나의 개념에 인터페이스와 Impl의 개념이 혼재하여 사용되지는 않기 때문에, 실제 세계에서 사용할 법한 이름으로 사용하기를 권하는 것이다.
이는 실제 적용을 어떻게 하는 것이 좋을지 좀 더 연구가 필요해 보이기는 한다. 하지만 클래스의 속성을 접미사로 표현하는 것은 세련되지 않다는 점에는 나 역시 동의한다. 이것을 고려해서 코드 작성할 수 있도록 노력해보아야겠다.
싱글턴은 참 쉽게 쓰는 패턴이기는 하다. 이제는 패턴이라고 부르기 민망할 정도로 아주아주 구현도 쉽고, 이해도 쉽다. 하지만 그만큼 개발 전체적으로는 해악이 많다. 어느정도 있다고는 생각했지만, 이렇게 많을줄은 몰랐다. 현재 작성하는 코드 중 싱글턴 구현이 주로 되어있다면, 그것이 반드시 필요한지 점검해보고싶을 정도이다.
아래는 그 목록이다.
- 전단사 위반, 긴밀한 결합, 우발적인 구현, 어려운 테스트 가능성, 메모리를 절약하지 않음, 의존성 주입 제한, 인스턴스 계약 위반, 빠르게 실패하기 위반, 구현과 결합
- 테스트 주도 개발 기법을 적용하기 더 어려움, 상황에 맞는 고유한 개념, 멀티 스레드 환경 문제, 가비지 상태 누적, 클래스 단일 책임 위반/관심사 분리(SoC), 쉬운 접근 지점, 의존성 지옥, 유연성 부족, 수명주기관리의 어려움
이곳에는 용어집이 함께 담겨있다.
용어집의 내용이 꽤 되어서 도움이 많이 되었다. 앞에서 설명한 내용에 대해서 다시 친절하게 정리한 것을 알 수 있었다.
어울리는 관련도서가 눈에 띈다.
'켄트 벡의 Tidy First?'도 눈의 띄지만, 리팩터링 2판이 더 와 닿았다.
물론 이 책은 리팩터링에 포커스를 맞춘 책은 아니지만, 같은 맥락에서의 이야기가 많아서 공감이 되었다.
목적 자체는 코드 스멜을 없애기 위한 것이기 때문에 그렇다.
> 괜찮은 부분
1. 카테고리를 적절히 나누어서 표현하였다.
208가지 레시피라고 표현한 것이 각각의 클린코드를 만드는 기법에 대한 것인데, 이것이 그냥 나열만 하면 각각을 보면 다 공감은 가겠지만, 머릿속에서 정리도 쉽지 않고, 그래서 남는것이 별로 없게 된다. 이것을 각각의 적절한 카테고리로 나누어 놓은 것인 매우 좋았다. 공리설정, 빈약한 모델, 기본형 집착, 가변성, 선언적 코드, 명명, 주석, 표준, 복잡성, 블로터, YAGNI 원칙, 빠른 실패, if문, null, 섣부른 최적화, 결합도, 전역, 계층, 테스트, 기술 부채, 예외, 메타프로그래밍, 타입, 보안으로 나눈 내용이 그것이다. 또한 이렇게 나누어 놓은 것으로 인해, 나의 관심사를 쉽게 접근할 수도 있고, 필요한 부분을 발췌하여 보기도 좋다. 때에 맞는 것을 찾아볼 경우가 더 많기 때문이다.
2. 다양한 언어를 예제로 사용하였다.
Java, PHP, Javascript, C#, Ruby 등 정말 다양한 언어를 이용하여 예시를 들었다. 각 요소의 상황에 맞는 언어를 맞게 표현하였기 때문에 잘 모르는 언어라고 하더라도 문제가 되지는 않았다. 사실 언어라는 것은 하나의 도구일 뿐, 언어 자체에 갖혀있는 것은 좋지 않다고 생각하기 때문에 이런 선택에 대해 긍정적으로 생각한다. 또한 특정 언어에 익숙한 사람만 타겟으로 되어있다면, 그 외의 언어를 다루는 사람들은 불편하게 볼 수 있거나 거리가 멀다고 생각하기 쉬운데, 이 책은 그렇지 않다.
3. 용어 정리에 공을 들였다.
글 중간에 용어를 새로 사용할 경우 그에 대한 설명을 잘 달아주는 것은 물론이고, 별도의 지면을 활용하기 어려운 경우에는 주석을 활용하기도 하였다. 또한 책의 뒷 부분에는 아예 용어를 모아놓은 곳도 있어서 그곳을 통해서 내가 모르거나 이해가지 않는 용어에 대해서 알 수 있도록 돕고 있다. 어떤 분야든 새로운 용어가 너무 많을 경우 그만큼 장벽을 느끼기 쉬운데, 이 책은 그런 부분에 대한 배려가 크다고 생각한다.
> 아쉬운 부분
1. 책의 물리적인 구성이 아쉽다.
이 책은 표지 부분이 말려있지 않다. 이런 책의 경우 수시로 꺼내보고 다시 넣고 하는 경우가 있는데, 이런 경우 책 표지가 상하기 쉬워보인다. 정말 정성스럽게 책을 관리하는 사람의 경우 이 책을 비닐로 감싸서 보는게 나을지도 모를 정도이다. 책의 퀄리티를 조금 더 올리는 방법으로 이런 것을 신경썼으면 하는 아쉬움은 있다.
> 추천 독자
- 개발자 지망상
- 현업 개발자
> 개인적인 평점
- 가격: 8 / 10
- 내용: 10 / 10
- 디자인: 7 / 10
- 구성: 9 / 10
> 정보
저자: 막시밀리아노 콘티에리
옮긴이: 이태영
출판사: 한빛미디어
가격: 35,000원
전체 페이지: 488페이지
** 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.
'[Review] > Book' 카테고리의 다른 글
[도서 리뷰] AI 트루스 (49) | 2024.09.29 |
---|---|
[도서 리뷰] 뇌를 쓰지 않는 만만한 PPT (0) | 2024.07.28 |
[도서 리뷰] 프로그래밍의 규칙: 더 나은 코드를 작성하는 21가지 개발 비법 (0) | 2024.06.23 |
[도서 리뷰] 개발자를 위한 커리어 관리 핸드북 (0) | 2024.05.25 |
[도서 리뷰] 읽기 쉬운 코드 (2) | 2024.05.14 |
댓글