이번 주 한 일들
mock 데이터 기반 마인드맵 저작도구 관련 작업
- 마인드맵 생성( 초기 화면 )
- 마인드맵이 겹치지 않도록 대분류, 중분류, 소분류관의 관계를 파악해 적절하게 위치를 계산합니다.
- 계산된 위치를 기반으로 화면에 그려줍니다.
- 화면에 그린 후 충돌방지 함수가 작동돼 영역 간의 사이를 벌려줍니다.
- 마인드맵 요소 이동
- 요소들이 이동할 때 주변에 있는 요소들과 겹치지 않게 충돌 방지 함수가 작동되며 옆으로 밀려납니다.
- 마인드맵 요소 추가
- 요소를 클릭하여 선택하고, 요소 추가 아이콘을 눌러 하위 요소를 추가할 수 있습니다.
- 마인드맵 요소 Text 수정
- 요소를 더블 클릭하면 텍스트가 input으로 변경되고, 엔터를 누르거나 요소 외부 영역을 눌러 변경 사항을 저장할 수 있습니다.
- 마인드맵 요소 삭제
- 요소를 클릭하면 해당 요소가 선택되고, 쓰레기통 아이콘을 눌러 삭제할 수 있습니다.
이번주 문제 해결 경험
저번 주에는 문제 해결을 하는 방식에 대해서 고민을 많이 했었다. 문제를 해결하기 위해 어떤 개념을 계속해서 dfs 방식으로 찾아보고, 이 과정을 기록하기 때문에 생각보다 많은 시간이 걸려 이 시간 자체가 일정에 영향을 주는 것 아닐까? 라는 생각이 들었던 것 같다. 하지만 멘토님께서 말씀하시길 이 시간 자체가 어찌보면 프로젝트에서 고려해야 하는 시간 중 하나라고 말씀해주셨고, 나는 이를 토대로 내가 구현했던 기술 중에서 고민을 했었던 기술이나 에러에 대해서 이번 주에는 조금 더 공을 들여 쓰기 시작했다.
기술에 대해서 쓸 때는 하나씩 기능을 완성했지만, 나름대로의 기준이나 인수 조건에 부합하지 않는 경우가 많이 나왔었고 이를 문서화 과정에 기록한 후에 이를 보완하기 위한 방법을 고민하여 작성하였다.
트러블 슈팅의 경우에는 내가 어떤 문제를 겪고 있는지, 이 에러가 정확히 무엇 때문에 나오는 지에 대해서 문서에 꼭 포함하려고 했다. 문제의 원인을 자세하게 알려고 하다보니 자연스럽게 원인에 따라오는 해결방법이 있어 이를 적용하면서 문제들을 해결했고, 오히려 코드만을 보면서 하나하나 고쳐보는 것보다 훨씬 속도가 빨라졌음을 체감할 수 있었다.
문서화를 전보다 철저히 하면서 느꼈던 추가적인 장점은 확실히 내가 무슨 문제에 집중하고 있는지 명확하게 인지하고 이를 통한 관련 개념들에 대해서 내가 약했던 부분을 보완할 수 있었다는 점이었다. 이를 통해 성장한다는 보람과 함께 쉽게만 생각했던 부분에 대해서 생겨난 학습적 구멍을 메울 수 있었다고 생각한다.
이를 특히 느꼈던 순간은 zustand와 context api의 사용 과정이었다. 기존 context api를 활용했을 때 마인드맵에서 노드가 많아질 수록 성능이 좋지 않아짐을 느꼈다. 이를 해결하기 위해 zustand와 렌더링을 최적화 시켜주는 selector 패턴을 사용하여 리팩토링을 진행했었다. 하지만 결과는 context api가 더 좋은 성능을 보였고, zustand의 경우 프레임 드랍까지 이어졌다.
기존에는 무조건 context api보다 zustand가 렌더링 성능 별로 좋다고 생각했지만, 실제로 해보니 예상과는 다른 점도 분석해 보면서 이를 기록하고 기존에는 몰랐던 새로운 지식 또한 알 수 있었다.
피어세션 기록
동료와 공유하거나 의견을 묻고 싶은 부분을 정리해보세요.
피어세션에서 나눈 이야기 중 나의 문제 해결 경험과 관련한 피드백과 새롭게 깨달은 점이 있다면 기록으로 남겨주세요.
마인드맵의 스타일
뭔가…뭔가 스타일이 좀 트렌디하지 않은 느낌인데 제 눈이 구려서 뭐가 문제인지 모르겠어요…..
기획적인 부분
- 마인드맵의 현재 Depth는 일정 depth로 제한하려고 하는데 이 점이 문제가 될까 고민중입니다.
팀 멘토링 기록
- 성능 최적화의 도입 시점
- 성능 최적화는 가장 마지막에 리팩토링 기간에 하는 게 맞는 것 같다
- 현재는 문제가 없게끔 기능 작동을 시키는 것이 우선
- 성능 최적화를 하려고 하면 모든 팀원들이 최적화를 위해 블락된 상태가 되기 때문에 일정에 좋지 않은 영향을 끼친다.
- 기술적으로 성능을 최적화할 수 있겠지만, 기획적으로도 최고의 성능을 낼 수 있을 정도로 제한해도 문제될 것은 없어 보인다
- 기술적으로 성능을 최적화하는 것이 무조건 완료하지는 않아도 이를 고민해보았다는 것도 기록해놓으면 좋을 것 같다
- 테스트 코드 작성
- 개인적으로 멘토님은 프론트엔드에서의 테스트 코드는 어느정도 성향 차이가 있다고 생각하심
- 테스트 코드를 작성해야만 하는 이유가 명확한 부분만 테스트를 해봐도 좋을 듯하다
- 무의미한 테스트 코드는 딱히 필요가 없을 것 같다.