브렌쏭의 Veritas_Garage

업무의 일환 :: 기능 명세, ERD 그리고 Git Branch(조금) 본문

[Project_만들다]/[Project_자아내다]

업무의 일환 :: 기능 명세, ERD 그리고 Git Branch(조금)

브렌쏭 2022. 5. 6. 18:00

모든 일은 작업이고 모든 작업은 기록되어야 함이라, 그것이 미래에 좀더 효율을 높이고 혹여 있을만한 상황을 생기지 않게 하기 위함이라.


모든 것은 결국 잘 협업하기 위함이다

프론트의 일이 무엇이고 백엔드의 일이 무엇인지 한없이 그레이에 가까운 회색의 영역에 들어서면, 소통 외에는 그 가름을 나눌 방도가 없다.  그리하여 작업에 들어서기 전에 개발 명세서를 만들고 ERD를 그려보고, 다이어그램도 그리고 하는 것이다.

1.  기능 명세서 , 개발 명세서

일단 기획이 되고 디자인이 뽑힌다

디자인이 나오면, 이제 프론트엔드는 열심히 만들기 시작하고 백엔드는 놀면 안된다. 해야할 일들이 있다. 

많이 쓸수록 힘들지만 더욱 편해질 것이다

서류작업을 시작해야한다.

열씸히!

API명세서의 경우 독립적인 서류로 만들수도 있고, 기능과 구현의도는 명확하게 파악하고 있어야 하므로 혼자 섣불리 재단하지 말고 아는 사람 (AKA 기획) 에게 물어봐야 한다. 

개발 명세서를 바탕으로 ERD를 준비하면 된다

2. ERD

열심히 만들수록 후에 일이 줄어든다...그리 믿어야한다.

파이프라인 or ERD (tistory.com)

 

파이프라인 or ERD

자그마한 미니프로젝트를 진행하면서, 간단한 데이터 파이프라인을 그려보았다. 특이하다거나 기능이 많다던가 하는 구조는 아니므로, 간략하게 파워포인트로 만들어보았는데 나쁘진 않은거

veritasgarage.tistory.com

그렇게 열심히 일을 하고 나면 이제 필요한 API, 기능들이 몇개인지, 어떤 테이블에 어떤 칼럼이 필요할지, 어떤 관계를 맺어야 할지, 중복되는 기능들은 어디서 쓰이는지, 서서히 윤곽이 잡혀간다. 

이제 윤곽을 구체화 시키기 위해서 데이터베이스의 바탕을 ERD로 작성하고 테이블을 만드는 것이다.

3. GitFlow

굳이 따지자면 깃과 깃허브를 사용하는 워크플로우 중 하나이지, 하나의 기능이나 그런것은 아니다. 문제없이 프로젝트를 마치기 위한 살얼음걷기 기술의 최신 버젼쯔음 되겠다.

깃플로우를 검색하면 30번 이상 보게 되는 그 이미지

일단 마스터에는 못올린다. 권한도 없거니와 제정신이냐 네놈!

겸손하게 Pull을 하지 않겠사옵니까? 하고 리퀘스트를 보내고 결재가 된다면 다음 기능을, 취소당했다면 다시 보완해서 다시 결재를 받는 것이다. 기본적으로는 어디서나 볼 수 있는 회사원의 기획안 루틴이다.

3-1. Forking-Repository

각자 회사의 레포지토리에서 자신의 깃허브로 포크를 한다. 그리고 거기에서 자신의 일을 하는 것이다. 푸시와 커밋은 자신의 레포지토리에 하면서 작업을 이어나가다가, 완성이 되면 PR을 하는 것. 

그리고 나면 회사의 레포지토리에서 merge가 된 (새로운) origin을 다시 풀 해서 작업을 이어나간다. 

git pull upstream `/회사 레포지토리/`

회사는 자신의 레포보다 한단계 위에 존재하므로, pull origin 이 아니라 pull upstream을 해야 한다.

다소 정신이 없어보이나, 정신이 없는건 정상이다

이때 동일한 파일을 다른 사람이 같이 수정해서는 안된다. 정확히는 같은 상황에 푸시를 하면 안된다. 

동일기능은 같이 개발하지 않습니다

언제나 개발자란 서로 조심하며 독립적인 기능들만 개발하는 것이 신상에 좋다. 안전하고 타인의 코드도 제 3자의 시선으로 온화하게 리뷰할 수도 있다. 물론 공통으로 사용되는 기능들이 무조건 존재하므로, 이때 공통사용 기능들은 가장 시니어 개발자가 맡아서 처리하게 된다. 무서워.. 언제나 피해여부와 변경여부를 체크하며 지뢰를 밟거나 설치하지 않도록 조심 또 조심

++ 머지가 아직 되지 않은 기능과 의존성을 가지는 기능을 개발하면 안된다. 선후관계를 잘 생각해야한다.

컨닝페이퍼

만드는 단위단위를 전부 서로 영향이 없도록 개발하는 것이 좋다. OOP아니겠는가. 사실 이제와 생각해보면 OOP는 깃관리를 편하게 하기 위해서 만들어진 개념일지도 모른다.

컨닝페이퍼 2

Pull Request를 보내는 것도 그렇다. PR을 보내는 그 단위도 독립적이어야한다. 안그러면 선행 PR이 닫히면 줄줄이 닫힐 뿐이다. 

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그 (woowahan.com)

 

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합

techblog.woowahan.com

 

Comments