유즈 케이스?

시스템의 동작을 사용자의 입장에서 표현한 시나리오이며, 시스템에 관련된 요구사항을 알아내는 과정. 소프트웨어 개발 프로세스중 개발을 위한 소프트웨어의 기능을 개략적으로 설명이 가능한 방법이다.

유즈케이스 관련 이미지들을 검색해보면 여러 선과 도형이 이어져서 대략 내가 만들려고 하는 프로젝트가 어떤 기능을 하는지, 그리고 사용자가 기능을 어떻게 사용하는지를 알 수 있다.

유즈 케이스를 그리는 수단으로 diagrams.net을 사용할 것이다. https://www.diagrams.net/

diagrams.net과 깃허브를 연동할수 있게 해보자. 사이트에서 start를 누르면

이렇게 저장할 장소를 고르라고 나오는데 이때 github를 선택하면 된다. github 프로젝트 디렉토리에 폴더가 없어서 폴더를 추가한뒤 그곳에 유즈케이스를 넣을 것이다.
이 작업은 gitkraken에서 터미널로 진행한다.

참고로 디렉토리만 만들면 변경이 적용되지 않기 때문에 파일을 추가해서 push하는 것이 좋다.

파일 생성 명령은 fsutil이다

fsutil file (적당한 파일이름과 형식) (length)

이런식으로 파일을 생성하고 난 다음 깃크라켄에서 모든 변화를 스테이징 하고 커밋한다.

커밋하기 전에 현재 브랜치가 메인에 있기 때문에 feature를 시작해야한다.(개발은 feature 브랜치에서 이루어지기 때문에) 이를 위해서 프로젝트로 돌아가서 유즈 케이스 작성하기의 이슈를 열었다.

이슈의 번호는 4번, 이걸 이용해서 브랜치를 제작한다. 내용의 변화가 존재해도 쉽게 브랜치 생성 및 위치변경이 가능하게끔 보이지않게 명령어를 실행해서 개발자가 따로 작업할 필요가 없는 것이 깃 크라켄의 장점이다.

커밋하기 전에 커밋메세지를 작성한다

커밋메세지를 작성하는 룰은 협업을 하는 조직마다 다양하기 때문에 그에 따라 맞춰서 작성 할 것.
변경 내용을 자세히 작성하는것은 좋은 자세다. 친절한 문서는 언제나 환영이니까. 단, 장황하게 작성하지 말고, "왜?"를 중심으로 작성하는 것이 좋다. 프로젝트를 진행하다가 마주치면 엥? 이거 더미파일인데 왜만듦? 이럴 수 있기 때문이다.

이대로 커밋을 진행하고 diagrams.net으로 가서 해당 디렉토리를 경로로 삼아 유즈케이스를 만든다.

유즈 케이스 관련 그림은 UML에 대부분 있으니까 사용해서 제작할 것.

대략적으로 만든 유즈케이스에서 점선이 존재하는데 각각 include(포함관계)와 extend(확장관계) 라고 적혀있다.
include는 해당 기능은 상위 항목에 포함되어있다 라는 뜻이고, extend는 상위항목에서 발생하는 분기중 하나라고 보면 된다. 사용자와 유즈케이스는 대부분 실선(연관관계)를 나타내고, 유즈케이스끼리는 점선(include 혹은 extend)으로 나타낸다.

유즈케이스를 그리고 github으로 전송하는 과정에서 diagram.net에서 빈 파일을 하나 저장한것이 있어서 그 파일의 커밋을 지우려고 한다.

선택된 항목에는 제목 없는 다이어그램이라는 파일이 document로 보내진 상태이다. 해당 항목을 우클릭하고 revert commit을 클릭하면 해당 커밋을 되돌리는 커밋이 나타난다.

이때 커밋의 메시지에 세부내용을 추가해주면 좋다(왜?를 중심으로)

유즈 케이스를 만들었으니 pull request를 해서 추가하는 것까지 진행한다. 개발 작업을 마지고 push했다면 깃허브의 pull requests 항목으로 가면 request가 왔다는것을 알 수 있다.

이런 식으로. 노란 창에 나타난 버튼을 누르면 변경된 항목을 보여주고 코멘트를 작성할수 있다.

확인한 다음에 create pull request를 누르고 최종 화면으로 넘어간다.

이제 merge pull request를 누르면 끝

이렇게 remote 에 남아있는 feature 브랜치는 제거하는 것이 좋다. 혹시라도 '나중에 되돌려야 하니까 지우면 안되는거 아니야?' 라고 생가할수 있지만, 손쉽게 되돌릴 수 있기 때문에 걱정안해도 된다.

브랜치가 사라진다고 해도 작업내용인 노드가 사라지는 것이 아니다!

유즈케이스 작성 끝! 다음엔 api 설계다.