챌린지 3주차가 마무리되었습니다🥳
이번주 역시 저번주와 마찬가지로, 저번주보다 훨씬 더 빠르게 지나간 것 같네요.
미션도 어려웠지만 이번주는 날씨가 역대급으로 더웠는데, 에어컨 고장 이슈가 발생하는 바람에 육체적, 정신적으로 정말 힘들었던 한 주 였습니다🥵
짝 활동
이번주는 저번주에 예고되었던대로 짝 활동으로 한 주가 진행되었습니다.
각자 개발하고 짝과 함께 서로의 결과물을 개선해보는 짝 개선이 11~12일 이틀에 걸쳐 진행되었고, 같이 개발하고 각자 개선해보는 짝 개발이 13~14일 이틀에 걸쳐 진행되었습니다.
미션을 함께하며 문제 해결을 위해 많은 소통을 하였습니다.
의사 결정 과정에서 공통으로 중요하다고 생각하는 부분, 공통으로 중요하지 않다고 생각하는 부분 등을 토론하며 훨씬 더 빠르게 최선의 선택을 할 수 있었던 것 같아 좋았습니다.
이번주도 저번주에 이어서 애자일스러운 개발과 TDD를 시도했습니다. 이번에는 짝과 함께 했다는 것이 조금 다를 것 같네요
애자일스러운 개발은 개인 미션일 때는 어느정도 달성할 수 있었으나, 짝 개발에서는 짝이 지금까지 해오던 스타일과 많이 달라 완전히 적용하지는 못했고,
TDD역시 미션의 접근 방법에 맞춘 테스트를 작성하는 것에 어려움을 느껴 일부만 적용하여 조금 아쉬웠습니다.
미션
이번주 미션도 역시 어려운 주제들을 다뤘습니다.
저번주는 패러다임 등과 같은 내용들로 생각의 전환이 필요하여 어려웠다면, 이번주는 저번주의 개념에 복잡한 요구사항이 추가된 모습이었습니다.
아마도 2일씩 이루어질 짝 활동을 반영하여 더 어려운 문제로 선정했던것이 아닐까 예상해봅니다.
11일차: 이벤트 주도 개발과 스레드 풀
11일차 미션은 짝 개선을 하기 위한 개인 결과를 만드는 과정이었습니다.
미션의 요구사항을 나름대로 해석해보면, 이벤트 주도 설계를 통해 이벤트 발생시 작업을 비동기로 실행하고, 해당 작업을 스레드를 이용해 동시에 처리할 수 있도록 해야하는 문제였습니다.
이벤트 주도 설계
저번주 미션을 통해 이벤트 주도 설계에 어느정도 감을 잡았다고 생각했었는데, 요구사항이 훨씬 복잡해지니 정신을 못차리게 되더군요 안 좋은 컨디션 때문인지 더 그랬던 것 같아요 🥲
하지만 과제를 마무리할 때 쯤에는 이벤트와 더욱 친해졌다는 느낌을 받을 수 있었습니다.
테스트 코드
제 설계는 작업들이 이벤트를 연쇄적으로 발생시켜 실행되는 구조였는데, 연쇄적으로 실행되는 동안 작업의 상태들을 추적하는 테스트를 적용해야한다고 판단하였습니다.
하지만 연쇄적으로 처리되는 일부 작업이 Private 메소드로 실행되는터라 모든 처리 흐름에서의 상태 변화 추적할 수 있는 테스트 코드를 작성할 방법이 떠오르지 않더군요…
이에 따라, 이벤트로 처리되는 흐름에서의 모든 상태 변화를 검증하지는 못했습니다.
(개선 방법은 아래에 나옵니다! 끝까지 봐주세요😁)
스레드
이벤트 흐름으로 실행 될 마지막 작업을 JS의 worker-thread(이하 WT)를 통해 처리할 수 있다고 판단되었지만, WT를 무한정 생성할수는 없다고 판단했기 때문에 WT Pool을 구현할 필요성을 느꼈습니다.
시간이 부족했던 이유도 있지만 워커를 적절히 만들고 배분할 좋은 방법이 떠오르지 않아, 결과적으로 스레드를 이용한 처리는 비동기 처리로 대체하여 구현했습니다.
12일차: 짝 개선 - 같이 개선하기
짝 개선은 11일차에 만든 자신의 결과물 중 개선할 부분을 찾아 선정하고, 짝과 함께 선정한 부분을 개선하는 과정이었습니다.
기존 결과에서 새로운 것을 추가하지 않고 개선하는 방향으로 진행하라는 지침이 있어, 저는 테스트를 위한 코드 구조 일부 개선과 테스트 추가, 짝은 관심사 분리를 위한 구조 개선을 개선 목표로 선정했습니다.
저희 페어는 아래와 같은 방식으로 개선 과정을 진행하였습니다.
- 짝에게 왜 이러한 부분을 개선하려고 하는 지 설명
- 그 이유에 맞춰 각자의 관점에서 문제를 해석
- 의견 교환을 통해 문제 재구조화
- 세부 구현을 보며 의견 교환 및 수정
나의 개선: 테스트를 위한 구조 개선
11일차 미션에서 어려웠던 점으로 언급했던 부분인 이벤트가 연쇄적으로 발생하는 구조로 인한 상태 변화 추적 테스트의 개선을 위해 호출 구조를 약간 변경하였습니다.
그리고 Jest의 SpyOn을 활용하여 이벤트 발생시 특정 함수가 호출되는지 확인하고, 호출되는 함수가 상태를 적절히 변경하는지 테스트 하는 방향으로 개선되었습니다.
짝의 개선: 관심사 분리를 위한 구조 개선
피어 세션에서 다른 분들에 작업 결과를 보며 특정 클래스가 너무 많은 책임을 가지고있다고 판단하셨고, 이를 함께 개선하였습니다.
클래스의 특정 관심사를 묶어 다른 클래스로 분리하고, 기존 클래스의 메서드를 호출해야하는 부분을 이벤트로 처리하게 변경하였습니다.
이 과정에서 연쇄적으로 처리해야하는 부분이 이전 클래스와 강한 결합이 남아있어 같이 고민하게 되었는데, 제가 콜백 함수를 넘기는 메서드를 제안하였고 이를 반영하였습니다.
저의 의견으로 고민되었던 부분을 개선할 수 있어 뿌듯했네요😁
13일차: 짝 구현 - 페어 프로그래밍
13일차에는 분산 버전 관리 시스템인 Git을 완벽하게 이해해야 해결할 수 있는 미션이 주어졌습니다.
또한 페어 프로그래밍을 통해 주어진 미션을 해결해야하는 조건이 있었습니다.
새롭게 배정된 짝과 어떻게 미션을 수행할지 협의했고, 결과적으로 아래와 같은 흐름으로 미션을 수행했습니다.
- 각자 미션 해결을 위해 필요한 내용들 학습
- 함께 요구사항 분석
- 함께 설계
- 함께 구현
바로 만나서 학습부터 같이 수행하는 것이 아니라 각자 관련 내용에 대해 충분히 학습한 후 미션 수행을 시작하였습니다.
지난주에 했던 방법과 유사하게 VSCode의 Live share를 통해 페어 프로그래밍을 진행하였고, 개발 전 충분한 분석과 설계를 위해 mermaid 를 적극적으로 활용하였습니다.
이전까지는 주로 객체 지향 프로그래밍을 주로 활용했었는데, 짝이 선호하는 함수형 프로그래밍을 시도한 것도 새로운 시도였네요😊
이에 따라 요구하는 기능들을 모듈로 묶어 설계하고 구현하였습니다.
TDD와 애자일스러운 개발
짝에게 애자일스러운 개발과 TDD를 제안하여 시도했습니다.
아쉽게도 저도 이러한 방식에 완전히 적응된 상태는 아니었고, 짝도 불편함을 느끼고 있다는 것이 작업 효율이 떨어지는 것으로 느낄 수 있었습니다.
이러한 이유로 짝이 편해하는 방식으로 자연스럽게 전환되었던 것 같습니다.
파일 시스템 테스트
파일과 디렉터리를 처리해야하는 요구사항이 있었습니다.
테스트 과정에서 실제 파일과 디렉터리를 생성하여 작업하는 것이 적절치 않다고 판단하여 이를 대체할 수 있는 방법을 찾게 되었고,mock-fs를 찾아 적용하였습니다.
하지만… Node v20 환경에서 fs의 모든 파일 쓰기 가 모킹한 가상 디렉터리에 생성되는 것이 아닌 실제 디렉터리에 생성하는 문제가 발생하였습니다.
파일을 처리해야하는 부분이 미션에서 굉장히 중요한 부분이었기 때문에 어떻게든 해결해보려했지만 시간이 많지 않았기 때문에, 이때 부터 테스트 코드를 작성하지 않고 개발을 진행하게 되었네요🥲
전주와 다르게 짝에게 테스트에 대한 긍정적인 인식을 심어주지 못한 것 같아 많이 아쉬웠지만 다음에 이러한 상황이 발생한다면 빠르게 결정을 내려 TDD를 끝까지 이어나가야겠다고 다짐 하게되었습니다👊
14일차: 각자 개선하기
13일차에 짝과 만든 결과물을 각자의 방식으로 개선하는 과정이었습니다.
이러한 단계를 만든 이유를 예상해보자면… 같이 고민하여 만든 결과물이지만, 각자의 방법으로 개선된 결과를 보며 어떠한 생각의 차이를 가지고있는지 확인해볼라는 의도 같았습니다.
12일차 같이 개선하기와 마찬가지로 새로운 것을 추가하는 것 보다는 기존 구현에서 개선해보라는 지침이 있어 기존 결과에서 문제점이라고 생각했던 부분을 개선하였습니다.
나의 개선: 코드 구조 개선
13일차의 미션을 수행할 때 요구하는 기능을 각각 나누어 개발하는 방식으로 진행되었습니다.
구현 과정에서 TDD로 시작했지만 결국 테스트 코드를 작성하지 않게 되었었는데, 이유 중 하나가 모든 기능에서 공통적으로 사용되었던 파일 시스템과의 결합을 적절히 분리하지 못했기 때문이라는 생각을 하게되었습니다.
파일시스템을 통해 파일과 디렉터리를 다루는 부분을 완벽히 분리한다면, 다른 주요 로직들은 파일 시스템을 이용해야하는 데이터를 엔티티로 취급하여 처리할 수 있게 됩니다.
그렇다면 파일시스템 관련 테스트만 배제할 수 있기 때문에 다른 처리에서는 TDD를 지속할 수 있었지 않았을까? 하고 말이죠
그래서 FileSystem이라는 클래스를 별도로 구현하여 파일에 관한 모든 책임을 담당하게 하였습니다.
또한 파일로 핸들링 해야하는 데이터를 정의하여 엔티티처럼 활용할 수 있도록 하였습니다.
추가적으로 주요 처리 흐름을 클래스로 분리해 FileSystem을 주입하여 데이터의 처리 흐름에 집중할 수 있도록 구조를 변경하였습니다.
이러한 변경을 통해 가독성을 높히는 것은 물론, 기존 기능을 구현한 코드의 크기를 획기적으로 줄일 수 있었습니다.
mock-fs
쓰기 작업에서의 이슈로 인해 제대로 활용하지 못했던 mock-fs가 신경쓰여 잠이 안오더라구요😂
이에 다양한 방법들을 시도했지만 결국 해결할 수 없었습니다.
그래서 다른 언어에서도 파일 시스템을 활용한 기능들을 테스트 해야할텐데 어떤 방법들을 활용하고있을까 찾아보게 되었습니다.
해결 방법은 단순했더라구요..🥲
그냥 파일 처리를 테스트할 디렉터리를 따로 만들고, 그 디렉터리에서만 확인하는 것 이었습니다.
테스트 디렉터리를 구성한 후 .gitignore로 해당 디렉터리를 안 올라가게 만들면 되었던건데… mock-fs에 너무 집착한 탓에 충분히 생각해볼 수 있는 단순한 방법도 고려하지 못했던 것 같습니다.
이 일을 계기로 조금 더 여유를 가지고 문제를 바라봐야겠다는 다짐을 해봅니다.🔥
마무리
이번주는 개인적으로 컨디션이 많이 안좋았어서 그만큼 결과물도 좋지 않았던 것 같습니다.
첫주의 각오처럼 결과물을 통해서 인사이트를 드리고 싶었는데 조금 아쉬웠어요. 그래도 다음주에는 에어컨이 수리됩니다.
하지만 그랬기 때문에 개선하기에 더욱 많은 변화를 보여드릴 수 있었을지도 모르겠습니다.
한 주간 모두 고생 많으셨습니다. 부캠 챌린지도 1주밖에 남지 않았네요! 마지막까지 화이팅해봐요🔥🔥🔥