Skip to content

5주차 데일리 개인 회고

n-ryu edited this page Dec 6, 2022 · 29 revisions

12월 5일 월요일

수빈

  • 사실
    • 점심에는 롯데리아, 저녁에는 닭갈비를 먹었다. (둘 다 같은 건물이었음)
    • 이력서를 썼다.
    • 소요시간 컴포넌트를 jotai로 전환했다.
    • 마스터클래스 시간에 이력서 피드백을 받았다.
    • 사무실 히터가 고장나서 사장님께서 다른 히터를 가져다주셨다.. (감동)
  • 생각 & 감정
    • async atom(jotai)+ suspense 조합이 생각보다 잘 되지 않았다. 중간에 에러도 많이 만나고, 이해가 되지 않는 부분들이 많아서 react suspense와 jotai에 대해 좀 더 많이 공부해봐야겠다는 생각이 들었다.
    • 이력서 피드백을 받으면서, FE 엔지니어링에 대한 내용을 너무 자세히 쓰지 않았다는 것을 알게 되었다. 좀 더 FE에 대한 내용을 많이 쓰는 게 좋을 것 같다. 거기에다가 나는 아직 많이 부족한 사람인 것 같다는 생각이 들었다,,
    • 벌써 5주차라는 게 믿기지가 않는다.. 나는 그동안 얼마나 성장했는가?에 대해 스스로에게 질문을 던져보았다. 지금까지 내가 배운 것은 욕심을 덜어내는 게 중요하다는 것을 깨달은 점, Why에 집중해서 의사결정을 해야 한다는 점 정도인 것 같다. 남은 시간도 좀 더 열심히 해서 성장하고 싶다.
  • 피드백
    • 능 : 결국 문제들을 모두 해결한 끈기 멋져요....! 오늘 고민과 문제들 이야기 들으면서 생각한건데, Jotai가 문서가 간단한 만큼 은근 뜯어보는게 쉬울 수도 있지 않을까? 싶어서, 프로젝트 끝나고 한번 같이 스터디해봐도 좋을듯! (React랑 강결합되어 있지만 않으면 아마 생각보다 진짜 간단할지도 모를거 같아) 맨날 고민인 리액트의 동작방식도 같이 공부하면 더더 좋을듯...
    • 대성 : 정말 시간이 빠릅니다.. 어떤 방향에서의 성장인가도 중요하다고 생각하는데 나는 진짜 그룹 프로젝트를 통해서 여러 차원의 틀을 깨는 느낌을 받은 것 같아! 인간은 변하지 않는다지만.. 조금은 변할수도..?

  • 사실
    • TodoList API를 조금 리팩터링 했다.
    • 다이어그램 페이지를 위해 데이터를 가공하는 로직을 작성했다.
    • 이력서를 작성했다.
    • 점심에는 햄버거, 저녁에는 닭갈비를 먹었다.
    • 무릎담요를 샀다.
    • 킹갓제너럴 나경님이 손목받침대를 빌려주셨다.
  • 생각 & 감정
    • 손목받침대는 아직은 공감이 잘 안된다.... 뭔가 불편하지는 않은데, 더 편한것도 모르겠는...? 뭘까.. 나란 인간은 맨발로 평생을 살아온 인간이 되어버린걸까...? 뭔가 억울해서라도 빨리 손목받침대의 소중함을 깨닫고 싶다.
    • 무릎담요가 생각보다 엄청나게 따뜻했다... 그동안 왜 이런걸 모르고 살았지?
    • 햄버거, 닭갈비, 좋은데 뭔가 무거운거 같기도 하고... 뱃속이 무거운데도 식사시간이 기다려지는건 배가 고파서가 아니라 그냥 놀고싶어서 그런게 아닐까 하는 생각이 아주 잠깐... ㅎ 아주 잠깐 지나갔다.
    • 이력서는 정말 쓰기 힘들다... 워낙 이리저리 많은 분야를 거쳐와서 인가... 하나도 남기지 않자니 그동안 한게 없는 사람이고, 일부라도 구구절절 남기자는 너무 구구절절한 사람같고... 어렵다는 생각이 들었다. 지금은 일단 개발이라는 분야에서의 경험을 최대한 자세히 적는 쪽으로 마음을 굳혔다.
    • 원래 오늘 다이어그램의 마크업도 다 해놓을 생각이었는데, 전혀 진행하지 못했다. 내가 너무 마음이 풀려있었던 탓이 큰것같기도 하다....
    • 마찬가지로 다이어그램 데이터 가공 로직을 짜는데, 너무 절차지향적으로 짰다는 생각이 들었다. 뭔가 알고리즘 문제에 가까운 태스크다보니 나도 모르게 PS를 하며 C++ 코드를 짜던 형태로 구현해버린것 같은데, 어떻게 리팩터링해야 할지 감이 잘 잡히지 않는다... 어렵다...
    • TodoList API 리팩터링을 하면서 아직도 많은 과제가 남았다는 생각이 들었다. 그동안 스리슬쩍 남겨둔 문제들이 꽤 있는데 언젠가 꼭 열어서 다 정리할 수 있으면 좋겠다.
    • 집에 돌아오면서 대성이와 TodoList API의 개선 방향에 대해서 이야기를 나누었다. 일반적인 프론트엔드 개발 철학 이 서로 독립적인 (순수한)정보들이 위치하고, 이들을 연결하는 관계와 관계에서 오는 결과값들은 함수로 도출한다... 가 맞고, 지금의 형태는 여전히 TodoList가 DB에 의존적이라 완전한 독립이 필요하다. 이들을 분리하면서 TodoList와 DB의 추상화는 그대로 유지해서 인터페이스만 노출한다면 내부적인 리팩터링도 자유롭고 독립성도 지킬 수 있으리라 생각한다. 다만 이 "순수성"과 "추상화"의 범주를 어디까지 잡아야할지가 불명확한 점은 고민이다. 둘의 관계가 절대 변하지 않는다면 합쳐 생각해도 될까? 런타임에는 변하지 않더라도 확장성을 고려했을때 해가되면 분리해야 할까? 아무래도 BE가 없어서 FE에서 이런 고민을 너무 많이 하는 것 같기도 하고... 어려운 고민이다.
    • Jotai, Suspense, 그리고 SSL 등 수빈이나 나경이가 한 작업들에 많은 도움을 주지 못해서 뭔가 아쉬웠다. 빨리 나도 공부를 하고, 관련된 문제를 함께 고생하며 느껴야 뭔가 더 많이 성장하고 팀원들에게 도움도 될 텐데, 작업들이 분리가 되어있다보니 서로 고민이나 생각, 지식을 더 잘 공유할 수 있는 방법이 무엇이 있을까 하는 생각이 들었다.
  • 피드백
    • 대성 : 매번 매서운 피드백 감사합니다! 언젠가 형도 납득할만한 이유를 줄 수 있는 사람이 되겠슴니다.. 나도 도움이 되고 싶다~~

대성

  • 사실
    • Tooltip을 구현했다.
    • 양념감자를 먹었다. 닭갈비를 먹었다. 사실 둘 다 많이 좋아한다.
    • 능 형과 무릎담요를 샀다. 근데 사장님이 히터를 주셨다.. 너무 아늑하다.
    • 끝나지 않는 이력서를 작성했다.
  • 생각 & 감정
    • Tooltip 구현에 앞서 또 내 고질병이 도졌다. 어떤 생각을 하고 구현을 해야할지 고민이 있었는데 1번 생각과 같이 잘못된 생각을 하고 있었다.
      1. 너무 다양하기 때문에 대표적인 라이브러리가 구현한 방식을 모사해보자!
      2. 내가 지금 이 툴팁을 구현해서 어떤 목표를 달성하려하는가?
      • 1번의 접근 방법은 베스트 프랙티스를 배워보겠다, 벤치마킹 해보겠다는 목표를 세웠을 때 적합할 것이다. 그렇지 않은 경우에는 기획을 개발에 끼워맞추는 격이고 좋은 학습이 될 수도 있지만 자원이 필요 이상으로 소모될 것이다.
      • 항상 내가 왜 구현해야하는지, 어떤 기획을 가지고 있는지를 생각하자! 필요한 만큼의 기능이 무엇인지 파악하고 구현한 뒤 또 내가 불편함을 느끼고 그 다음 스텝의 이유를 찾아 발걸음을 내딛자.
    • 스스로의 MVP를 정하는 것이 중요한 이유
      • 무엇을 얻어갈 것인가? → 아무 생각 없이 일단 구현 혹은 애매한 디테일만 추가할 경우 “왜 그렇게 했어”라는 질문을 당연히 받게 되고 아무 대답도 못하게 된다. 구현에 앞서 고민한 것과는 반대지만 비슷한 결과를 맞이하게 된다. 그저 좋아보이는 것들을 따라해놓고 아무것도 얻어가지 못하는 상황을 겪을 수 있다.
      • 항상 답이 있는 문제들에 대해 정답지 혹은 그에 준하는 베스트 프랙티스만 보고 살아왔었다. 문제를 풀기 위해서라면 분명히 효율적이고 좋은 방법일 것이다. 근데 지금 내가 마주하고 있는 것들은 답이 없는 것들이고 문제조차도 내가 정의해야하는 것들이다. 대학원 생활때 항상 느껴왔던 기분을 또 느꼈다.
    • 항상 집 가는 길에 이것 저것 재밌는 이야기를 나누게 된다. 그 이야기에도 내 고질병이 살짝 포함되어 있어 능 형과 수빈이를 자극하기에는 충분했다.. 이야기를 요약하자면 FE에서의 API를 구현하는데 데이터와 로직을 분리할지 데이터와 로직을 묶고 의존성을 없앨것인지에 대한 논의였다. 내 주장(분리하자!)에 대한 근거는 가독성, 사용성, 함수형 컴포넌트와의 결이었다. 물론 근거가 빈약하기에 직접 간단히 비교하기 위해 간단한 Todo를 구현하는 과정을 겪어보고 더 보충하려고 했었지만 시간과 자원이 문제였다. 애초에 구현 경험 자체가 부족하다보니 스스로 답을 얻고 싶어서 억지 주장을 한 감이 있다. 어쨌든, 그 반대편의 근거는 먼저 사용성은 묶는 편이 훨씬 좋다는 것이었다. 확실히, private 메서드, 체이닝, 메서드 접근와 같은 특성때문에 사용성이 더 좋다고 할 수 있는데 괜히 함수형 뽕에 맞아서 시야가 좁아졌었다. 그래서 굳이 옆그레이드를 왜하냐라는 반박할 수 없는 팩폭에 어지러웠다.. 분리도 좋지만 언제 어떤 함수(메서드)를 어디에서 호출해야하는지에 대한 trade-off가 존재하기 때문에 좀 더 철저하게 따질 줄 알아야되는 것 같다..
  • 피드백
    • 능 : 항상 왜 해야하는지? 내가 얻고자 하는게 무엇인지? 실제로 얻은게 무엇인지? 얻은게 예상과 달랐다면 그 원인은 무엇인지? 이런 것들을 잘 정리하는게 중요한 것 같아!!! 나도 잘 못하는 거지만 항상 너랑 이야기하다보면 잘 생각나서 상대적으로 생각 많이 하고 하는 것처럼 보이는거지 글쓰는거 보면 나도 우당탕탕이여~ 다 하면서 배우는 거지~~

💊 비타500

📌 프로젝트

🐾 개발 일지

🥑 그룹활동

🌴 멘토링
🥕 데일리 스크럼
🍒 데일리 개인 회고
🐥 주간 회고
👯 발표 자료

Clone this wiki locally