시간 준수, 서로 간 배려 등의 기본적인 사항은 믿고 갑니다.
캠 이슈
항해99를 진행하면서, 캠을 늘 켜놓는 것에 대해서 피로감을 느끼는 크루원들이 많이 계신 것 같고 저 또한 그렇습니다. 제 생각으로는 개발 진행중에는 자율적으로 on/off 하되, 누군가와 대화를 할 때는 짧게 한 두 마디 하더라도 반드시 캠을 켰으면 좋겠습니다. 물론 다 같이 이야기해보고 결정할 문제이구요. 이번에는 1주간이 아닌 6주간 프로젝트이기 때문에 서로 친밀한 분위기에서 진행하는 것이 중요하다고 생각해요. 어떤 말을 하더라도 최소한 캠을 켜고 얼굴을 보면서 소통하는 것이 혹시 모를 불필요한 오해, 감정적인 소모를 막기 위해 좋지 않을까 싶습니다. 여튼 이 주제는 다같이 토론해서 결정해봐요.
실시간 상황 공유
매일 작업 시작 전, 작업 종료 전에 최소 2회 서로 상황을 공유합니다.
1) 어떤 부분을 해결하는 중인지
2) 어느 정도 진척되었는지
3) 문제에 직면해있다면 어떤 문제인지
4) API 문서, 변수/함수 이름, request나 response의 형태 등 상호간 공유해야 하는 정보에 수정사항이 생기지 않았는지
최대한 지연 없이 소통하며 진행합니다.
서버 빨리 열고 실제 환경에서 기능 테스트하기.
- 위 실시간 상황 공유와 같은 맥락입니다. 개발 중 어떤 기능 또는 페이지를 만들었을 때나 특정 문제를 해결했을 때 자신의 로컬 저장소에만 그 결과를 갖고 있다면, 협업의 관점에서는 그 작업은 아예 진행되지 않은 것과 같습니다. 뭔가를 만들었을 때, 뭔가를 해결했을 때 바로바로 업데이트 해서 모두가 확인할 수 있게 합시다. 특히 협업 개발은 절차적인 프로세스를 따르게 되는 경우가 많습니다. 내 작업을 끝내고 업데이트해줘야 자신의 기능을 더 개발하거나 테스트할 수 있게 되는 다른 팀원이 있을 것입니다.
- BE는 최대한 빨리 backend 서버를 엽니다 - FE 에서도 API 테스트가 가능하도록. 모든 API 작성이 완료된 후에 로컬에서만 테스트 하다가 서버를 짠! 하고 연다는 생각 X. 아주 조금의 API라도 기능할 때 서버를 열고, FE 팀원 분들이 프로젝트 진행 중 실시간으로 테스트, 수정할 수 있는 - mock API 등이 아니라 실제 우리 팀의 API를 연결해서 - 환경을 조성합니다.
- FE도 마찬가지로, BE 자체적으로 API 테스트(Postman, Thunder Client 등) 할 때와 브라우저 환경에서 테스트할 때 환경에 따라 코드 동작의 차이가 생길 수 있으므로 FE 배포를 일찍 해주시면 훨씬 수월한 진행이 가능합니다. 모든 페이지가 완성되고 CSS 까지 다 예쁘게 먹인 다임에 짠! 오픈하려고 하지 말아주세요 ㅠ
GitHub
- FE / BE 별개의 repository 사용.
- 각 repository 내에서 branch 이름은 일정 형식에 맞게 정합니다. 분담한 기능 또는 페이지가 담당하는 자원(resource)를 지칭하는 이름으로 짓는 방법이 좋을 것 같은데 다른 아이디어도 공유하고 협의해서 결정하면 좋겠습니다.
예) feature_users / feature_articles / feature_comments
- merge 할 때 반드시 "어떤 브랜치를 어떤 브랜치에 merge 하는지" 확인하고 합니다. 기본 세팅이라면 main 이란 브랜치에 각자의 브랜치를 병합하게 될텐데
"Merge (from) feature_users into main" 입니다. 반대로 하는 경우를 주의해주세요.
- 아래(더보기)는 제가 git 사용하는 방식입니다. 각자 git 사용법은 다르니, 이대로 하지 않으셔도 좋습니다만 만약 git이 헷갈리시거나 자꾸 문제가 발생하신다면, 아래처럼만 하셔도 크게 문제가 생기지 않습니다.
1. 로컬 프로젝트 폴더 설정 및 원격 저장소 연동
1) 프로젝트 폴더에서 콘솔창 실행
2) 로컬 저장소로 사용할 폴더를 설정
git init
3) 원격 저장소의 주소를 설정
git remote add origin "git주소"
git remote add origin https://github.com/alpha-fly/shop_advice_backend.git
4) (원격 저장소에 이미 초기 코드가 있다면)
git pull origin main / 또는 git clone "git주소"
git pull origin main
(or)
git clone https://github.com/alpha-fly/shop_advice_backend.git
(clone을 할 경우 3, 4는 순서가 바뀌어도 됩니다)
2. 자신의 branch 생성하고 동시에 그 브랜치로 이동
git checkout -b "브랜치이름"
git checkout -b feature_users
(로컬 저장소에 자신의 branch를 생성하며, 앞으로 업로드시 이 브랜치를 계속 사용하게 되고, 원격 저장소에도 이 이름으로 된 branch에 계속 push 할 것입니다)
3. 작업물 업로드 하기 - "내 로컬 브랜치에서, 내 원격 브랜치로 업로드"
1-1) git add . (모든 파일을 commit 하려고 할 때)
git add .
1-2) git add "특정 파일 경로와 파일 이름" (특정 파일만 commit 하려고 할 때)
* 보통은 1-1처럼 모든 파일을 commit 하면 git이 알아서 변경사항 있는 파일들만 commit하게 해주지만, 같은 파일을 동시에 2명 이상이 작업하는 경우가 있다던지 특이사항이 있을 땐 지금 올리려고 하는 특정 파일만 골라서 commit 하는 것이 안전할 수 있습니다.
* 아래 예시와 같이 여러 개의 파일을 지정할 수도 있습니다. 경로는 현재 폴더 기준입니다.
git add app.js routes/users.js models/user.js
2) git commit -m "커밋 메시지"
* 커밋 메시지는 반드시 작성해주세요. 형식화된 커밋 메시지를 사용하면 더욱 좋겠습니다...만 프로젝트가 진행되면서 이 부분까지 신경쓰기 어려워진다면, 형식은 뒤로 하더라도 어떤 수정/추가 사항을 commit 하는지 반드시 작성 부탁드립니다.
git commit -m "ADD: 회원 탈퇴 기능 추가"
git commit -m "FIX : 예약기능 오류 수정 - 변수명 변경 및 data type 설정"
3) git push origin "나의 브랜치 이름"
* 일단 나의 branch에 push한 뒤에, 검토를 거쳐 github 웹페이지에서 merge 합니다.
* main 브랜치에 push 바로 하는 것 노노...
git push origin feature_users
4. 병합하기
merge는 커맨드 입력보다 직접 github 웹페이지에 접속해서 하는 것이 쉽습니다.
아래와 같은 절차로 해주시면 됩니다.
단, Automatically Merge가 안되고 conflict가 발생했다면 일단 중지, 팀원을 호출하시고 같이 해결해주세요.
5. 내 로컬 브랜치를 메인 브랜치와 동기화 하기 (git pull origin main)
- 사실 현업에서 git을 사용하는 방식은 현재 저희와 많이 다른 것 같습니다. branch를 일시적으로만 사용하고, 목적한 기능(feature)이 구현되면 병합 후에 해당 브랜치를 삭제하는 식으로...
- 여튼 우리는 branch를 잘 삭제하지 않고 유지하면서 개발하기 때문에 중간중간 github 원격 저장소의 main브랜치와 내 로컬 저장소의 코드를 동기화 해주는 것이 필요합니다. 본래는 자신의 결과물을 push 하기 전에 먼저 main 브랜치를 pull하는 것이 바람직합니다만, 이러다가 (드문 경우이지만) 누군가 내 코드 부분을 조금 건드렸다던지 해서 자신이 작업한 결과가 작업 전으로 돌아가버리면 귀찮아지기 때문에, 적어도 자기 결과물을 업로드하고 병합한 이후에는 pull 한번씩 꼭 땡겨주세요.
'항해99 > 항해99 실전 프로젝트' 카테고리의 다른 글
| 기술매니저님 면담 질문 (0) | 2022.07.20 |
|---|---|
| 항해99 실전프로젝트 2주차 WIL (0) | 2022.07.10 |
| 항해99 실전프로젝트 1주차 WIL (0) | 2022.07.03 |
| 220623 리더/부리더 온보딩 세션 (0) | 2022.06.23 |