3주차 데일리 개인 회고

11월 21일 월요일

대성

• 사실
  • 본격적으로 분업을 시작했다.
  • TDD를 했다.
  • 비빔밥이 맛있었다.
• 생각 & 감정
  • 능이 형의 디자인을 보고 분업을 시작하니 막연했던 것들이 손에 잡히는 기분이고 빨리 만들고 싶다라는 생각을 했다.
  • TDD를 할 때 테스트의 구성이 단순히 input, output만 있는 줄 알았는데 알고리즘이 타당하다는 것을 보여주는 방법에는 여러가지가 있을 수 있다는 것을 깨달았다.
    • 무엇을 단위로 볼 것인지를 기준으로 여러가지를 나눌 수 있을 것 같다.
      • 함수 하나를 단위로 보면 input과 Output으로 이를 검증할 수 있다. 그러나, 함수의 단위를 작게 할수록 input, output을 작성하는 것에 비해 테스트하는 것의 가치(?)가 작아지고 함수가 커질수록 의존하는 것들이 많아지고 추가적으로 호출이 되었는지 상태가 변경되었는지 등 mocking을 하는 것이 복잡해진다. 그리고 함수의 단위가 작으면 type, interface, 함수의 이름 등으로도 이미 충분할 수도 있다.
      • Output을 하나의 단위로 본다면 Output이 올바르게 나왔는지를 검증하는 함수를 작성하고 이 검증하는 함수가 올바른지를 테스트할 수 있다. 검증하는 함수가 올바르다면 수많은 랜덤 테스트케이스를 생성할 수 있고 알고리즘이 타당하다는 것을 경험적, 귀납적으로 알 수 있다. 이렇게 일종의 틀이 먼저 정해진 알고리즘 같은 경우는 오히려 코드를 작성하는 자유도가 낮고 그에 반해 몇 개의 분기 혹은 몇 개의 예외처리에 대한 테스트 케이스를 작성하고 이에 대해 TDD로 코드를 구성하는 경우는 그 자유도가 높다고 할 수 있다. 코드를 작성하는 자유도가 낮다는 것은 정답이 정해졌다는 것이고 이를 보여주기 위해서는 정당성 증명을 해야겠지만, 수많은 랜덤 케이스로 이를 어느정도 증명할 수 있을 것이다. 마지막으로, 각각의 핵심 알고리즘이 타당하다는 것을 보여줄 수 있다면 남은 것은 E2E Test에서 호출이 되었는지 보여주는 것밖에는 남지 않을 것이다.
  • 밥 먹는 시간이 거의 1시간이 되는데 이게 낙인가 싶으면서도 이 시간도 각자를 위해 활용하는게 더 좋을까라는 고민이 생겼다.
• 피드백
  • 능 : 오늘 페어프로그래밍 하면서 고생 많이했어! 내가 라이브러리나 유틸기능들에 대해서 좀 어두운데 오늘 덕분에 많은것을 배웠습니다 ㅋㅋㅋㅋ 내일도 힘내서 테스트코드 작성하고, 알고리즘 끝내보자고!
  • 나경 : TDD를 하면서 정말 많은 생각을 한게 보이네... 남은 알고리즘 구현 힘내세요...!
  • 수빈 : 뒤에서 계속 열심히 하는 모습을 보긴 했지만 이렇게 많은 생각을 했을 줄이야..!!! E2E 테스트는 맡겨만 주세요!!

능

• 사실
  • 오늘 처음으로 분업이 시작되었다!
  • 알고리즘 테스트코드를 작성했다.
  • 마스터 클래스를 들었다.
  • 점심으로 기사 분식을 시도했다.
• 생각 & 감정
  • 테스트 코드를 작성하면서 테스트 방식에 고정 Input, Output을 이용한 정답 대조 방식도 있지만, 출력 값의 유효성을 검증하는 방식도 가능하다는 사실을 대성이와 함께 깨닫고 해당 방식으로 테스트 코드를 작성하게 되었다. 즉 테스트 대상 작업의 출력이 특정 조건들을 만족해야만 하는 경우, 출력 값 전체를 평가하는 것이 아니라 출력값이 가져야하는 조건만을 테스트 하는 것이다. 10 이하의 소수를 출력한다고 하면, 결과값이 [2,3,5,7]인지 확인할 수도 있지만, 결과값들이 모두 소수인지, 그리고 결과값에 해당하지 않는 10 이하의 수들은 모두 소수가 아닌지 판별하는 식으로 간접적인 테스트를 하는 것으로도 확인이 가능하다. 이렇게 테스트 코드를 작성하면 검증 과정이 입력값에 독립적이므로, 임의의 입력들을 넣어서도 테스트를 충분히 진행할 수 있다는 장점이 있다.
  • 하지만 위의 방법에도 약점은 존재한다. 검증 과정이 입력에 독립적이기 때문에, 출력 양식은 정확하지만, 입력값에 대해 출력값의 대응이 정확하지는 테스트 할 수 없다. N 이하의 소수를 출력하는 경우, 검증 코드는 N을 알지 못하므로, 넘겨받은 결과값들이 모두 소수인지만 판별할 것이고, 끽해야 결과값 중 최대값 이하의 소수들을 모두 센 것인지만 알 수 있을 것이다. 하지만 N=100 에 대해 [2,3,5,7]를 넘기더라고, 검증 코드는 절대 이를 걸러낼 수 없다.
  • 전자는 검증 코드가 검증 대상 로직에 독립적이기에 신뢰성이 뛰어나고, 임의 생성된 테스트 케이스 사용이 가능하다는 장점이 있다. 후자는 테스트 케이스 작성에 품이 많이 들지만, 로직의 무결성 검증을 위해서는 반드시 필요하다. 즉, 두 케이스를 적절히 안배하여 소단위 테스트는 전자의 방식으로 진행 한 뒤, 준 통합테스트 혹은 단위간 연계성을 띠는 테스트 그룹만 후자의 방식으로 진행하면 현명하게 TDD를 할 수 있으리라는 생각이 들었다. (본래도 특정 예외케이스를 타겟하여 테스트를 적고, 복잡하고 임의성의 띠는 몇몇 테스트 케이스를 마무리로 넣는데, 이에 대한 구분을 더 명확히 하는 느낌이다.)
  • TDD란 무엇인가... 하는 생각이 새삼스래 다시 들었다. 조건 검증만 하는 경우, 단순한 로직에 대해서는 그 의미가 많이 퇴색되므로, 너무 TDD의 무결성에 매몰되기 보다는 적절한 테스트 피처 크기의 선정과, 이를 잘 wrap up할 수 있는 무결성 검정을 잘 구분하여 전략적으로 작성하는 것이 현명하게 TDD를 하는 방법이 아닐까? 싶었다.
  • 형변환... 또 형변환.... 형변환의 늪은 정말 끔찍하다. 조금 귀찮더라도, 미리미리 적절한 표준 타입/규격과 컨버전 함수를 작성하는 것이 좋겠다는 생각이 들었다. 데이터 수집과 테스트 코드 작성 레거시가 이틀정도밖에 쌓이지 않았는데도 벌써부터 수많은 에러를 뽑아내는 것을 보면서, 타입 관리에 만큼은 "나중에 하자" 가 절대적 독이라는 생각이 들었다.
• 피드백
  • 나경 : 화요일 스크럼에서 이런 생각들을 말해줘서 정말 좋았어👍 능오빠와 대성오빠가 테스트 코드를 짜면서 여러 부분을 고려하고 있다는 것을 알게 되었고 다음에 내가 테스트코드를 짠다면 어떤걸 또 고려해야하나 라는 생각을...했지만 사실 CD도 바빴다...ㅋㅋㅋ 아무튼 항상 이런 생각 공유해줘서 고맙습니다
  • 수빈 : 엄청난 회고,, 나중에 후속편으로 page 독립해서 써주세여!!! 회고에 있기 아깝다.. 뒤에서 계속 열심히 토론?하는 모습 인상적이었는데 TDD에 대해 이렇게 많은 고민을 했다니!!! 덕분에 새로운 시각을 알 수 있었어!! 감사합니당
  • 대성 : 능 형의 사고 복잡도가 O(1)인 것을 검증하는 테스트 코드를 작성하도록 하겠씁니다. 소수로 비유드니까 정리가 잘 되는 느낌..! 뭔가 재밌게 하고 있는 것 같아서 너무 좋습니다!

수빈

• 사실
  • CI,CD를 작업했다.
  • 도커를 설정하다가 이해 부족으로 인한 수많은 오류를 만났다..
  • github actions와 도커의 대환장 콜라보,,⭐️
  • 칼국수를 먹었다.
  • 저녁에는 청첩장을 받으러 가서 작업을 많이 하지는 못했다.
• 생각 & 감정
  • 유치원 수준의 이해력을 가진 내가 고등학생 수준의 일을 하려니 너무 어려웠다.. 이게 바로 기초가 중요한 이유인가.. 능 오빠가 한 20번 설명해줬는데 20번만에 이해해서 부끄럽기도 하고 고맙고 미안하고 머쓱했다.(?) 팀원들이 힘을 합쳐서(?) 나를 이해시켜줬고 그 과정이 고맙고 미안했다.. 협업이 나를 성장시킨다 두둥탁⭐️
  • 빌드를 도커에서 하려고 했는데 github actions에서도 할 수 있다는 걸 알고, 방향을 바꾸어 진행하게 되었다. 이 과정에서 나의 무지함과 신문물에 대한 감탄을 했던 것 같다..
  • github actions로 codecov 등록하고, 빌드하는 코드를 작성해봤는데 너무 신기하고 재밌었다.
  • 청첩장 받으러 가는 약속으로 야근하는 팀원들을 등지고 일찍 퇴근해서 마음이 안좋았다..(근데 고기는 맛있었다고 한다..)
  • 칼국수는 칼칼했다.
• 피드백
  • 능 : CI/CD 팀의 빠른 습득속도 매우 훌륭합니다~~~~! TDD는 느리게 갈게요 ㅎㅎ....
  • 나경 : github action 사실 괜찮을 것 알고 있었지만 해보기 전에는 마냥 막막하고 힘들 것 같앴는데 언니랑 함께하니 그래도 재밌게 했어!! 그리고 야근 때 힘들었던걸 언니가 한방에 해결해줬다..ㅋㅋㅋㅋ 오늘도 고생하자!
  • 대성 : codecov 소개해준 것도 너무 좋았고 항상 트렌드나 개발 상식 알려주는 것도 좋습니다~ 본인을 설명충이라고 부르는 것만큼 어떤 문제를 겪고 있는지 잘 설명해주니까 다같이 잘 고민할 수 있었던 것 같아!! 자신을 과소평가하지만 끝에 끝에는 해낼 것 같은 느낌!

나경

• 사실
  • CI/CD를 했다
• 생각과 감정
  • 나는 돌멩이다
  • 정말 다양한 것을 시도해봤다…내가 날린 action만 몇개인지 모르겠다…
  • 그래도 어느정도 해결이 될 것 같아서 다행이다…
  • Docker 개념만 알고있어서 휘뚜루 마뚜루하면 될 것이라고 생각했었는데 생각보다 쉽지 않았다. 역시 무언가를 하기 전에 공식문서를 참고해서 제대로 공부해야겠다는 생각을 다시하게 되었다.
• 피드백
  • 능 : Docker같은게 한번 배워두면 그다음부터는 쉽게 쓸 수 있어서 처음만 고생하면 됩니다! 공부해서 나도 알려줘~
  • 수빈 : 좋은 레퍼런스를 잘 찾아서 덕분에 수월하게 진행할 수 있었던 것 같아.!! 둘이 했어도 피로도가 엄청났는데 혼자 했다면 얼마나 땅굴을 팠을지,, (아찔) 페어 프로그래밍 재밌따!!! 조와요🙆🏻‍♀️
  • 대성 : 그 수많은 실패의 의미는 그만큼 성공할 가능성이 남아 있다는 것.. 돌멩이도 다 같은 돌멩이가 아니다! 고통받는 것이 마음이 아프지만 수빈이랑 같이 둘이 꺄르르하는 것 보면 덩달아 힘을 받게 되는 것 같아~ 힘내봅시다!

11월 22일 화요일

능

• 사실
  • 사무실 옆 함박스테이크 집에 가서 점심을 먹었다.
  • 고수 가득 반미를 저녁으로 먹었다.
  • 테스트 방식, 섹션의 정의를 마무리했다!
  • 테스트 코드들을 리팩터링했다.
  • 테스트 케이스들을 작성했다!
  • DB 잘쓰는 법 강연을 들었다.
• 생각과 감정
  • DB 강연을 들으면서 예상치 못한 Graph DB 사용 뽐뿌가 왔다!!!! Neo4j를 시도라도 해볼 수 있었으면 좋겠다!
  • 테스트의 종류, 각자 어떤 특징이 있는지, 어떻게 활용하면 좋을지에 대한 감이 어느정도 잡혀서 기쁘다.
  • 이제 테스트 코드 작성이 얼마 남지 않았다! 테스트를 잘 짜두어서 알고리즘 구현도 금방 될 것 같아 벌써부터 완성이 기대된다.
  • 다시한번 문서화를 잘 해두어야겠다는 생각이 들었다. 테스트 코드를 작성하면서 많은 깨달음이 있었는데, 아직까지 이를 제대로 정리하고 문서화하지 못한것 같아 아쉽다는 생각이 들었다.
  • 대성이가 Todo 순서관계 생성과 시각화를 잘 해준 덕에 Todo간의 순서관계 테스트케이스를 즐겁게 작성할 수 있었다. 동시에 이를 다시 우리 코드로 시각화 하면 역시 재미있겠다는 생각이 들었다.
• 피드백
  • 나경 : 내일 아침 테스트의 종류에 대해서 들을 수 있는 시간이 있겠군요^^ 신난다!! 시각화한거 보니까 둘이 정말 많은 생각과 고민들이 있었을 것 같다는 생각이 들었어. 고생했어!
  • 대성 : 어제 말로 주고받은 것들을 회고로 정리해주고 또 다시 아침에 갈무리해주니까 오늘 정말 수월하게 할 수 있었어!! 시각화한 것을 엄청 재밌어해주니 뿌듯한 느낌.. 나도 점점 해볼수록 여러가지 뽐뿌가 오는데 할 수 있겠지..? 내일 아침까지 딱 마무리하고 후딱 다음 것을 향해 가봅시다!!
  • 수빈 : 테스트의 달인이 되어 가는 둘의 모습을 뒤로 보았다..!!! 순서관계 테스트케이스 짜기 어려웠을텐데 고생 많았따 둘이ㅜㅜ TDD 2편 들려주세요!

나경

• 사실
  • 어제 고민했던 context부분과 Dockerfile 지정 부분을 능오빠에게 물어봐서 수월하게 해결할 수 있었다
  • client를 build한 파일을 copy한 container를 만들고, 그 앞 컨테이너에서 nginx로 정적파일을 올려주게 만들었다
  • server의 typescript를 build한 파일을 copy하여 실행시키는 container를 만들었다.
  • client와 server를 proxy해주는 container를 만들었다.
  • 이 container들을 compose해 server에 올려주었다.
  • 위 과정들을 main과 release에 push되면 진행되게 github action으로 만들었다.
  • 점심에는 함박스테이크를, 저녁에는 반미를 먹었다
  • 종혁오빠와 말을 편하게 하기로 했다.
• 생각 & 감정
  • DB 특강을 듣는데 graphQL 좋다고 하셔서 그렇구나 했는데 집에 오면서 [A3] 컴포넌트, 다시 생각하기를 봤는데 마지막에 graphQL 홍보를 하시길래 이쯤되면 쓰라는건가.. 라는 생각이 들었다.
  • DB 특강 호눅스님이 능 오빠와 굉장히 비슷한 향기가 나서 친숙했다
  • DB에 대해서 역시나 모르는게 많다는 것을 느꼈다.
  • 어제는 가늠할 수 없는 에러여서 당황했는데, 오늘은 로그를 읽으면 술술 풀리는 에러들만 만나서 기분이 좋았다. 멘탈 성공!
  • 아직도 내가 아는 것을 설명할 수 있는 능력이 많이 부족하다는 것을 느꼈다. 전에 지인께 들었던 말인데 나는 말 할 것을 생각지않고 말하면 중구난방으로 튄다는 얘기를 들었었다. 일단 다른 사람한테 이야기하기 전에 머릿속으로 무엇을 이야기하고 싶은지 정리해보고 순서대로 이야기를 해나가는 습관을 들여야겠다고 생각했다.
  • 페어프로그래밍의 꿀잼을 느꼈다... 솔직히 혼자했으면 진짜 화나고 때려치고 싶은 순간이 많았을 것 같은데 수빈 언니와 함께하니 신나게 할 수 있었다.
  • 지금까지 한 부분을 문서화해야겠다고라는 생각을 너무 늦게해버렸는데 다행히 수빈언니가 잘 해줬었다... 혼자 할 때는 꼭! 노션 키고 해야지
• 피드백
  • 대성 : 오늘 희노애락 다 봤다. 별점: ★★★★★,,, 나도 항상 비슷한 고민을 하고 있는데 같이 아무말 해보면서 이겨내보자~ 고생 많았습니다!
  • 능 : 그래도 쑥쑥 목표한 바를 완성해주고 있어서 감사합니다... 문서화도 감사합니다... 더 노력하는 TDD팀이 되겠습니다.... 그리고 페르시아의 왕자는 "상식"의 영역입니다 ㅎㅎ.
  • 수빈 : 정말 둘 다 신남 -> 탈진 -> 슬픔 반복하면서 했던 것 같아,, 인프라는 둘 다 처음이라,, 혼자 했으면 절대 못했을거야ㅠㅠ 둘 다 slack report까지 고생 너무 많았따ㅠㅠ

대성

• 사실
  • 테스트를 어떻게 할지에 대한 생각과 코드들을 리팩터링 했다.
  • 그래프 형태의 테스트 케이스를 작성하고 이를 시각화 했다.
  • 함박과 반미.. 잘 먹었다~
• 생각과 감정
  • 어제와는 팀 분위기가 사뭇 달랐다. 모두가 삽질을 하고 가닥이 잡히니까 재밌고 알차게 하루를 보낸 것 같다.
  • 테스트 데이터를 하나하나 보고 만지니까 토대가 더욱 단단해진 것 같다. 능 형한테 사과게임말고 더욱 재미난 것을 줄 수 있을 것 같다..
  • 검증 테스트 관련 코드 중 디테일하지 못하고 대충 이렇게 돌아가겠지하고 짠 부분이 결국 문제가 있었다. 내 안의 논리가 코드가 나와야 되는데 반대로 코드에 내 말을 억지로 맞추는 버릇이 있는 것 같다. 보통 Top-Down으로 생각을 많이 하는데 bottom-up 식으로 생각하는 능력이 부족한 것 같다.
• 피드백
  • 능 : 게임으로 만들어주면 합니다... 종이로 주시면 안합니다... 그래도 마지막에 한방에 테스트 패스했고, 오늘 고생했으니 내일 슉슉 구현을 해봅시다~~~
  • 수빈 : 사과게임 말고 다른 재밌는게 혹시 테스트케이스 작성하는건가요.?? ㅋㅋㅋㅋ 다들 고생이 많습니다,,
  • 나경 : 엄청난 그래프들… 숙제로 나눠주려고 했을 때 식겁했다고~ 코드가 내 논리를 만드려고 한다는 말 엄청 공감이네😢 내가 코드를 조종하게 해볼게💪

수빈

• 사실
  • 서버에 nginx를 배포했다.
  • github actions로 docker-compose.yml 파일을 복사해서 넣어줬다. (이 코드를 까먹어서 힘들었다..!)
  • 호눅스 님의 DB 강의를 들었다.
  • docker compose를 처음 시도했고, 맛있는 음식들을 먹으며 야근했다.
• 생각과 감정
  • 머리가 너무 혼란스러웠다.. 할 일은 많은데 시간이 없어서 막막했지만 그래도 희망이 보이고 있는 것 같다.
  • docker-compose로 배포하는 과정이 혼란스러웠다. 컨테이너를 사용해서 격리를 했더라도, 계속 원래 사용하던 아키텍처를 머릿속에 연상해서 더 헷갈리는 것 같다ㅜㅜ 주말에 시간이 나면 아키텍처 구성도를 그려보는 게 좋을 것 같다고 생각했다.
  • 다같이 호눅스님의 DB 강의를 듣는데, 굉장히 유쾌하고 겸손하신 분이라는 생각이 들었다.
• 피드백
  • 능 : 이제 곧 완성될꺼야~ 분명 내일이면 완벽하게 릴리즈 서버에 올라가는 모습을 보면서 다같이 폭죽을 터트리자~
  • 나경 : 인프라 어려워 어려워 😢 그래도 이번에 맘먹고 해봤으니까 전보다는 막연한게 없어진 것 같아서 너무 좋아!! 우리 너무 고생많았다😆
  • 대성 : 액션가면급 액션 장인으로 변모하는 중.. 주말에 트러블 겪었던 것 정리해보면서 잘 마무리해보자!

11월 23일 수요일

능

• 사실
  • 대단위 테스트 코드를 작성했다.
  • 처음으로 본격 피처 브랜치를 메인 브랜치에 머지했다.
  • 문래동에서 불백을 점심으로 먹었다.
  • 저녁으로 쫄면을 먹었다.
  • 가위바위보에서 져서 점심에 아이스크림을 샀다.
  • 저녁에는 이겨서 커피를 얻어 마셨다.
  • 멘토님과의 미팅을 가졌다.
• 생각과 감정
  • 테스트란 무엇인가.... 멘토님과의 미팅을 통해서 아무리 그래도 Input-Output 완전 대조 테스트가 가장 일반적이라는 것을 알게 되었다. 다시 부활 시켜야지....
  • 우리가 생각하던 것보다 테스트 케이스를 더 단순하게 짜도 된다는 생각이 들었다.
  • 각 테스트 케이스가 하나의 매우 작은 유닛이 되어, 그 각각이 작동되면, 전체 기능이 제대로 작동될 것이라고 가정해야 했는데, 우리는 함수 하나를 하나의 유닛처럼 여기고, 해당 케이스에 대해 복잡한 테스트 케이스를 넣어서 종합적인 무결성을 검증하려고 했던 것이 문제였다.
  • TDD를 하는데, 케이스를 단순하게 짜서 빈틈이 생기면 어떡하나... 가 의문이라 임의의/많은/복잡한 테스트 케이스를 만들었던 것인데, TDD는 빈틈이 없이 테스트를 짜서 한방에 완벽한 "결과"를 추구하는 것이 아니라, 테스트를 먼저 짜고 코드를 구현하는 "과정"을 통해 건실함을 챙기는 것이라는 것을 또 잊고 있었던 것 같다.
• 피드백
  • 나경 : 맞네.. 테스트를 먼저 짜고 코드를 구현하는 "과정"을 통해 건실함을 챙기는 것이라는 것이라는 말을 처음에도 했던 것 같은데 자꾸 잊게된다..! 분명 처음에 같이 이야기 나눴던 것 같은데. 그래도 신박한 생각으로 tdd에 접근해서 그 발상에 테며들었달까..
  • 수빈 : 테스트를 위한 테스트의 테스트,, 아마 그 아이디어가 한 번 들었을 때 100% 이해하기 어려워서 그랬던 것 같아.! description이나 다이어그램?같은 걸 준비하고 했으면 달랐으려나.. 라는 생각을 뒤늦게 해보았습니다.. ⭐️ 그리고, 항상 좋은 피드백 감사합니다👍🏻 덕분에 ci&cd에 대한 좋은 인사이트를 얻었어여
  • 대성 : 능루먼쇼.. 형은 너무 많은 것을 알아버렸어(근데 형이 기뻐보이는 것은 기분탓일까).. TDD 시리즈 빨리 종연합시다!

수빈

• 사실
  • 멘토링을 했다.
  • rebase를 팀원들과 해보면서 브랜치 전략을 수정하기로 했다.. ^^ rebase는 참 많은 것을 우리에게 알려주었다.
  • 팀원들과 서로 코드 리뷰를 했다.
  • 머리 깨지면서 release server 분리하고, Github actions로 release를 관리하도록 했다.
  • 텐텐 게임에서 져서 아이스크림을 샀다.
  • 도커 마스터클래스를 들었다.
• 생각과 감정
  • 항상 느끼는 거지만 어떤 라이브러리/marketplace 등에서 제공하는 기능을 사용할 때 그 내부 동작을 완벽하지는 않더라도 궁금해하고 관심을 기울이는 게 중요하다고 생각한다. 문제 상황에 놓여 있을 때, 이런 식으로 하면 될 것 같은데라는 생각은 라이브러리에서 제공하는 편의 기능이 어떻게 동작하는지 궁금해하고, 알아보는 데에서 시작하는 것 같다.!! 좀 더 시간을 들여서 고민하고, 기록하자!
  • 생각보다 하루에 온전히 개발할 수 있는 시간은 부족하고, 머리 깨지는 시간은 길다.. 욕심을 덜어내는 것은 항상 너무 어렵다..
  • Rebase를 사람들이 왜 싫어하는지 알았다.. 부들..
  • 코드 리뷰를 들으면서 좀 더 최적화된 github action에 대해 고민해봐야겠다고 생각했다.
• 피드백
  • 나경 : rebase… ㅋㅋ ㅋ ㅋ 4명을 당황시킨 혼돈의 rebase… 정말 하루에 개발에 온전히 집중할 수 있는 시간은 적은 것 같네. 내일은 컴포넌트 설계 한번 몰입해서 도전해보는걸로 하자!(컴퍼니데이 2번은 쉿)
  • 능 : 그래도 CI/CD 해놨으니까!!!!!!! 앞으로는 편할거야!!!!!?!!!! 욕심은 더는 연습은... 다함께 열심히 해봅시다...
  • 대성 : 여유가 생기면 궁금해할 수 있을거야(나도 못함).. 그리고 개발도 곧 고속도로 진입할 예정이니 어떻게든 가봅시다~

나경

• 사실
  • release server 설정을 했다
  • docker image tag를 달았다
  • git 관리에 대해서 다시 한번 생각해보고 rebase가 아닌 merge를 선택하기로 했었다
  • 22:00~23:00 멘토 미팅을 했고, TDD CICD 컴포넌트 git 관련 진행 사항 및 질문을 주고받았다
  • 핸드폰 개통이 아직도 안됐다..
• 생각 & 감정
  • 어쩌다보니 PR하나에 54개의 commit이 생겼지만 action이 잘 동작해서 기분이 좋았다
  • 거북목과 척추측만증이 심해지는 느낌이 들었다.. 팀원들과 나의 건강을 위해서 매 시간마다 스트레칭 시간 5분을 가져야겠다(필수)
  • Action을 쓰고있지만 자세히는 몰라 할 수 있는 기능을 100% 못쓰고 있다는 생각도 들었다. 사실 github action 같은 경우는 바뀌는 지식에 가까운데 이런 지식은 어디까지 쌓고 어디까지 정리해둘 것인지 생각을 해봐야겠다
  • 첫 코드리뷰를 했다. 사실 이미 진행상황을 서로 공유한 상태여서 고민 공유 및 추후 수정사항을 같이 생각해보는 자리에 가까웠다. 재밌었다!!
• 피드백
  • 수빈 : PR 하나에 54개의 커밋,, 다음부터는 좀 더 분리해서 작성해보자 하하! 좀 더 action의 기능(?) 원리에 좀 더 집중해서 활용해보겠씁니다..⭐️
  • 능 : CI/CD 착착 돌아가고, 전혀 안 써본 새로운 기능들도 써보고, 정말 고생 많았어! 커밋 숫자는.... 환경설정이니까 어쩔 수 없다 생각하자 ㅋㅋㅋㅋ
  • 대성 : 스트레칭 마스터 직책을 부여하겠습니다.. 권한은 팀원들의 의사와 상관 없이 스트레칭을 시킬 수 있는 것임니다.. 그리고 곧 액션 마스터 직책도 드릴게요..

대성

• 사실
  • 테스트 케이스 작성을 일단 완료했다..
  • 멘토링 시간을 가졌다!
  • 서로의 PR 리뷰 시간을 가졌다!
• 생각 & 감정
  • 예상했던 일정보다 테스트 케이스 작성을 완료하는데 더 시간이 소비했다. 좀 더 테스트 코드를 효율적으로 작성하기 위해 형변환 과정과 데이터 및 관련 코드를 리팩터링하는데 시간을 소모했다. + 오늘 내 태도가 좀 늘어지고 수동적이었다.. ㅠ
  • 테스트 케이스 작성에 대한 피드백을 멘토님께 받았는데 테스트가 일종의 함수의 사용설명서이어야 한다라는 말이 와닿았다. 함수 자체의 검증도 중요하지만 테스트 결과만 보았을 때 이게 어떻게 동작하고 어떤 경우에 실패하고 성공하는지를 보여주는 것도 중요하다는 것을 깨달았다..
  • PR리뷰를 하니까 서로 어떤 것을 해왔는지 상세하게 알 수 있었고 궁금증들을 해소할 수 있었다. 하지만 merge를 하는 과정에서 rebase를 해봤는데 rebase도 임시 브랜치를 만든다는 사실도 알게 되었고 continue를 통해 conflict해결해나가는 과정도 재밌었지만 메타 정보도 갱신되고 하나의 브랜치에 두 사람이 작업하게 되면 한 사람은 main을 feature branch로 rebase한 채로 작업을 했을 수도 있고 이 경우 다시 origin의 feature branch를 다시 rebase하거나 merge를 할 경우 브랜치가 너무 지저분해진다는 단점이 있어 rebase를 안 하기로 했다.
• 피드백
  • 나경 : 테스트는 일종의 함수설명서! 멘토 리뷰 때 들으면서파일 명명, 변수 명명에 대해서 항상 왜 고민해봐야되는지 다시 한번 깨달은 것 같애… rebase 함께해서 더러웠고 다시는 보지말자!
  • 수빈 : rebase는 정말 힘들었다.. remote branch에서는 하지 않는 걸로 ^^ 하하 그리고 테스트,, 일종의 사용설명서라는 것도 맞지만 우리가 db 등등에서 다양한 시도를 하려고 테스트를 하는 거니까 큰 의미가 있었다고 생각해! 고생 많았서!!!
  • 능 : 오늘 하나도 수동적이지 않았는데, 원래 페어 프로그래밍 처음 하다보면 의견교환에 익숙해지는 시간이 필요한 것 같기도 해 ㅋㅋㅋ. 이것도 천천히 익숙해지면 되니까 천천히 해보자

11월 24일 목요일

나경

• 사실
  • 컴퍼니데이가 2번 있었다
  • 메인 컴포넌트를 설계했다
  • 오랜만에 React를 켜봤다
  • 저녁으로 1층 고기집을 갔다
  • 2022 월드컵이 시작했다.
• 생각 & 감정
  • 월드컵 할 때 맥도날드에서 항상 컵 굿즈 이벤트를 했던 것 같은데.. 이번엔 안한다. 컵 쳐돌이에게 속상한 일이다
  • 하루종일 팀원들한테 유심때매 찡찡댄 것 같다.. ㅎㅎ 그래도 잘 해결 될 것(?) 같다.
  • Routing 관련 이슈가 있었다. 자세한 것은 개발일지 참고.. 분명 좋은 해결책이 있을 것 같은데 뾰족한 수가 생각나지않아서 답답했다. 하지만 언니와 나는 해낼 것이다. 늘 그렇듯이(멋있는 표정). 불필요한 re render를 줄여보자..!
  • 내기에 fruit ninja를 도입해봤다. 처음으로 1등을 하는 기쁨을 맛봤다.
  • 가위바위보에서 져서 아이스크림을 샀다. 맛있게 맥플러리를 먹었다
• 피드백
  • 수빈 : 항상 느끼는 거지만 페어프로그래밍은 항상 즐겁따!!! styled component 덕분에 좀 더 빨리 적응하고 잘 사용할 수 있었던 것 같아!👍 fruit ninja는 좀 더 분발해보겠씁니다!! 내일도 파이팅!
  • 능 : 과일 닌자.... 정말 좋은 제안이었습니다. 내기귀신으로서 분발하겠습니다... 컴포넌트 설계 착착 해주는 모습 매우 뿌듯합니다! 얼른 완성된걸 보고싶다!
  • 대성 : 항상 이슈 생길때마다 레퍼런스 뚝딱 찾아내는 것 같네 ㅋㅋㅋㅋ 믿습니다! 아이스크림은 받아갈게..(멋있는 표정)

수빈

• 사실
  • 메인 컴포넌트를 설계하고 개발했다.
  • 점심에는 라멘, 저녁에는 고기를 먹었다.
  • jotai, styled component를 처음 사용해봤다.
  • 발표를 맡게 되었다.
• 생각 & 감정
  • 새삼 성향이 맞는 4명이 모인 우리 팀이 신기하고 너무너무 좋다!! 4명의 뽀로로들 잘 부탁합니다!
  • 간만에 리액트를 해서 즐거웠다.!!
  • atomic 상태관리 라이브러리를 사용해보면서 로 범위를 지정하는 부분이 어렵고도 흥미로웠다. 전역에서 모든 상태를 관리하는 게 맞을까? 싶다가도 상태가 여기저기 분산되어 있으면 관리가 어렵지 않을지 걱정이 되기도 한다. jotai 레퍼런스가 많지 않아서 정보를 찾기 어려웠는데, 팀원들, 다른 캠퍼 분들과 Provider를 어떻게 하면 효율적으로 사용할 수 있는지 이야기를 나눠보고 싶다.
  • react-dom-router의 unexpected re-render 문제가 발생했고, 우리 서비스에서 굳이 url을 변경하는 라우팅이 필요할까는 고민이 생겼다. 이 부분도 나경이와 잘 해결해나가야겠다!
  • 저녁에 먹은 고기는 정말 맛있었다. (가격 대비 맛있고 양도 좋았다)
  • rebase를 포기한 현 시점에서 feture branch에 sqush merge를 엄청나게 하고 있다. 하하
• 피드백
  • 능 : 나는 전혀 체크도 안하던 렌더링 성능, 라우팅 고려하는 모습이 정말 멋집니다... 뭔가 착착 건실하게 하는 느낌....? 얼른 하고 지식과 노하우를 전수해 주세요~~
  • 나경 : 라우팅이 필요할까 라는 접근 완전 좋네👍 우리 둘다 예상치 못한 문제를 만나서 고생했다🥹 고기 또먹으러가쟈!
  • 대성 : 오늘 발표를 들어보니 유튜버, 스트리머의 자질이 보입니다.. 그리고 리액트 디버깅하는 모습을 보니 개발자의 자질도.. 라이브 코딩쇼로 데뷔하자

능

• 사실
  • 점심은 라멘, 저녁은 고기를 먹었다.
  • 과일 닌자 게임을 해 보았다.
  • 전반적인 투두 로직 구현을 위한 피처리스트와 인터페이스를 설계했다.
  • 메인 페이지에 필요한 투두 로직들을 일차적으로 모두 구현했다.
  • 자동으로 Test Result를 PR에 댓글로 달아주는 마켓플레이스 액션을 만들었다.
• 생각 & 감정
  • 투두 로직을 짜면서 고민이 정말 많아졌다. 막연하게 생각하던 것에 비해 눈앞에 두고 나니, 데이터 규모, 시간복잡도, 순수성, DB와의 연동성, 타입체크, 타입 변환 등 고려할 것이 정말 끝도 없이 있었다.
  • 그래도 너무 고민을 많이하기보다는 우선 구현하되, 나중에 수정하기 쉽도록 하는 것에 신경을 들여서 작성하는 것이 좋은 개발 방법이라는 생각이 든다.
  • 오랜만에 자료구조와 알고리즘을 고민하니 즐겁다. 특히 서비스 규모가 커지면서 DB, Client, Server 모든 면에서 자료구조를 고민할 필요성이 있을 것 같아 뭔가 간단한 구조에서 극한의 케이스를 따져보는 재미가 있다.
  • 코드 한두줄짜리 수정이지만, 마켓플레이스에 올라온 퍼블릭 액션을 직접 포크해서 수정하고 다시 퍼블리시했다! 작은 수정인데 내 이름으로 올리는 게 뭔가 그러면 안될것 같은 느낌이지만... 당장 현재 프로젝트에 사용하고 싶기도 하고, 해당 프로젝트가 지금 관리되고 있지 않아서 PR보다는 포크해서 직접 발행하는 방법을 선택했다. 유지보수... 잘... 해... 봐야겠지?
• 피드백
  • 나경 : 항상 여러가지 면모를 생각하고 해결해나가는 오빠 너무 대단해!! 알고리즘 부분도, github action도! 퍼블리셔라니 넘 멋지군. 나도 .. 언젠간…
  • 대성 : 뚝딱 마켓플레이스 액션을 만드는 모습을 옆에서 실시간으로 봤는데 즐기는 자 모드로 하시는 것을 보고 감명받았습니다.. 깃 덤블도어 칭호는 덤으로 드릴게요.. 그리고 같이 10초당 1커밋할 때는 정말 즐거웠씀다
  • 수빈 : 유능한 개발자 유능님,, Marketplace에 올리는거 어려워보인다고 했는데 뚝딱뚝딱 만드는 거 보고 감탄했따.. 덕분에 오픈소스 contributor의 꿈을 다시 꾸게 되었어요..

대성

• 사실
  • 드디어 작성한 feature list, 테스트 코드, 테이스 케이스를 토대로 알고리즘을 구현했다.
  • 1층 고기집을 정복했다.
• 생각 & 감정
  • 토대가 튼튼하니 알고리즘 작성을 술술 할 수 있었다. 그리고 테스트 통과할 때 기분이 좋은 것은 덤. 다만, 추후 컴포넌트와 DB, 이미 작성한 테스트 코드 등을 다 고려하며 작성하는 것은 정말 어려운 것 같다. 그리고 또 구현할수록 생기는 문제점들이 또 연결되어 있는 것들까지 퍼지게 되니 항상 그 경계에서 입출력 처리가 정말 중요하다는 것을 알게 되었다.
  • 숨겨진 가성비 고기 맛집을 찾았는데 얼른 회식을 할 수 있으면 좋겠다고 생각했다.
  • 릴리즈 계획을 연기했다. 우리 프로젝트의 미루기 기능을 이용해 미뤘으면 더 좋겠다는 생각을 했지만 어쩔 수 없이 생긴 3일 정도의 격차를 메꾸기는 쉽지 않은 것 같다. 그래도 마음은 편하다.
• 피드백
  • 능 : 1층 고깃집 정말 좋았으... 꼭 다음주에 릴리즈 하고 회식을 진행해보도록 합시다!
  • 수빈 : 토대가 튼튼하니 알고리즘 작성을 술술 할 수 있었다. 이거 너무 멋져.. 지금까지 고생하고 고민한 게 어떤 방식으로든 성과로 돌아오는구나!! 고생했습니당 다음 릴리즈까지 파이팅! 나경 : DB와 다른 컴포넌트를 고려한, 확장성을고려한 API를 작성하다니.. 너무너무 대단해..! 그래도 설계할 때 열심히 해서 구현이 술술 된다니 다행이군요😆