090.10 b
Description: 우아한테크코스 1주차 회고록
#000#IT_Knowledge#090#External_Insights#090.10#Activity#090.10 b#우아한테크코스_1주차_회고록
우테코 1주차 회고록
우아한 테크코스 1주차를 하면서 여러 지식을 배웠습니다.
JSDocs , Jest , 변수 관리 등등... 그 중에서도 특히 생각해 볼만한 점과 관련한 2가지를 배웠습니다.
1. 구현할 기능 단위의 목록 작성시 그 기준은 어떻게 할 것인가?
2. 좋은 Commit Convention 이란?
1. 구현할 기능 단위의 목록 작성 시 그 기준은 어떻게 할 것인가?
요구사항을 받았을 때 비개발자와 개발자 사이의 다리 같은 역할을 하는 기능 명세서 가 필요하게됩니다. 해당 내용을 기반으로 우리는 기획단계에서 서로의 의도를 파악하고 개발을 시작할 수 있겠죠. 라고 보통 알고있었습니다.
하지만 더 깊은 내용에 대해선 생각해볼 기회가 없었죠. 그 기능 명세서 안의 기능 단위는 어떻게 구분할 것인가? 입니다
처음 기능을 나눌 때의 개발자의 입장에서 함수 단위로 나누어봤습니다. 제가보기엔 좋지만 단어선정에 있어 개발을 모르면 어려운 형태죠.
이후 단어를 비개발자도 이해하기 쉽게 바꿨습니다. 변수 형태로 구현이라는 용어보다는 나중에 변경 가능 이라는 표현으로 대체하였습니다
이후 함수 단위로 나누기보다는 클래스 단위라는 형태가 나을 것 같다고 판단했습니다. 함수단위로 나누려고 하니 의존성이나 단일 책임 원칙등에 문제가 생길만한 모양이 됐기 때문이죠. 예를 들어 단순히 함수 단위로 나눌때 입력받은 값들이 양수인지 판단하는 함수 자체는 어디에 들어가도 문제가 없지만, 나중에야 생각해보면 검증 클래스를 만든다면 그곳에 들어가야 의존성이 낮아지는 모듈화가 되기 때문이죠.
추가적으로 예외케이스부분을 임의로 정하는 부분도 배웠습니다. 실제 기획에서는 언급안된 제한사항 들이 많습니다. 모든 사항들을 언급할 수는 없기에 일일히 언급할 수는 없지만, 어떤 제한사항 들은 넘겼다가는 문제가 생길 수도 있기에 짚고 넘어가야합니다. 예를 들어 커스텀 구분자에 대해 한번만 사용이라는 부분은 언급이 없지만 이를 기능 명세서에 넣어줌으로서 기획자와 개발자 모두 이를 인지하겠끔 할 필요가 있는것 같습니다
이처럼 요구사항을 받았을때, 비개발자도 이해하기 쉽고 개발에 필요한 단위를 선정하며, 개발에 이르기 위한 목록을 만드는 점을 배웠습니다.
(추가적으로 여유가 되면 다이어그램까지 그린다면 더 좋을 것 같은...! )
2. 좋은 Commit 메시지란? (Commit Convention , diff)
이번 미션에서 깊게 생각해본 좋은 Commit 메시지란 무엇일까? 였습니다.
다른사람이 보기 한눈에 봐도 읽기 쉬운 제목이 먼저 떠올랐는데 이를 위한 AngularJS Git Commit Message Conventions 를 참고하였습니다. 해당 내용에서는 명확히 type , scope , subject 를 통해 기준을 잡고있습니다. 그런의미에서 해당 양식을 따라하는 것 까지는 좋았습니다만...
좋은 Commit 단위란?
아무리 메시지가 좋다고 하더라도 결국은 commit의 내용을 담아야할텐데 문제가 생겼었습니다.
한 클래스의 기능을 구현한 feat 커밋을 편집 하던 중 오타를 발견하였습니다. 해당 내용을 수정하고 feat 커밋에 그대로 작성해야할까요? 아니면 fix커밋으로 새로 만들어야할까요?
보통이라면 생각하지않고 해결한김에 feat안에 넣었을 텐데, 좋은 Commit을 생각하다보니 고민이들었습니다.
(사실은 여기서 추가적으로 원격에 push했냐 안했냐라는 기술적인 고려사항도 포함돼야합니다!만 여기서는 제외하고 생각하겠습니다)
처음에는 fix가 있으니 커밋을 나눠야된다는 생각을 하였습니다. 그러다 곰곰히 생각해봤을때 그렇다면 커밋단위가 너무 세세해지는 것 아닌가?라는 생각에 망설였습니다. 그럼에도 불구하고 썩 깔끔한 느낌이 들지 않아 고민을 하였습니다.
결국커밋 단위로 무엇을 보여주고 싶고 어떤걸 보는가? 라는 근본적인 질문을 하게됐습니다.
커밋의 경우 홈페이지에서 확인해본 결과 보통 diff만을 보여줍니다. 즉 이전 커밋과의 차이점을 보여주는데 그런의미에서 커밋 단위란 보여주고 싶은 것의 단위가 의미가 있을때 나누는것이 맞다라고 생각하게 됐습니다. 그렇다면 fix 커밋으로 보여줄 것이 의미있는 차이인가? 에 대한 질문으로 바꿔본다면 내용 자체는 Validator라는 클래스의 이름이 오타가 발생해 l과 i가 순서가 바뀐 문제였습니다. 만약 오타가 단순히 주석이라던가 display시 표기되는 문자라던가 대소문자 같은 의미면 몰라도 참조해야하는 클래스의 이름이라는 중요한 사항인만큼 이것은 의미가 있다고 생각했습니다. 그렇다면 결론은 fix커밋으로 나누는 것이 맞다. 왜냐하면 이 커밋은 클래스이름 변경이라는의미있는 차이 이기 떄문에.
이런 결과로 커밋의 단위를 그 차이로서 생각하게됐습니다. 나중에 다른사람에게 보여주는 것도 그 의미있는 차이 기준인 커밋을 보여주는 것이 좋은 Commit인것 같다는 나름대로의 기준을 세워보게 됐습니다.