회고

24.02.02 진행

회고 방식: AAR 회고

참고자료: https://brunch.co.kr/@pletalk/61

1. 의도한 결과는 무엇이었는가(초기 목표) ?
2. 실제 어떤 일들이 일어났는가(현실) ?
3. 계획과 실제 결과의 차이는 왜 발생되었는가(배운점들) ?
4. 지속, 개선 혹은 포기할 것들은 무엇인가, 배운 것들은 무엇인가(목적) ?

1. 초기 목표 - 의도한 결과는 무엇이었는가?

🦊 원석

🦊 : 열심히 웹서브 만들기 (2주 구현 + 1주 테스트)

• 객체지향을 열심히 활용해보자.
• 설계도 열심히 해보자.
• C++98 검사를 github actions를 이용해 해보자.

🐶 정민

🐶 : 블랙홀이 끝나기 전까지 웹서브 통과하기

• 데일리 스크럼, 회의록 작성하기

2. 현실 - 실제 어떤 일들이 일어났는가?

🦊 원석

🦊 : 열심히 웹서브를 만들었다. (기간은 예상과 비슷하게 됐다)

객체지향을 잘 살리기 어려웠다.

• 역참조, 클래스 분리x 등.
• 하나의 클래스에 코드가 너무너무 많았다.
  • 멤버변수 추가할때마다 복사생성자, 대입연산자 추가 너무 힘들어..
• 중간 이후부터는 반쯤 포기하고 왕왕 구현했다..
• builder 나눈건 나름 만족한다.
  • 새로운 요구사항에 대응하기 좋았다.

설계는 나름 했지만, 그대로 가진 못했다.

• 설계 단계에서 생각하지 못한 내용이 너무 많았다.

kqueue가 BSD 전용 함수라 테스트를 제대로 진행하지 못했다.

• MOCK 헤더를 이용하는 등 컴파일만 가능하게 하면 됐을 것 같은데, 시간에 쫓겼다.

🐶 정민

🐶 : 파싱을 했다.

• 설계를 열심히 했다고 생각했는데, 이후 생각하지 못한 예외가 발생하는 경우가 있다.
• 시간이 촉박하다 보니 처음부터 깔끔하게 짜기 보다는 최대한 구현을 빨리 하려고 했다.
• config 파싱을 마지막에 한 것은 잘한 것 같다. (원석이도 동의해요)
• cpp에서 제공하는 함수를 많이 활용하지 못하고 c 스타일로 짠 부분이 꽤 있는 것 같다.

3. 배운점들 - 계획과 실제 결과의 차이는 왜 발생되었는가?

🦊 원석

🦊 : 과제 내용에 대해 처음부터 다 알고 시작하지 못했다.

• 처음 설계와 계속 달라진 이유, 객체 지향을 지키지 못한 이유가 근본적으로 이것 때문인 것 같다
• 구현해야 할 내용에 대해서 완벽하게 파악하지 못한 채 구현을 시작하다 보니, 좋은 설계가 나오지 않게 된 것 같다.
• 그렇지만 모든 프로젝트가 다 알고 시작하지는 못할텐데, 처음부터 수정을 덜 하면서 구현하는 방법이 있을 지 궁금하다.
• 처음에 동적할당에 대한 두려움 때문에 사용하지 않는 방향으로 설계를 하게 되었는데, 이게 결국 설계를 갇힌 방식으로 하게 만든 것 같다.

🐶 정민

🐶 : 객체지향은 어렵다.

• cpp로 처음 규모가 큰 프로젝트를 진행했다. cpp 스럽게 코드를 짜는 방식에 익숙하지 않다 보니 하나의 클래스에 너무 많은 함수들이 존재했다.
• 어떤 기준으로 클래스를 나누고 역할과 책임을 분담해야 하는지가 어려웠다.
• 파싱 부분에 반복되는 함수가 많았지만 묘하게 각자 하는 역할이 달라서 함수화하지 못했다.
• 처음 시작할때는 프로젝트의 정확한 흐름에 대해 다 알지 못하고 시작하다 보니 부분만 생각하게 되었던 것 같다. 다 완성했을 때 이런 부분은 합쳐졌으면 좋았겠다는 게 보이는 것 같다.

4. 목적 - 지속, 개선 혹은 포기할 것들은 무엇인가, 배운 것들은 무엇인가?

🦊 원석

🦊 : 배가 사르르 고프다..

기록

• 데일리 스크럼, 개발일지, 에러코드 정의, 회의록 등.
• 프로젝트에서 일어나는 일들을 최대한 기록하려고 하였고, 많은 도움이 되었던 것 같다.
• 한창 구현에 바쁠 때는 기록을 살짝 소홀히 하게 된 것 같다. → 습관 들이는 것이 중요할 것 같다.

설계는 완벽할 수 없다

• 아무리 설계를 하고 시작하더라도 구현하는 과정에서 놓치는 부분을 찾게되고 추가되는 요구사항을 만나게 된다.
• 이는 필연적인 부분이라 어떻게 설계를 해야 이런 예상치 못한 상황에 유연하게 대처할 수 있을 지 고민을 하게 됐다. (사실 아직도 잘 모르겠다..)
• 혼자 설계할 때는 어려웠던 것들이 간식 시간에 정민이와 같이 이야기 하니까 훨씬 쉬워졌다.
• 간식 타임은 좋은 것 같다.

구현을 우선으로

• 알게 모르게 코드를 예쁘게 짜야 한다는 강박이 있었던 것 같다.
• 마음을 비우고 나니 코드가 아주 잘 짜졌다..
• 예쁜 코드도 중요하지만, 가장 중요한 것은 완성이라는 것을 느꼈다.
• 시간이 더 많았다면 더 완성도 높은 코드를 작성할 수 있지 않았을까.. 라는 생각도 든다.
  • 스프린트: 회고 주기를 짧게 가서 후회 덜하기.. (설계 바꾸기 같은거)
• 하지만 시간 안에 구현하는 경험도 좋은 경험인 것 같다.
• 다른 언어나 98이 아닌 모던 CPP였다면 어땠을까.. 싶기도 하고 너무 언어에 기대려는 건가 싶기도 하다. → 그래도 나중에 다시 구현해보고 싶긴 하다.

회의

• 회의할 때나 커뮤니케이션을 할 때 내가 생각하는 것을 잘 전달하는 능력이 중요하다는 것을 느꼈다.
• 이전 과제와는 달리 개념이 어렵고 방대해 같은 말이라도 전혀 다른 부분을 생각하고 있는 경우가 많았다.
• 내 생각을 더 잘 전달하는 방법도 고민해봐야겠다.

테스트

• 확실히 프로젝트가 커지다 보니, 테스트하는데도 어려움이 있었다.
• 새로운 기능을 추가하면 postman으로 GET 요청 몇번 날려보는게 전부였다.
• 오류가 생기면 cout으로 로그를 찍어보며 진행해 수정까지 오래 걸렸다.
• 서버 로그를 따로 만들어 두지 않아 오류가 어디서 생기는지 파악하기 어려웠다.
• 프로젝트 볼륨이 작을 때처럼 구현하니 훨씬 힘들어진 느낌이다. → 다음에는 테스트 코드나 로그를 더 신경써서 프로젝트를 진행해야겠다.

공식 문서

• 공식 문서를 잘 안봤다.. → RFC의 커넥션 부분을 참고할 수 있었을 텐데, 그냥 내가 생각한 대로 한 것 같다.
• 나중에 파싱 부분을 도와서 할 일이 있었는데(dot segment) 그 때 RFC를 보며 구현하니까 아주 편했다.
• 공식 문서의 중요성을 느꼈다.

🐶 정민

🐶 : 움파룸파투파티티

기록

• 데일리 스크럼을 기록하면서 하루에 해야할 것이 명확해져서 좋았다.
• 큰 목표를 세우고 쪼개기 보다는 그날그날 해야할 것들에 대해서 정하다 보니 현재 얼만큼 진행되었는지 체감이 잘 되지 않았다.
• 회의록은 얘기 하면서 쓰기가 너무 어렵다. → 클로바를 활용하면 좋을 것 같다.

분배

• 구현에서 파싱을 담당하다 보니 원석이가 구현하는 부분에 대해서는 잘 모른채 구현을 했던 것이 아쉽다.
• 물론 이론적으로는 설명을 들었지만 잘 모르다 보니 설계는 대부분 원석이가 했다.

HTTP

• 실제로 웹서버를 만들면서 RFC에 작성된 HTTP 프로토콜에 대해 알 수 있는 시간이었다.
• HTTP/1.1에 대해서만 공부를 해서 최신 HTTP에 대해서는 배제하고 구현을 했다.
• 구현이 우선이다 보니 어느 정도 RFC에 나와있는 내용을 타협하려고 했다.
  • 대신 내가 납득할 수 있는 선 안에서 구현을 최대한 하려고 노력했다.

회의

• 회의를 할 때 예쁘게 말하는 것은 어렵다.
• 내가 생각하는 것이 항상 틀릴수도 있다는 것을 생각하며 포용적으로 말하고 들어야겠다.

시간

• 블랙홀 안에 구현을 하고 통과해야 한다는 생각이 강해서 불안한 채로 했다.
• 확실히 시간 내에 무언가를 해내야한다는 생각은 조급하게 만들었다.
• 구현을 처음부터 예쁘게 하려고 해도 막상 하다보니 바꿔야 되는 것들이 생기고, 고치다 보면 또 마음에 들지 않는 것 같다. 그래서 최대한 완성하고 리팩토링을 잘 하는 것도 유연하게 대처하는 방법이고 그에 익숙해지고 싶다.

테스트

• telnet과 postman으로 테스트를 진행해보았다.
• nginx의 실제 동작 과정에 대해 잘 이해하는 시간이었다.
• curl을 제대로 활용해보지 못한 것 같아 아쉽다.
• 테스트를 자동화했다면 코드를 수정할 때마다 확인하지 않아도 되었을 것 같다는 원석이의 의견에 동의한다. cpp로 테스트 작성을 해본적이 없다보니 얼레벌레 테스트 한 것 같다.
  • 테스터를 쓰는 것은 익숙하지만, 만들 생각은 하지 못했다.

공식문서

• 확실히 공식문서를 읽으면 동작 과정에 대해 상세히 이해할 수 있어서 좋은 것 같다.
• 이전에 미니쉘을 구현할 때는 bash의 파싱 과정에 대해 제대로 알지 못한 채로 구현하다보니 예외 케이스가 생각할 것이 너무 많아서 어려웠는데 이번에는 nginx를 직접 docker에서 실행시켜 보고 github, 공식 문서 등을 읽어보면서 최대한 동작과정을 이해하려고 노력했다.
• RFC는 내용이 너무 방대하고 모르는 단어가 많다 보니 읽기가 어려웠지만 서로의 약속인 만큼 굉장히 자세하게 나와있어서 구현할 때 공부하기 좋았다.