목표
- 파트별 개념 파악
- 파트별 테스트 통과
이번주 작업
alarm clock
- 개념 학습
- 테스트 코드, 요구사항 파악
- 테스트 통과
priority scheduleing
- 개념 학습
- 테스트 코드, 요구사항 파악
- 테스트 통과
priority donation
- 개념 학습
- 테스트 코드, 요구사항 파악
- 테스트 통과
MLFQS
- 개념 학습
- 테스트 코드, 요구사항 파악
- 테스트 통과
발표 내용
의도적으로 sema_up에서 value를 증가시키기 전, yeild를 호출하여 원자성을 깨도록 만들었다. 그러나 해당 테스트에서는 문제가 생기면 안되지만, 실행이 안되는 문제가 발생했다.
그래서 원인을 찾아보았더니, pintos를 진입점인 main 함수쪽에서 문제가 발생함을 발견했다. 실행하면서 sema_up을 사용하는데, 이때 yield가 되면 메인 스레드가 무한히 대기상태에 빠지는게 원인이였다.
진짜 문제는 테스트 내부가 아닌, 외부에서 발생함을 발견할 수 있었다. sema를 사용하는 다른 테스트에서는, 테스트 내부에서 메인 스레드가 무한 대기상태에 빠져 외부에 문제가 있다는 생각을 하기 어려웠다. 이해되지 않는곳을 파고들다보니, 남들이 찾지 못한 부분을 알아낼 수 있었다.
회고
Keep
- 개념 이해 확인차 핀볼로 발표자를 발표 직전에 결정
- 개념과 구현을 나누어 진행 -> 진도를 놓치지 않을 수 있었다.
Problem
- Pintos 과정 팀플 부족
Try
- 이해를 돕는 주석 추가 (한글로 작성)
- 의사 코드, 코드 리뷰 시간 증가
- 구현 위치, 방식, 리팩토링 진행
- git merge, conflict 문제 적극 해결
Feedback
Pintos 취지를 잘못파악했었다. 운영체제 내용을구현해보면서, 깊이 있는 학습을 목표로 잡았었다. 그러나 코치님들은 협업 과정에서 문제점, 건설적 대화 경험을 원하셨다. 의도한 목표는 협업에서 이루어지는 방식을 배워보라는것이였다.
회의를 통해 협업을 왜하는지, 어떤것들을 얻어갈 수 있는지에 대해 고민했고, 아래 결론이 나왔다.
- 협업은 개인을 넘어선 규모의 작업이 가능하다. 고로 협업을 해야한다.
- 코드 리뷰를 통해 팀에게 가장 좋은 코드를 선별, main 브랜치로 머지, 그 과정에서 git conflict 해결 능력 함양
- 코드 리뷰가 쉽도록 주석, 코드 리팩토링, 코드 작성 근거 마련이 필요하다.
유사 커피챗을 진행한 동기말을 들어보면, 의도한 바가 비슷하다는걸 알 수 있었다. 인턴시절에도 이전 사람의 코드를 읽고 리팩토링하는데 애먹었던 기억이 난다. 네이버 부스트캠프때도 다른 사람 코드를 자주 봐야하고, 빠르게 이해하고, 피드백을 주는 활동을 매일 진행했었다. 생각해보면 개발 능력이라는게 구현하는것만이 전부가 아니겠구나 싶다.
코치님들이 팀플을 활성화시키기 위해 다음 조건을 거셨다.
1. 매일 1회 이상 머지
2. merge한 코드를 베이스로 진행
3. 모두가 이해해야 진도를 나가기
팀 진행도는 모두가 코드 구현한 곳까지로 결정된다. 따라서 먼저 구현한 사람이 있다면, 다음 학습을 진행하기 위해서는 학습용 레포를 따로 만들어서 진행하기로 했다. 그리고 팀 진행도를 올리기 위해서, 쉽고 적절하게 설명하는 능력도 필요해보인다. 네이버 부스트캠프때는 해봐도 잘 몰랐었는데, 이번에는 전과 다른 경험과 성장이 있길 바란다.
피드백을 반영해, 아래와 같이 팀이 운영될 예정이다.
학습 정리
