개발 다이어리

사소해 보이지만 가장 쉽고  중요하다.

이름은 변수, 함수, 인수, 클래스, 패키지, 소스파일, jar, war... 어디에나 붙는다.

요즘은 IDE발전으로 일괄 이름 바꾸기가 편하다. 따라서 크게 고민하지 말고 주저 없이 이름을 붙여라

의도를 분명히 밝혀라

좋은 이름을 지으려면 시간이 걸리지만 그보다 좋은 이름으로 절약하는 시간이 더 크다.

의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워진다.

그릇된 정보를 피하라

헛갈릴만한 약어 사용을 피하라. 독자에게 그릇된 정보를 제공한다.

서로 흡사한 이름을 사용하지 않도록 주의하자.

유사한 개념은 유사한 표기법을 사용하자.

의미있게 구분하라

불용어 사용을 피하자. 아무런 정보를 주지 못한다.

내가 만약 계좌 정보 알려주는 메서드를 찾는다. 한 클래스에 다음과 같이 메서드가 존재한다. 도대체 무엇을 호출해야 하는가?

getActiveAcount();
getActiveAccounts();
getActiveAccountInfo();

누가 봐도 의미를 파악할 수 있게 구분하자.

발음하기 쉬운 이름을 사용하라

발음이 어려운 이름을 사용하면 상호 간 커뮤니케이션이 어려워진다.

int zkaq ; // 엑스케이이이큐에 값을 저장하면되요!
int sum ;  // 썸에 값을 저장하면 되요!

검색하기 쉬운 이름을 사용하라

문자를 하나만 사용하는 이름과 상수는 텍스트 코드에서 쉽게 눈에 띄지 않는다

내가 상수로 지정한 MAX_CLASSES_PER_STUDENT 가 찾기 쉬울까?

해당 상수의 값인 7로 찾는 것이 찾기 쉬울까?

특히 한자리 변수는 찾기 어렵다. 이런 관점에서 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다.

인코딩을 피하라

과거 코딩할 때나 필요했던 정보

자바는 강타입 언어라 필요 없다.

자신의 기억력을 자랑하지 마라

문자 하나만 사용하는 변수 이름은 문제가 있다. 간단한 for 문에서 사용하는 i,j..등은 괜찮지만 나머지 상황에서는 누가봐도 명확하게 이름을 지어야 한다.

전문가 프로그래머는 자신의 코드를 남들이 최대한 이해하기 쉽게 한다.

클래스 이름

클래스 이름은 일반적으로 명사나 명사구를 사용하고, 동사는 피한다

Manager,Processor,Data,Info 등과 같은 모호한 단어는 피한다.

메서드 이름

메서드 이름은 동사나 동사구를 사용하자

접근자, 변경자, 조건자는 자바빈 규약에 따라 set, get, is 를 붙이자.

기발한 이름은 피하라

재미난 이름보다 명료한 이름을 선택하라

의도를 분명하고 솔직하게 표현하라

한 개념에 한 단어를 사용하라

추상적인 개념 하나에 단어 하나를 선택해 이를 고수한다.

예를 들어, 똑같은 기능 메서드를 클래스마다 get, fetch, retrieve로 제각각 부르면 혼란스럽다.

메서드 이름은 독자적이고 일관적이어야 한다. 그래야 주석을 뒤져보지 않고도 프로그래머가 올바른 메서드를 선택한다.

말장난을 하지마라

한 단어를 두 가지 목적으로 사용하지 마라. 다른 개념에 같은 단어를 사용하는 것은 말장난에 불과하다.

add를 더하기로 사용했는데 다른 클래스나 메서드에서 집합에서 추가의 뜻으로 add를 사용하면 옳은 것인가? 이럴때는 insert, append를 사용하라

프로그래머는 코드를 최대한 이해하기 쉽게 짜야 한다. 주의깊게 봐야 이해가능한 코드가 아니라 대충 훑어봐도 이해할 코드 작성이 목표다.

해법 영역에서 가져온 이름을 사용하라

코드를 읽을 사람도 프로그래머라는 사실을 명심하자. 그러므로 전산용어, 알고리즘 이름, 패턴 이름 등을 사용해도 괜찮다.

예를 들어, Factory 패턴을 사용했다면 CustomFactory 이런식

문제 영역에서 가져온 이름을 사용하라

적절한 프로그래머 용어가 없다면 문제 영역에서 이름을 가져온다.

의미 있는 맥락을 추가하라

클래스, 함수, 이름 공간에 맥락을 부여하자.

street, city ,state, zipcode 라는 변수가 있을때

쭉 훑어보면 맥락상으로 주소라는 것을 알 수 있다.

허나 단순히 하나의 변수만 사용할때 state 만 사용한다고 할 때 이게 주소인지 확실히 알 수 있을까?

이럴때 접두사를 붙인다 addrStreet, addrCity, addrState, addrZipcode

더 좋은 방법은 클래스로 묶는 것이다. Address 클래스를 만들고 멤버로 추가하자

불필요한 맥락을 없애라

의미가 분명한 경우에 한해서 짧은 이름이 긴 이름보다 좋다. 이름에 불필요한 맥락을 추가하지 않도록 주의하자.

마치면서

좋은 이름을 선택하려면 설명 능력이 뛰어나야한다. 이는 문화적 배경이 같아야한다

대부분 사람은 자신이 짠 클래스, 메서드 이름을 모두 암기하지 못한다.

이부분은 개발도구에 맡기고 개발자는 자료 구조처럼 읽히는 코드를 짜는데 집중해야한다.

이름을 자신 나름대로 바꿨다고 질책받았다고 해서 포기하면 안된다.

요즘은 IDE에서 쉽게 이름을 일괄로 바꿀 수 있기 때문에 더 좋은 이름이 생각나면 주저 없이 바꾸

코드가 존재하리라

코드는 요구사항을 상세히 표현하는 수단이다.

어느 정도 수준에 이르면 코드의 도움 업싱 요구사항을 상세하게 표현하기란 불가능하다.

궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다.

나쁜 코드

우리는 나쁜 코드를 본적도 짠 적도 있을 것이다.

우리 모두는 자신이 짠 쓰레기 코드를 나중에 손보겠다고 생각한 경험이 있다. 하지만 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

프로젝트 초반에 코드에 시간은 안쓰고 대충 짠 나쁜 코드를 빠르게 치고 나가는 경우가 있다.

하지만 조금만 지나면 뮨재가 생긴다. 코드를 고칠 때 마다 엉뚱한 곳에 문제가 생기고 코드 변경이 어려워진다.

결국 나쁜 코드가 쌓여 생산성이 저하된다.

원대한 재설계의 꿈

기존 코드가 엉망이라 생산성이 안나와 관리층에서 재설계를 허용해 줘도 결국 재설계 또한 쉽지 않다.

이유는 재설계 시스템이 기존 시스템 기능을 100% 지원해야 하면서, 재설계 도중 기존 시스템에 가한 변경도 따라잡아야 하기 때문이다. 

결과적으로 처음부터 시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법이다.

태도

코드가 왜 이렇게 엉망이 되었나?

온갖 이유(변명)을 들어댄다.

하지만 잘못은 전적으로 우리 프로그래머에게 있다. 우리가 전문가 답지 못했기 때문이다.

고객이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 역으로 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.

예를 들어, 자신이 의사라 가정하자. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다.

시간이 너무걸리니까! 하지만 의사는 단호하게 거부한다. 왜? 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 환자 말을 그대로 따르는 행동은 범죄일 뿐만 아니라 전문가 답지 못하니까.

프로그래머도 마찬가지다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

원초적 난제

나쁜 코드는 결국 업무 속도를 늦춘다는 사실을 우리는 안다

그럼에도 불구하고 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다. 빨리 가려고 코드에 시간을 들이지 않는다.

이 부분이 틀렸다는 것을 명심하라

오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다.

빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드라는 예술?

꺠끗한 코드를 구현하는 행위는 그림 그리기와 비슷하다.

그림을 보면 대부분 사람들이 잘그렸다 못그렸다 판단을 알 수 있지만,

그것이 그림을 잘그리는 능력이 아니다.

다시말해, 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.

깨끗한 코드란?

이 질문에 대한 대가들의 답변 요약

비야네 스트롭스트룹

나쁜 코드는 더욱 나쁜 코드가 되도록 유혹한다. 나쁜 코드를 개선하려다 더 나쁜 코드를 양산할 수 있다.

깨끗한 코드는 한가지에 집중한다.

그래디 부치

깨끗한 코드는 짤 쓴 문장처럼 읽혀야 한다.

큰 데이브 토마스

깨끗한 코드란 다른 사람이 고치기 쉬워야 한다.

읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다.

테스트 케이스가 없는 코드는 깨끗한 코드가 아니다.

마이클 페더스

깨끗한 코드는 주의 깊게 작성한 코드다.

론 제프리스

중요도 순 나열

• 모든 테스트를 통과한다
• 중복이 없다
• 시스템 내 모든 설계 아이디어를 표현한다
• 클래스, 메서드, 함수 등을 최대한 줄인다

워드 커닝햄

읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다.

우리들의 생각

깨끗한 변수 이름, 깨끗한 함수, 깨끗한 클래스를 만드는 방법을 소개한다.

이책은 나와 동료들이 속한 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다.

여기서 가르치는 교훈과 기법외에 다른 집단이 가르치는 것이 틀렸다는 것이 아니다!

다만 우리 진영이 가르치는 교훈과 기법은 수십 년에 걸친 경험과 반복적인 시행착오로 습득한 것이다.

우리는 저자다.

코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다.

새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.

다시말하면 읽기 쉬운 코드가 매우 중요하다는 것이다. 비록 읽기 쉬운 코드를 짜기 쉽지 않더라도 말이다.

주변 코드가 읽기 쉬우면 새코드를 짜기도 쉽다.

주변 코드가 읽기 어려우면 새코드를 짜기 어렵다.

결론

예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다.

이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. 코드감각을 확실히 얻는 다는 보당도 없다.

단지, 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다.

나머지는 이 책을 읽는 독자에게 달렸다.