1장. 깨끗한 코드

나쁜코드는 회사를 망하게할 수도 있다.
프로젝트 재설계는 꿈일 뿐이다.
(차세대 프로젝트는 너무 너무 힘든 일이다.)
나쁜 코드의 원인을 밖에서 찾지 말고, 나에게서 찾자.
(프로그래머는 좋은 코드를 사수해야하는 책임이 있다.)
기한을 맞추려고 어쩔수 없이 나쁜 코드를 작성한다고 합리화 하지 말자.
(사실, 나쁜 코드에 발목이 잡혀 일정은 더 늦어지는 경우가 많다.)
좋은 코드를 작성하려면, 좋은 코드가 무엇인지 반드시 알아야 한다.

유명인들이 말한 깨끗한 코드란?

비야네 스트롭스트룹(C++ 창시자)
- 논리가 간단해야 버그가 숨어들지 못한다
- 의존성을 최대한 줄여야 유지보수가 쉽다
- 오류는 명백한 전략에 의거하여 철저히 처리한다
- 나쁜 코드는 나쁜 코드를 유혹 한다(깨진 유리창 이론)
- 깨끗한 코드는 한 가지를 제대로 한다
그레디 부치(UML 창시자)
- 깨끗한 코드는 단순하고 직접적이다
- 잘 쓴 문장처럼 읽힌다(가독성)
- 설계자의 의도를 잘 보여준다
- 명쾌한 추상화와 단순한 제어문으로 가득하다
데이브 토마스(OTI 창립자)
- 깨끗한 코드는 읽기 쉽고 고치기 쉽다
- 단위 테스트 케이스와 인수 테스트 케이스가 존재한다
- 의미있는 이르밍 붙는다
- 특정 목적을 달성하는 방법은 하나만 제공한다
- 의존성 최소, 각 의존성은 명확해야 한다
- 코드는 문학적으로 표현해야 한다
마이클 페더스('레거시 코드 활용 전략' 저자)
- 깨끗한 코드는 주의 깊게 짰다는 느낌을 준다
- 고리쳐고 봐도, 고칠곳이 딱히 없다
론 제프리스('Adventure in C#' 저자)
- 깨끗한 코드는 중복이 없다
- 한 기능만 수행한다
- 제대로 표현한다
- 작게 추상화 한다
워드 커닝햄(위키 창시자)
- 깨끗한 코드는 짐작했던 기능을 각 루틴이 그대로 수행한다

우리는 새 코드를 작성하면서, 끊임없이 기존 코드를 읽는다
그러니 깨끗한 코드를 작성하는게 정말 중요하다!
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라!(코드에도 적용이 되는말이다)

1장은 앞으로 클린 코드를 위한 세부적인 조언을 하기에 앞서, 클린 코드란 무엇인지를 짚어주는 내용이었습니다.
여러 유명인들이 생각하는 클린 코드란 무엇인지 소개하고, 저자가 느낀바를 공유하는 형식으로 진행되었는데요.
클린 코드에 대한 다양한 견해를 들을 수 있어서 좋았습니다.

2장. 의미 있는 이름

참고
해법 영역 : 전산 지식, 알고리즘, 디자인 패턴, 수학 용어 등등..
문제 영역 : 도메인, 고객의 요구사항, 비즈니스 로직 등등,
클린코드를 읽다 보면, 해법 영역과 문제 영역이라는 단어가 종종 등장합니다.
이 의미가 뭔지 명확히 설명하진 않는데, 위와 같은 의미라고 생각하시면 됩니다.

의도를 분명히 밝혀라
클래스, 메소드, 변수의 이름에서 충분한 정보를 제공하도록 명명하자.
그릇된 정보를 피해라
중의적인 표현을 피하고, 모든 코드에서 일관된 표현을 사용하자.
의미 있게 구분하라
의도가 드러나는 이름을 붙이자.
발음하기 쉬운 이름을 사용하라
발음하기 어려운 이름을 갖고 있으면 이 내용으로 토론을 할 수 없다.
검색하기 쉬운 이름을 사용하라
상수나 너무 짧은 단어로 이름을 지으면, 검색하기가 힘들다.
이름의 길이는 범위 크기에 비례해야 한다.
인코딩을 피하라
접두어 접미어를 사용하지 말자.
특히, Java에서 String nameString = "jay;"처럼 명명하지 말자.
- 인터페이스 클래스와 구현 클래스
  (저자는 개인적으로) 인터페이스 보다는 구현 클래스에 접두어, 접미어를 붙이는게 좋다고 한다.
  ex) ShapFactory -> ShapFactoryImpl or CShapFactory (O)
자신의 기억력을 자랑하지 마라
한번 봤을 때, 바로 이해할 수 있는 이름으로 변수명을 지어야 한다.
예를들어 u 라는 변수가 url이라는 것을 자신은 기억할 지라도, 동료들은 그렇지 않다.
자신은 이런것을 기억할 수 있다고 자랑(?)하는것은 전문가 답지 않다.
진정한 전문가 프로그래는 명료함이 최고라는 사실을 이해하고, 알기 쉬운 이름으로 코딩한다.
클래스 이름
클래스, 객체 이름은 명사, 명사구가 적합하다
다만, Manager, Processor, Data, Info와 같은 단어들은 피하자.
메서드 이름
메서드 이름은 동사, 동사구가 적합하다.
접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javabean 규약에 따라 get, set, is를 붙이자.
기발한 이름을 피하라
유머 감각이 비슷한 사람, 그 유머를 기억하는 사람만 이해하는 변수명을 짓지 말자.
재미난 이름 보다는 명료한 이름을 선택하라.
한 개념에 한 단어를 사용하라
추상적인 개념에는 한 단어만을 사용하라.
전체 소스에서 일관성 있는 코드를 작성하지 않으면, 읽는사람에게 혼란을 야기한다.
예를들어, 찾아오다라는 기능을 fetch, get, find, retrieve등으로 사용하면 혼란스럽다.
말장난을 하지 마라
한 개념에 한 단어를 사용하라라는 원칙을 지키기 위해 너무 큰 범주를 묶지 마라.
예를 들어, 기존 프로젝트에서 두가지를 합쳐서 새로운 결과를 반환하는 기능을 add라고 쓰고있었는데
기존 데이터 집합에 새로운 항목을 추가하는 기능도 add라고 명명하는것은 옳지 않다.
이런 경우 append, insert 같은 이름들이 더 적절하다.
해법 영역에서 가져온 이름을 사용하라
코드를 읽는 사람도 프로그래머라는 사실을 명심하자.
프로그래머에게 익숙한 기술 개념을 활용하자.
문제 영역에서 가져온 이름을 사용하라
적절한 프로그래밍 용어가 없다면 문제 영역에서 이름을 가져오자.
문제 영역과 관련이 깊은 코드라면, 문제 영역에서 이름을 가져오자.
의미 있는 맥락을 추가하라
아무리 고민해도 적절한 이름이 생각나지 않는다면, 마지막 수단으로 접두어를 붙이자.
ex) firstName, lastName, addFirstName, addLastName 등
함수 하나가 너무 길면 맥락이 보이지 않기 때문에, 여러개의 함수로 나누자.
그 함수들로 하나의 클래스를 만든다면 더욱 맥락을 파악하기 쉽다.
불필요한 맥락을 없애라
일반적으로 짧은 이름이 긴 이름보다 좋지만, 그렇다고 이름에 불필요한 맥락을 추가하지 말자.
ex) '고급 휘발유 충전소(Gas Station Deluxe)' 애플리케이션의 모든 클래스에 GSD라는 접두어를 붙임.
-> 모든 클래스에 GSD를 붙이면, IDE에서 G를 검색하면 모든 클래스가 검색됨
ex) 각 고객 계정의 주소를 담는 클래스를 GSDAccountAddress 라고 명명
-> 주소를 담는 클래스의 이름은 Address면 충분하다.
-> accountAddress, customerAddress등은 변수명으로 하는것이 좋다.

2장을 읽으면서 느낀 것은, 이렇게 하는게 명확한 의미를 전달 하더라라는 것이지, 이것을 마치 절대적인 규칙처럼
무조건 준수해야한다는 뉘앙스는 아닌것 같았습니다.
그 예로 2장에서 접두어를 사용하지 말라고 했다가, 아무리 생각해도 안되면 오히려 접두어를 사용하라고 합니다.
만약 저자가 전달하는 내용을 규칙으로 생각했다면, 이는 모순이라고 보이겠죠.
그래서 결국 저자가 하고싶은 말은 "변수명 지을때 생각좀 하고 지어라" 라서, 2장에서 알려주는 내용들을 잘 기억해놨다가
알잘딱 이름을 지으면 된다는 말인 것 같습니다.

저작자표시 비영리 변경금지