221216 TIL 미니프로젝트 1

오늘의 한일

1. S.A (Starting Assignment) 작성

2. 팀 정책서 작성

3. Frontend meeting

4. Git debugging

 

1. S.A (Starting Assignment) 작성

이번주차의 첫 시작인 오늘은 백엔드와의 첫 협업이고 전문적이고 체계적인 계획 작성법을 경험해 볼수 있어서 좋았다. 

1. 프로젝트 설명
   - 필요한 정보: 프로젝트 이름, 간략한 설명
   - 프로젝트의 주제를 계획하는 단계이며, 이번 주차는 우리가 구현할 수 있는 기능에 맞추어 주제를 선정했다.
2. 와이어 프레임 (Wire Frame)
   - 필요한 정보: 페이지 설정, 사용자에게 보여질 화면의 대략적인 구성, 기능, 정보 등이 들어갈 위치, 내용 등등
   - 사용한 도구: figma
   - 특이사항
      들어갔으면 좋을것 같은 기능 혹은 정보 등을 자유롭게 얘기하면서 함께 보며 화면을 구성하였다.
3. API 명세서
    - 필요한 정보: 분류, 기능, Method, URL,  request, response, 담당, 비고
    - 각 정보에 대한 설명:
       분류: 페이지 등을 기준으로 한 대분류이다.
       기능: 대분류 안에서 나뉘어지는 세부적인 기능이다.
       Method: 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능을 말하는 CRUD (Create, Read, Update, Delete)를 명시. 어떤 라이브러리를 사용하는 가에 따라 Post, Get, Put/Patch, Delete 등으로 표시하기도 한다. 
       URL: 서버컴퓨터에서 data를 가져오는 경로를 말한다. 백엔드에서는 이대로 설정을 하는 것이 중요하고 프론트에서도 이 경로를 통해 데이터를 가져온다. 변경이 있을경우에는 팀원들에게 꼭 알려야 한다.
       request: 클라이언트에서 정보를 입력받아 서버로 보내줄때 보내주어야 하는 정보를 나타낸다. Create과 Update의 경우에만 입력해준다.
       response: 서버에서 클라이언트로 리턴해주는 정보를 나타낸다. 성공/실패시 (http error code로 확실하게 표시)로 나누어 명확하게 표시해준다. 클라이언트를 만드는 프론트에서도 기능 구현에 필요한 정보가 무엇인가를 생각해보고 백엔드에 요청한다.
       담당: 각 기능의 담당자를 frontEnd와 backEnd로 나누어서 입력한다.
       비고: 특별히 참고할 만한 사항을 넣는다.
    - 예시 사진
   
   

   4. 주간계획
       목표한 계획을 일 단위로 (프로젝트마다 상이할 수 있음) 가능한 구체적으로 공통,프론트엔드, 백엔드로 나누어 작성한다.

 

참고: 항해99 10기 e반 2조 미니프로젝트 팀노션

https://www.notion.so/2-SA-78341ee516e946bfa7cbb0e7c158f94f

2조 미니 프로젝트 (SA)

 

2. 정책서 작성 

• 일반적으로는 웹 사이트를 만드는데 필요한 모든 기능과 세세한 합의 사항을 글로 정리해 놓은 '기능 정의서'와 웹사이트의 운영 기준을 정리한 '정책 정의서' 를 모두 작성한다. 그러나 이번 프로젝트는 미니 프로젝트이므로 포괄적인 범위를 포함한 정책서를 작성하였다.
• 이를 통해 디자인, 퍼블리싱, 개발 단계에서 각 담당자들은 기능 정의서를 보고 어떤 작업이 필요한지를 가늠한다
• 정책서에서는 각 페이지 별로 분류한 후에 필요한 기능들을 나열하고 그에 필요한 세부사항을 함께 논의하고 합의하여 정한다.
• 필요한 정보
  • 번호(분류)
  • 정책 코드
  • 정책명: 구현할 기능의 이용 단계로 구분하여 이름을 입력한다.
  • 세부 항목: 해당 정책의 하위 단계를 입력한다.
  • 소개: 정책 결정이 필요한 사항을 입력한다.
  • 정책 정의: '소개'항목에 대해 결정한 정책을 상세히 정의한다.
    예시:
    최소조건
    - 첫글자는 대소문자로
    - 5자 이상 9자 미만
    에러메시지 표시
    - input box 아래 표시된다.
    입력값
    - [대소문자,숫자]
    에러메시지
    - 중복된 아이디입니다.
    
• 예시 사진
  
  

 

3. Frontend meetin

결정사항

1. 업무 분담
   코드가 중복되지 않도록 비슷한 기능을 묶은 페이지 별로 업무를 분담하였다.
2. 폴더 구조 설계
    - 논의할 내요: 필요한 패키지, 폴더 구조
    - 밑에 예시 사진 참고
3. Git
    - 논의할 내용: branch 구조, 작업 순서, 설정사항
    - 세부 사항
      (1) branch 구조:
         1) 어떤 branch를 만들고 각자 작업할때 어떻게 pull과 push를 할것인지 논의 한다.
         2) 예를 들어 main-dev-frontEnd branch 구조를 만들고 frontEd 팀원들을 frontEnd branch에서 branch를 생성하여 각자 작업한다. 
      (2) 작업순서:
           1) git에서 pull과 push, merge 등을 하는 순서 등을 정한다.
           2) 예를 들어 작업이 끝나면 frontEnd branch에 각자 merge하고 frontEnd와 backEnd는 dev branch에 merge 하여  test running 한다. 그 후에 마지막으로 main에 merge하여 deploy 한다.
           3) issue에 적을 내용, commit message에 적을 내용 등을 논의한다.
           4) 좋은 커밋 메세지의 예시
   https://cocoon1787.tistory.com/708
      (3) 설정사항:
            1) main branch에 push 하기 위해서는 모든 팀원의 동의가 필요하다. frontEnd branch 에 push하기 위해서는 두사람이상의 동의가 필요하다 등을 정한다.
4. Theme
    - frontEnd가 디자이너는 아니지만 미적감각을 위한 UI 설정을 하였다.

[Git] 좋은 커밋 메시지 작성법

폴더 구조 예시

4.Git debugging

문제 정의:

• 소문자 이름으로 생성한 파일의 이름을 대문자로 바꾸었는데 인식하지 못하고 branch를 checkout 하면 다시 소문자로 돌아간다.
• branch 'fr-tg'에서 상위 branch인 branch 'frontEnd'를 pull 해오려고 했으나 에러코드가 발생
• 에러코드: 기억나지 않는다.

문제 원인 추론:

• 작업중에 pull 을 제때에 하지 않아 파일이 꼬인것 같다.
• VScode에서 source control을 사용했는데 제대로 작동하지 않았을 수도 있다.

해결 시도:

1. git에서 대문자 파일을 인식하도록 설정 변경
2. 브랜치 삭제후 재생성
3. local repository 삭제후 clone

해결 방법: 

1. git에서 대문자 파일을 인식하도록 설정 변경
   1. git은 저장된 파일명과 일치하는(대소문자만 다른) 파일을 저장했을 경우 변화를 인식 못 한다.
   2. 해결 방법 2가지
      1. 터미널에 git config core.ignorecase false 입력하여 대소문자를 구분하도록 설정 변경
      2. 다른 기호를 붙여서 변경한 뒤, 원래 의도하고자 한 대로 다시 변경을 해주어 인식하도록 유도
2. local repository 삭제후 clone
   
   1. branch는 git hub website에서 직접 삭제해주었다.
   2. 새로 원격 repository를 clone해 주었다.
   3. 이때 지금까지 작업했던 내용들을 따로 복사해주어야 한다.
   4. 클론한 이후에도 작동이 안 되다가 갑자기 되었다.... 왜 그런지 모르겠다... 코딩을 하다보면 이런 일이 참 많다. 이 왜 되지? 이게 왜 안되지? 이제는 잘 몰라도 하다보면 될것만 같은 생각이 든다. 코딩이야 말로 믿음이 중요하다.
3. 이제부터는 터미널 명령어로 작동하는데 익숙해지도록 하자 그게 에러가 없는것 같다.
   1. 기본적인 명령어 정리
      1. git add . : 변경된 파일들 staging
      2. git commit -m "commit message"
      3. git push origin master : master branch에 push 한다.
      4. git status: 
      5. git branch -v: 로컬 branch의 정보를 마지막 커밋 내역과 함께 보여줌
      6. git branch -a: 로컬/리모트 저장소의 모든 branch 정보를 보여줌
      7. git branch test1: test1 branch를 생성한다.
      8. git checkout test2: test2 branch로 checkout한다.
      9. git branch -d origin test1: test1 branch 를 삭제한다.
      10. git pull origint master: master branch의 변경내용을 pull 해온다. 다른 branch 에서도 가능하다.
   2. git web에서 하는 안전한 merge 방법
      1. Pull requests 에서 new pull request 클릭
      2. Compare changes 에서 compare: 와 base: 를 변경
         compare에서 base로 merge가 되는 것이다.
      3. Create pull request
      4. 실행한 다음에 팀원들에게 merge 사실을 알리면 팀원들을 pull로 파일을 불러온다.