TDP 2차 회고록 (2021.10.20)

🚧 Keep

---

📌 느슨하지만 Deadline 하지만 Deadline = Deadline

개발자는 끈기의 아이콘, 그 누구에게도 내 작업 영역을 뺏길 수 없다!

🙋🏻 "조금만 더 하면 될 것 같아요!"

🤗 "네! 조금 더 힘내요! 파이팅! "

🤦🏻‍♂️ "조..조금만 더"

🤔 "흠.."

 

협업에 있어서 가장 중요한 부분은 "실력", "loc"가 아니에요!

 

📈 빠르게 성장하는 개발자의 Uncheck_list!

◻️ 혹시 내가 rush hour, deadlock 제공자!?

◻️ 회의 시간은 내가 맡은 부분 브리핑하는 시간이지!

◻️ Convention? 귀찮아 내 스타일!

 

우리 팀은 짧은 deadline, 반납 횟수를 반영하며, 반납 기간을 "독촉"하기 위해 찐한 관리로
매일 아침 To do list 점검했다.

---

📌 우리는 Back-end-warriors

• 어차피 수많은 Template, Cascading Style Sheets 섞어 쓴다.
• front는 거들 뿐..

---

📌 Git 의 유능함에 Cheers!

Github 참 많은 기능을 이용했다.

1. Project 탭에서 Kan-ban board 형식으로 Task 관리
2. Milestone 이용한 더 작은 Task 관리
3. PR tab 이용한 Branch 관리
4. Git Action tab 이용한 자동 배포
5. Discussions
6. Wiki
7. Code review
8. 업데이트 예정 : Git Guardian

---

📌 Action else View

• 1차 poc프로젝트 때는 기능을 기준으로 Task는 짧고 빠르게 개발을 진행 했다면, poc 이후 2차 프로젝트 때는 Page 혹은 View 기준으로 Task 분할
• poc 에서 탈락한 기능을 위주로 Main Skill labeling
• 개발 과정에서 필요한 세부 Detail 에는 Sub Skill

---

📌 항해

프로그래밍 개발 방법론에서 애자일 이던 폭포수 에서도 Project owner와 Project Manager는 분리되어 있는데, 이런 소규모 프로젝트에서는 PM도 PO도 위태로운 핸들링이라고 생각한다.

→ 자기 주도적 학습을 이용한 팀원 주도 개발 방법론을 과연 어떤 방향으로 이끌어 갈까.

⇒ 회의 참여도, Reaction는 좋았다, 하지만 Idea가 항상 수동적이다.

⇒ 능동적인 회의 참여는 100개의 나뭇가지의 사과나무에 나뭇가지를 인원수를 곱한 나뭇가지가 생성된다.

---

 

🤔 Problem

---

협업 관련

1. 코드리뷰 과제 마감에 밀려 느슨해짐
   • 배포 관련 과제의 업무량에 대한 판단 미숙
2. 협업이라고 하면, 동의만 하는 것이 아니라 단점 얘기하기, 주제에 대해서 반대되는 의견을 말하는 것도 필요하다.
   • 동의만으로 진행되는 회의는 좋은 결과를 낼 수 없음, 적극적인 의견 피력이 필요함
3. 팀프로젝트 구현할 때, 중요한 것을 먼저 하지 않고 sub issue를 한 것
   • 공통되는 부분들을 빠르게 처리해야 서로 같이 작업을 진행할 수 있음
   • 팀원으로써 프로젝트의 방향성과 우선순위는 늘 파악해야함
4. Convention 문서 만들고, 거기에 맞게 코드 작성하지 않음
   • 컨벤션은 정해놓은 약속과 같은 것이며 이에 따라 작업해야 혼선이 생기지 않음
   • 따로 코드를 수정해야 하는 번거로움과 작업물을 확인하기 어렵기에 효율성을 떨어뜨림
5. 그리고 Convention 문서에 추가한 것 있으면 알려주기 및 자주 확인이 필요함
   • 수정하고 나면 바로바로 알려주어야 Merge 등 통합할때 큰 문제가 생기지 않는다.
   • 노션등을 활용하여 충분히 전달 가능
6. Git Pull 하지 않는 것
   • 자신의 브랜치에 자신의 진행상황과 계속해서 일치시켜야 하며 다른 사람들의 작업량이 공용 브랜치에 머지 되었을때 따라서 나의 작업물도 다른 사람들에게 전달되어야한다.

---

기술 관련

1. mongodb의 깃배쉬를 통한 연결이 미숙한 점
   • 배포 전 미리 mongodb 연결방법을 숙지하고 로컬 등 서버에 연결하려는 고민을 미리 했어야함
2. 서버 배포할 때, 늦게 시작해서 제때 끝내지 못함(Github Action 자동배포)
   • 서버 배포 마감에 쫓겨 Github Action 자동배포가 어려워짐
3. 설정값을 깃에 노출
   • 보안에 대한 준비를 나중으로 미루지 않는 습관이 필요함

---

 

🏃🏻 Try

---

📝 Convention에 맞게 코드를 작성하지 않는 것에 대한 해결책

• Convention이나 Logic에 관련해서 수정한 부분을 그때마다 Convention 문서에 작성하기
• 회의 전에 당일 회의록에 미리 쓰기
• 변경사항을 회의 때, 꼭 공유하기

---

💥 Git pull 자주 하지 않아 충돌 생기는 것에 대한 해결책

• 다른 사람이 PR한 내역을 test_box 브런치에 병합이 되면, 각자 브런치에서 pull 하기

---

🔎 문제 해결을 빠르게 하기 위한 방법

• 문제 해결하기 위해, 찾아보고 시도해보고 질문하기
• 질문할 때, 문제점에 대해 명확히 이야기하고, 문제를 해결하기 위해 시도해 본 것을 이야기 해주기

---

🔒 보안

• 배포할 때, 설정값을 노출하지 않기
  • 환경변수를 이용한 설정값 관리한 것을 유지하면서, 설정값들을 추가하며 진행하기
  • Git Guardian 사용하기

---

✔️ 같이 가기 위한 List

• important function에 먼저 집중하기 👉🏻 sub issue는 important function을 끝내고 처리하기
• 회의 할 때, 무조건적인 동의를 하는 것이 아니라, 단점도 얘기하기
• 해당 주제에 대해서 다양한 의견(ex. 반대되는 의견 등)을 능동적으로 얘기하기
• 혼자서 될 때까지 하는 것도 있지만, '앗 이것 조금만 하면 될 것 같은데...' 해도
  막히는 것을 회의 때 공유하기  → 러시아워 발생하지 않기 위해!
• 코드 리뷰 제때 하기! PR 올라오면, 회의 끝나고 난 뒤 바로 코드 리뷰부터 시작하고 개발하기

---