[TIL 23.01.16 -17] 스파르톤

오늘은 (사실 어제부터 17일까지) 무박 2일로 스파르톤을 진행하였다.
여차저차해서 마무리가 되었고, 이 부분에 있어서 회고 겸 문제가 있었던 점들
그리고 TIL 을 2일차를 한꺼번에 정리하려고 한다.

3줄요약

• 확실히 무박 2일은 조금 힘들었다 그 뿐만 아니라 팀적인 소통도 잘 안되는 것 같아서 아쉬웠다.
• 아직 내가 많이 부족한 것을 느꼈다. 앞으로 잘 정리하면서 (즉각 즉각 모르는것들을 메모로 적어야 겠다)
• 오늘 한 내용들중 간단하게 적고 오늘은 가겠다.. 너무 힘들어잉

Q1. 정확하고, 오류가 잘 안나게 되는 git 협업 방법

Git Strategy

• Commit naming
  (참고링크1)
  👉 Add : 추가한 기능 #issue_num
  👉 Del : 지운 기능 #issue_num
  👉 Feat : 만든 기능 #issue_num
  👉 Fix : 고친 기능 #issue_num
  

• PR naming

  👉 Feat : 커밋들 요약
  

• Branch naming

  👉 FE/develop

  👉 BE/develop

  👉 FE/feature/login

  👉 BE/feature/login
  

• Issue naming

  👉 Feat : 추가할 기능

  다음과 같이 작업을 하면서 협업의 능력을 올려놓았다. 앞으로 이 부분은 조금씩 다음 팀원과 맞춰갔으면 좋겠다.

Q2. 와이어프레임은 어떻게 짰어?

https://miro.com/app/board/uXjVPyeeMwo=/

다음과 같이 와이어 프레임을 작성했다.

Q3. API 는 어떤 것을 적용했어?

• 다음과 같이 API 를 적용했다.
• 사실은 GET 도 적용을 하려고 했지만, 이에 대해서는 우리 프로젝트에서 항상 name이라는 값을 받아와야 했기 때문에 이는 전부 POST API 를 사용할 수 밖에 없었다.

Q4. Trouble Shooting

• Server 낭비 Issue

  • Problem.

    • 다음과 같은 문제는 선택지를 고를때마다, result_list의 값들을 If 문으로 선택적으로 증가시키는 알고리즘이다.
    • 하지만 이때, 질문을 할때마다 전체 userlist를 돌면서 비교하는 것은 비효율적이고 서버 낭비가 된다.
    • 지금은 코드가 간단하지만, 나중에 있어서 코드의 양이 증가하거나, user_list 가 많아질수록 이는 더욱더 비효율적이고 값을 처리하는 시간이 오래 걸릴 수 있다.

  • Sol.

    • 첫번째로 들었던 생각은 for 문을 통해서 name 변수 하나의 값을 먼저 찾은뒤 이에 대한 result_list 의 값을 빼내는 것이다.
      • 이 경우에는 알고리즘 자체에서는 달라지는 것은 없지만, 코드 간편화가 가능하므로 도전해볼만 하다.
    • 두번째로는 frontend 쪽에서 먼저 총괄적으로 결과값을 모았다가 이를 back쪽에 넘겨줘서 한꺼번에 저장을 하는 것이다.
• Method 사용
  • Problem
    • result의 최댓값을 찾는 과정에서 for문과 if 문으로 최대값을 찾으려고 했지만, 이는 앞서 말한 것처럼 너무나도 비효율적이기 때문에 다음과 같이 max method를 사용해 최대값을 구하는 것으로 바꾸었다.
      
  • Sol.
• 형식자 오류
  • Problem img_result_dic 에 각 숫자 string 에 맞는 url을 반환해야하는데, 여기에서 오류가 발생했다.

    url_list = img_result_dic['result_index']

    다음과 같이 result_index에는 내가 원하는 숫자 string 값을 넣어주려고 했는데, 형식자 오류가 계속해서 나왔다.
    
  • Sol.

  마치며...

  사실 지금 너무 피곤하기 때문에, 오늘까지는 쉬고 내일부터는 JAVA에 관한 내용들을 저장하고 나중에 더 작성하겠다.