More actions
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 전체 결합을 통해 코드 버그를 줄여보자
5월 18일
- 함수
- 플래그는 추하다
- guard clause를 쓰세요!