CleanCode

Clean Code

• CleanCode book
• CleanCoders
  • 쩌네 이런데가 있네요. 안경끼고 손가락질 하는 분 엉클 밥 같으신데..? - 서지혜
• Google Code Review System
• google coding style guide

5월 11일

• Clean Code 읽은 부분에 대해 토론(Chap 01, Chap 09)
  • Chapter 2 Meaningful Names - Naming Convention
  • 클래스의 이름을 지을 때는 -info, -data와 같은 일반적인 이름을 쓰지 말라.
  • Account를 만들면 되지 AccountInfo라는 클래스를 만들 필요는 없다. Account 클래스 내부에 들어가는 정보가 Info니까.
  • -List 라는 식의 이름을 지을 때는 정말로 List의 API들을 지원할 때에만 -List라고 붙여주는것이 좋다. 이름을 저렇게 지으면 -List의 API들을 지원할 것 같은 느낌이 들기 때문에 아닐 경우에는 -s나 다른 방식으로 하는게 좋을 것.
  • 아래와 같은 식으로 Account내부의 정보를 하나로 묶으면 AccountInfo 클래스와 getAccountInfo()등이 있을법하지 않은가? -> 저런 구조 자체가 잘못됐을 수 있다. getAccountInfo()와 같은 방법이 아니라 다른 방법으로 일을 시키는 모양이 더 낫다.

Class Account {
private AccountInfo info;
};

• • Chapter 9 Unit Tests
  • 문제를 들었을 때 테스트코드를 먼저 생각하는 습관을 들여야 할 것 같다. 문제를 해결하는 코드를 먼저 짜려고 하면 결국 테스트코드 작성이 아니라 직접 테스트를 하게 되는 듯 하다.
  • 피드백을 빨리 받기 위해서 테스트를 실시. 피드백을 받고 고칠 때까지의 주기가 짧아야 함. 코드를 짜고 유닛테스트를 만드는 것도 안되는건 아님. 피드백을 바로 받을 수 있으면 됨.
  • 코드를 깨끗하게 하고 싶으면 테스트 코드도 깨끗하게 유지해야 한다. 테스트 코드가 더러워지면 테스트를 잘 안하게 되니까 코드도 더러워지게 된다.
  • 테스트 시에는 올바른 input이 제대로 들어오는지를 먼저 확인하고 나서 코드가 잘못되었는지 생각해볼 것.
  • 실제로는 쓰지 않는데 테스트를 위한 메소드를 추가하게 되는 경우가 있을 수 있지 않은가? -> java의 경우는 reflection을 사용하면 메소드의 추가 없이 처리가 가능한 경우도 있지만 그것보다도 테스트용 framework(mockito 등)를 사용하는것이 좋다.
  • BDD, Given/When/Then

• gerrit 설치
  • 참고 데모 동영상
  • 버전관리가 필요한 이유를 깨닫는 어떤 사람
  • gerrit install guide
• next : git과 연동

comment me

• 스터디 이름 정합시다. 아름다움을 추구하니까 소니 에릭슨? - 서지혜
  • 아름다운 걸로 하자면 unit sphere 같은 게 아름다울 것 같긴 한데... 그건 좀 아닌 것 같죠 -_-;; - 서민관
  • 음.. 공학자의 아름다움이군... - 서지혜
    • Beautiful Code -김태진