CleanCode

Clean Code

• CleanCode book
• CleanCoders
  • 쩌네 이런데가 있네요. 안경끼고 손가락질 하는 분 엉클 밥 같으신데..? - 서지혜
• Google Code Review System
• google coding style guide
• Martin Fowler의 refactoring home
• Express names in code: Bad vs Clean

5월 4일

• 스터디 킥오프
• 도서 : Clean Code
• 서지혜의 my-calculator 코드를 피어 리뷰함.

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
  • 위와는 좀 다른 참고 사이트 - 이쪽이 전체적인 흐름이나 아파치 설정 관련은 좀 더 보기 괜찮은 것 같다.
  • Gerrit기동시에「** ERROR: GERRIT_SITE not set」
  • 헐ㅋㅋㅋ 번역하니까 인스토루디레쿠토리로 나온닼ㅋㅋㅋ 전 그냥 환경변수 설정 해버렸습니다. 절대경로 쓰다가 베이스 디렉토리 한번 날려먹고 가능하면 피해범위 적도록 경로 이동해서 조작하거든요. - 서지혜
• next : git과 연동

• Git + Gerrit + Jenkins 전체 결합을 통해 코드 버그를 줄여보자
  • [1]

5월 18일

• 함수
  • 플래그는 추하다
  • guard clause를 쓰세요!

후기

• 민관
  • + : 코드 리팩토링을 해봐서 좋았다. 화이트보드에 적어가면서 읽어본 부분 공유하니까 정리된 느낌.
  • - : 프로젝트 방식과 방향이 흐릿한 느낌이다.
  • F : 시간을 컴팩트하게 진행하고 싶다. 늘어지는 경향이 있다.
• 진경
  • + : 리팩토링을 시도해보았다. 다른 사람의 코드를 리팩토링 할 수 있다는 생각을 하게 되었다.
  • - : 본인의 코드를 리뷰받고 싶었는데 정리가 되지 않아 받지 못했다.
  • F : 주중에도 스터디를! 온라인 협업 툴을 이용할 수 있다.
• 영주
  • + : 책 얘기만 한게 아니라 책의 예제를 시도해봤다.
  • - : 각자 예제를 리팩토링했다. 따로 논 느낌.
  • F : 스터디를 제대로 하고 있는지 알고싶다. (멘토가 있었으면 좋겠다?)
  • 코칭을 받고 싶다는 말인듯 - 서지혜
• 희정
  • + : 처음 나올때 떨렸는데 많이 신경 써 줘서 좋았다.
  • - : 배경지식이 부족한 듯 하다.
  • F : 스터디중에 어떻게 진행해야 하나에 대한 얘기를 너무 많이 한다.
• 지혜
  • + : 다른 사람들이 리팩토링 하는 것을 보았다. 새로운 사람 추가
  • - : 리팩토링을 할 때 리팩토링에 대한 요구사항, 리팩토링을 멈출 수 있는 수준을 제시하지 못하였다.
  • '이것'을 제시할 수가 있나?
  • F : 스터디 첫날 정했던 각자의 목적과 목표(어디갔지?)를 통해 스터디가 제대로 진행되어 가고 있는지 체크할 수 있을것.
  • 그러나 자신의 실력이 더 나음을 어떻게 비교할 수 있을까? 학습 곡선도 무시할 수 없다.

comment me

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