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를 쓰세요!
- Error Handling
- 에러를 방지하거나, 처리하는 코드 때문에 함수의 본 임무를 파악하기 힘들게 되면 안됩니다.
- Consider using try-catch-finally instead of if statement.
- Don't return null.
- Returning null or undefined (Javascript)
var list = stringObject.match(/regexp/);
if(!list){
// handle and return
}
list.forEach(/* handle found strings */)
...
- Returning emtpy object (Javascript)
var list = stringObject.match(/regexp/) || []; list.forEach(/* handle found strings */) /* You can handle empty list with "list.length === 0" statement in anywhere after list is set. */
- Don't pass null.
후기
- 민관
- + : 코드 리팩토링을 해봐서 좋았다. 화이트보드에 적어가면서 읽어본 부분 공유하니까 정리된 느낌.
- - : 프로젝트 방식과 방향이 흐릿한 느낌이다.
- F : 시간을 컴팩트하게 진행하고 싶다. 늘어지는 경향이 있다.
- 진경
- + : 리팩토링을 시도해보았다. 다른 사람의 코드를 리팩토링 할 수 있다는 생각을 하게 되었다.
- - : 본인의 코드를 리뷰받고 싶었는데 정리가 되지 않아 받지 못했다.
- F : 주중에도 스터디를! 온라인 협업 툴을 이용할 수 있다.
- 영주
- + : 책 얘기만 한게 아니라 책의 예제를 시도해봤다.
- - : 각자 예제를 리팩토링했다. 따로 논 느낌.
- F : 스터디를 제대로 하고 있는지 알고싶다. (멘토가 있었으면 좋겠다?)
- 코칭을 받고 싶다는 말인듯 - 서지혜
- 희정
- + : 처음 나올때 떨렸는데 많이 신경 써 줘서 좋았다.
- - : 배경지식이 부족한 듯 하다.
- F : 스터디중에 어떻게 진행해야 하나에 대한 얘기를 너무 많이 한다.
- 지혜
- + : 다른 사람들이 리팩토링 하는 것을 보았다. 새로운 사람 추가
- - : 리팩토링을 할 때 리팩토링에 대한 요구사항, 리팩토링을 멈출 수 있는 수준을 제시하지 못하였다.
- '이것'을 제시할 수가 있나?
- F : 스터디 첫날 정했던 각자의 목적과 목표(어디갔지?)를 통해 스터디가 제대로 진행되어 가고 있는지 체크할 수 있을것.
- 그러나 자신의 실력이 더 나음을 어떻게 비교할 수 있을까? 학습 곡선도 무시할 수 없다.