https://book.naver.com/bookdb/book_detail.naver?bid=7390287

 

Clean Code

로버트 마틴은 이 책에서 혁명적인 패러다임을 제시한다. 그는 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제해 책 한 권에 담았

book.naver.com

 

어제 예비군을 참가해서 하루 휴식(?)했습니다.

비가 온 다음날이라 습하고 덥고 난리도 아니었네요.

 

세번째 챕터는 함수입니다.

 

 

작게 만들어라.
함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

 

PS에서 Solution 함수를 작성할 때 우리는 항상 유혹에 부딪힙니다.

이 코드정도는 그냥 따로 빼지 않아도 되지 않을까? 

생각해 보면 제가 PS에서 함수를 쪼개는 경우는 isIn() isTrue()와 같은 조건문을 빼거나 복잡한 시뮬레이션 문제를 쪼갤때 정도였습니다. 간단한 문제라면 함수의 분리가 없어도 되겠지만 구현해야되는 코드의 수준이 복잡해질수록 함수를 쪼개는 일이 중요한걸 느끼게 됩니다.

 

함수 안의 추상화 수준을 같게 하라. 위에서 아래로 내려가라.

 

어떤 함수에서 넘겨받은 인자의 홀수/짝수 그리고 음수/양수를 판독한다고 생각해 봅시다.

간단한 조건문으로도 작성할 수 있을겁니다.

if(num % 2 == 0){
	...
}

if(num > 0){
	...
}

 

 

조건부분을 함수로 따로 분리하면 어떨까요.

이것도 보기에 나쁘지 않습니다.

if(isEven(num)){
	...
}
if(isPositive(num)){
	...
}

 

 

그럼 이런 코드는 어떨까요?

if(num % 2 == 0){
	...
}
if(isPositive(num)){
	...
}

위의 코드에선 내용이 간단하다보니 이해에 문제는 없지만, 조금 더 복잡하고 난해한 코드에선 이런 일관성을 해치는 코드가 큰 오해를 만들 수도 있습니다.

 

 

예상할 수 없는 결과를 일으키지 마라.
명령과 조회를 분리하라.

 

위에서 사용했던 isPositive() 함수를 생각해 봅시다.

다른 사람이 짠 해당 코드를 발견했고, 마침 양수를 구분해야할 필요가 있던 저는 제 개발파트에 해당 함수를 가져다 썼습니다. 그런데 알고보니 isPositive() 안이 이런코드로 구현되었다면요?

public boolean isPositive(int num){
    if(num > 0){
        answer ++;
        return true;
    }
    return false;
}

isPositive()가 호출되고 받은 인자를 양수로 판독할때마다 어딘가의 static한 변수 answer를 늘려주고 있었다면, 단순히 양수를 판독하려던 저는 프로그램을 망가트리는 치명적인 버그를 만들 수도 있습니다.

 

 

 

지키고 있던 내용도 있고, 알면서 지키지 않았던 내용도 많은 제 코드를 회고해보게 만드는 챕터였습니다.

감사합니다.

728x90

+ Recent posts