서론
2주차는 내가 정말 많이 부족하다는 것을 느끼는 시간이었다..
공통 피드백과 Discussion을 통해 객체 지향적 프로그래밍은 이렇게 짜야한다는 것을 배운 것 같다. 나는 그동안 너무 내 마음대로 스파게티 코드를 짜지 않았나 싶은 생각이 드는 시간이었다.
1주차 공통 피드백
커밋 메시지를 의미 있게 작성한다.
커밋 메시지로 작업한 내용에 대한 이해가 가능하도록 작성하는 것은 너무 어려웠다.
커밋 메시지 컨벤션 예시과 깃 커밋 메시지 컨벤션을 참조하여 완성하였습니다.
커밋 메시지의 7가지 규칙
- 제목과 본문을 빈행으로 구분
- 제목 <= 50로 제한
- 제목의 첫 글자는 대문자로!
- 제목의 끝에는 마침표 x
- 제목은 명령문으로! 과거형 x
- 본문의 각 행은 72글자 이내로
- 어떻게 보다는 무엇과 왜를 설명해야 한다.
커밋 메시지 구조
여기서 <type>은 해당 commit의 성격을 나타낸다.
- feat : 새로운 기능에 대한 커밋
- fix : 잘못된 동작을 고칠 경우 사용(버그 등장 시)
- docs : 문서 수정의 대한 커밋
- style : 코드 스타일 또는 오타, 변수명 포맷 등에 관한 커밋
- refactor : 코드 리팩토링에 대한 커밋
- test : 테스트 코드 관련된 커밋(추가, 수정 등)
- chore : 빌드 업무 수정, 패키지 매니저 수정 등
<body>는 본문으로 헤더에서 생략한 상세한 내용을 작성합니다. 헤더로 충분한 표현이 가능하다면 생략이 가능합니다.
<footer>는 바닥글로 어떤 이슈에서 왔는지와 같은 참조 정보를 추가하는 용도로 사용합니다.
예를 들어 특정 이슈를 참조하기 위해서 close #321와 같이 사용하면 됩니다. 그리고 이는 main 브랜치로 푸쉬될 때 닫기(close) 됩니다. 해결(이슈 해결 시 사용)/관련(해당 commit에 관련된 이슈 번호)/참고(참고할 이슈가 있는 경우 사용)의 타입을 사용할 수 있습니다.
Discussion
정말 많은 도움이 되었다. 링크를 기준으로 서술하겠습니다.
변수명을 짓는데 어려움이 있을 때 도움을 읽으면 도움이 된다.
- is~~~
- get~~~
- make~~~
많이 쓸 예정 :)
우테코 프리보드를 완성적으로 끝내기 위해서는 위 체크리스트를 자주 참고해야한다..
요약 그 잡채..
else를 지양해야한다는 말은 들어만 보았지 사실 코드에 적용해보지 않았다.
이번 토론을 통해 이유에 대해 알았고, 코드에도 적용하도록 노력해야겠다.
이유 : else는 빠른 반환 원칙을 준수하지 못한다. 왜냐하면 else문에 의해 코드의 indent depth가 늘어난 채 유지되기 때문이다.
처음 알았다...
그 동안 무수히 많은 매직 넘버를 사용했었는데.. 쓰지 않도록 노력해야겠다..
1주차 피어 리뷰에 올라온 내용이다. 총 4개를 읽었고.. 리뷰는 달지 못했다.
리뷰를 달수있는 개발자가 되어보자!
읽어볼 링크들
