클린코더스 6강 - Form

💡백명석 님의 클린 코더스 강의를 듣고 요약한 자료입니다.

목차

1, 2강 OOP
3, 4강 Function
5강 Function Structure
6강 Form

Coding Standards

조직이 일정 수준의 크기가 되면 관료적인 문서화를 요구한다. 코드를 어떻게 작성할 것인지에 대한 표준을 마련하는 것은 필요하지만, 별도로 문서화하는 것은 회의적.

Comments should be rare

CodingStandards가 코멘트 작성을 강제하면 어떨까? 프로그래머는 필요해서가 아니라 의무적으로 코멘트를 작성하게 될 것이다. 무의미한 코멘트가 많이 생산될수록 코멘트를 읽는 사람이 줄어들 것이다. 따라서 코멘트는 특별하게, 그것이 반드시 필요한 경우에만 작성해야 한다.

Comments are failures

작성자의 의도가 잘 나타나게 프로그램을 작성한다면 코멘트가 불필요하다. Java, Ruby, C# 같은 프로그래밍 언어는 표현력이 뛰어나기 때문에 가능하다. 모든 코멘트는 당신의 코드가 충분히 표현적이지 못하다는 반증이다.

Good Comments

좋은 코멘트는 무엇인가?

• Legal Comments
• Informative Comments
• Warning of Consequences
• Todo Comments
• Public API Documentation

Bad Comments

그렇다면 나쁜 코멘트는 무엇인가?

• Mumbling
  알아보기 힘든 코멘트. ~해서 ~ 되어서 ~ 해서... 끝없는 주석.
• Redundant Explanations
  이미 코드가 설명하고 있는 데 그걸 다시 한 번 주석으로 말하는 것
• Journal Comments
  변경 이력 같은 것을 써넣은 코멘트
• No ways Comments
  아무 의미 없는 코멘트
• Closing Brace Comments
  }//end of for 같은 것
• Attribution Comments
  누가 작성했는지. 정말 필요하면 직접 확인하면 된다.
• HTML in Comments
• Non-Local Information
  멀리 떨어진 곳의 코드를 설명하는 코멘트를 작성하지 마라.

Vertical Formatting

공란 막 쓰지 마라.
메서드 사이, private, public변수 사이.
메서드 내 변수 선언과 메서드 실행의 나머지 부분. if/while블록과 다른 코드 사이.
특별하지 않은 경우에 공란 쓰지 마라.
관련된 것들은 vertical하게 근접해야 한다. vertical한 거리가 관련성을 나타낸다.

Class

클래스는 private 변수를 만들고 public함수로 그것을 조작한다. 외부에서는 private변수가 없는 것처럼 보인다. 이게 클래스다. 하지만 이런 경우는 별로 없다.

보통 아무 생각없이 getter/setter를 제공하기 때문이다. 이건 나쁜 설계다. private으로 선언해도 getter/setter를 제공하면 public변수를 제공하는 거나 다름없다. Tell Don't Ask를 잘 지키면 getter/setter를 피할 수 있다.

응집도에 대해 알 필요가 있다. 메서드가 클래스 내의 모든 변수를 조작한다면 응집도가 높은 것이다. 모든 메서드가 그렇다면 그것은 응집도가 높은 클래스다. getter/setter를 이용하는 방식은 cohesive하지 못하다. getter/setter는 하나의 변수만 사용하니 당연한 결과다. 안 쓸 수는 없으니 최소화해야 한다. getter를 써야 한다면 본래 변수를 그대로 노출하지 말고 추상화를 통해 제공해야 한다.

https://github.com/msbaek/clean-coders-2013

getGallonsOfGas라는 이름은 구현 내용을 적나라하게 드러낸다. 이 메서드를 사용하는 클라이언트는 gallonsOfGas라는 변수가 있다는 것을 추론할 수 있다.

https://github.com/msbaek/clean-coders-2013

디젤 차는 가솔린을 사용할 수도 없다. 차가 가솔린에서 디젤로 바뀌면 클라이언트까지 변경해야 한다.

https://github.com/msbaek/clean-coders-2013

상세 구현을 덜 노출할수록 다형성을 활용할 기회가 늘어난다. 내부 변수를 숨기고 gallonsOfGas를 추상화된 메서드로 제공할 경우 유연한 설계를 할 수 있다. 다형성을 통해 클라이언트(CarDriver)는 Car에만 의존함으로써 실제 Car가 변경되어도 영향을 받지 않는다.

객체지향의 핵심은 IoC를 통해 High Level Policy(클라이언트, 비즈니스 로직)를 Low Level Detail로부터 보호하는 것이다.

Data Structure

데이터 스트럭처는 클래스와 반대되는 개념이다.

https://github.com/msbaek/clean-coders-2013

그동안 Java로 데이터스트럭쳐를 만들고 있었던 것은 아닌 지 자문해봐야 한다. 만약 switch문이 있다면 DS가 숨어있다는 것을 알아차려야 한다.