ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Portfolly] 스프린트 2주차 회고
    Studying/Proj 과정 2023. 7. 16. 13:43

    벌써 2주가 지났다는 게 충격적입니다. 초반에는 '이 정도 기간이면 다 구현하고 남겠다'라고 생각했는데,

    어느 시점에서 블랙홀에 빠진 것처럼 시간이 증발해 버렸습니다.

     

    어쩌면 처음엔 큼지막한 기능만 생각하고 충분히 할 수 있다고 생각했다가,

    막상 해보니 디테일하게 신경 써야 할 부분들이 뒤늦게 떠올라 급해진 것 같습니다.

     

    그래도 이번주에 기본적인 기능은 돌아가는 걸 확인했으니 기분 좋게 한 주를 되돌아볼 수 있게 되었습니다.

     

     

    1. 나의 약점은 무엇인가

     

    1) 틀에 찍어낸 코드처럼 늘 작성하던 방식대로만 작성하려고 합니다.

     

    react-quill 이미지 업로드를 위한 이벤트 핸들러를 훅으로 분리하여 작성하던 중, 훅에 에디터의 ref를 전달해야 하는 일이 발생했습니다.

     

    하지만 훅에 초기값이 전달되는 시점에는 DOM이 업데이트 되지 않아 undefined일 수밖에 없었습니다.

     

    '어떻게 하면 훅에 초기값으로 ref를 전달할까?'라는 고민에 휩싸여 이틀을 고민했는데, 어느 순간 '왜 굳이 훅 초기값으로 주려고 했지?'라는 의문이 들었습니다. 그리고 훅을 통해 반환받는 핸들러 함수 자체의 props로 전달하면 된다는 것을 깨달았습니다.

     

    평소에 훅을 사용할 때 초기값으로 연산에 필요한 모든 값을 주다 보니 이번에도 역시나 그런 식으로 하면 될 거라 생각한 것이었습니다. 조금만 다르게 생각하면 아주 간단하게 해결될 문제를 '초기값으로 전달해야 한다'라는 이상한 집념에 갇혀 시간을 보내버렸습니다.

     

    평소에도 '아 이거 예전에 짜본 코드인데' 하면서 아주 자연스럽게 예전에 작성한 코드를 같이 펼쳐놓고 과거의 내 코드를 베끼듯 작성하곤 했습니다.

     

    그러다보니 늘 똑같은 로직에 똑같은 코드를 짜게 되고, 발전이나 변화가 없고, 그로 인해 성장이 더뎌진 것 같습니다. 이제 그런 습관을 버리고 늘 그때 그 순간에 필요한 코드를 처음부터 끝까지 직접 작성하겠다고 다짐했습니다.

     

    2) 커스텀을 무서워하고 피해버리는 편입니다.

     

    예전부터 그래왔는데 특정 라이브러리를 커스텀하여 사용할 수 있다고 하면 덜컥 겁이나고 어렵게만 느껴집니다.

     

    이번 react-quill 에디터의 경우에도 toolbar와 textarea를 커스텀으로 분리시키는 방법이 있다는 걸 알면서도 커스텀 툴바를 만드는 게 어려워 보여 못 했습니다.

     

    어려워 보이는 이유는 바로 라이브러리가 코드에 적용되어 동작하는 흐름을 모르기 때문이라고 생각합니다. 커스텀 툴바 파일을 만들고, 그걸 등록하는 과정은 다른 블로그 가이드를 통해 할 수 있지만, 저의 작업 환경에서 뭔가 제대로 동작하지 않을 때 그 흐름을 파악하고 있지 않으니 고칠 수가 없었습니다.

     

    분명 간단한 방법일 텐데 어떤 파일이 무슨 방식으로 돌아가는지 파악하는 걸 귀찮게 여기니 그런 것 같습니다.

     

    시간이 남는다면 이 부분도 꼭 제대로 공부해서 저 같은 사람(?)을 위해 아주 간단하면서도 자세하게 설명하는 블로그를 작성해보고 싶습니다.

     

    2. 나의 강점은 무엇인가

     

    1) 코드를 분리하는 데 제법 감이 오는 것 같습니다.

     

    별 거 아닌 단순한 기능에, 단순한 함수를 바깥으로 빼는 것 뿐이지만 예전에 비하면 코드를 분리하는 실력이 조금 성장했다는 기분이 듭니다.

     

    과거에는 정말 말 그대로 머리가 잘 안 굴러가서 어떻게 빼내야 할지 몰랐는데, 이제는 '이 부분은 다른 곳에서 쓰일 수 있으니까 따로 만들어야지'라는 생각이 먼저 들곤 합니다.

     

    A기능과 B기능의 교집합을 찾아 A, B 어디서든 쉽게 사용할 수 있는 별도의 코드를 작성한다는 것 자체가 이제는 즐겁고 코드를 짜는 것에 있어서 가장 재밌는 포인트가 된 것 같습니다.

     

    2) 코드를 작성한 이유를 천천히 설명할 수 있습니다.

     

    예전에는 그저 블로그를 참고해서, 강의 자료에서 이렇게 쓰라고 해서 작성한 코드들의 집합이었습니다.

     

    그러다 보니 조각조각 합친 프랑켄슈타인 같은 코드가 완성되었는데 그저 동작한다는 이유로 만족했습니다.

     

    하지만 누군가 어떤 부분을 짚으면서 굳이 이렇게 짠 이유가 있냐,라고 물었을 때 '내가 작성했지만 내 코드가 아니었구나'라는 걸 깨달았습니다.

     

    그 이후로는 근거 있는 코드를 짜는 걸 가장 근본적인 마음가짐으로 두었습니다. 이번 메인 프로젝트에서도 특정 라이브러리를 쓰는 이유, 함수를 정리한 이유에 대해 스스로에게 질문하고 정확한 답변을 한 뒤 코드를 작성했습니다.

     

    그러다 보니 에러에 부딪혀도 코드 자체를 파악하고 있으니 해결하는 시간이 확 줄어들고 (다른 사람이 보기에 부족할지라도) 당장은 확신하는 마음으로 코드를 작성하게 되었습니다.

     

    3. 나의 팀워크 방식은 어떠한가

     

    제가 경험한 걸 바탕으로 작은 팁을 공유하며 프로젝트를 진행합니다.

     

    예전에는 경험 자체가 부족해 공유할 팁이 없거나, 제 방식이 부끄럽다고 느껴져 작은 팁이라도 공유해본 경험이 잘 없었는데, 이번에는 조금 용기를 내보았습니다.

     

    질문하는 방법에 대해 여쭤보시길래 처음엔 부끄러워서 농담 식으로 대답했는데 너무 도움이 안 되는 거 같아서 제 경험을 바탕으로 다시 한번 답변을 드렸습니다.

     

    '불특정 다수에게 가르쳐주듯 글을 쓰다 보면 내가 지금 누군가에게 가르쳐줄 만큼 잘 알고 있지 않은 부분들을 발견하게 되고, 그 부분에 대해 질문하면 된다'라는 팁을 건넸는데... 그걸로 도움을 드릴 수 있는지는 모르겠지만 그래도 팀원과 그런 부분들을 공유한다는 게 부끄러워할 일이 아니라 팀협업의 재밌는 과정이라는 걸 깨달았습니다.

     

    또한 코드를 구현하면서도 비동기 데이터 요청 함수를 따로 빼는 것에 대해 팀원 분께서 좋아해주시고 편하게 사용해 주셔서, 내가 작성한 코드로 다른 사람이 (매우 조금이지만) 편하게 구현할 수 있다는 점이 기뻤습니다.

     

    4. 나의 열정은 어떤 방식으로 표출되는가

     

    계속해서 리펙토링 하기 위해 다양한 방식을 떠올리고 기록해둡니다.

     

    한 가지 기능을 구현할 때 2가지 이상의 방법이 떠오르면 그중 하나를 선택해서 밀고 나가는 게 아니라, 다 구현하고 나면 다른 방법으로 고쳐보고 비교해야지 라는 마음가짐을 늘 하고 있습니다.

     

    이번 스프린트에서 구현한 좋아요 기능의 경우 useToggle 훅을 만들어 단순히 isClicked 같은 상태값으로 관리했지만,

    react-query를 써서 optimistic update 방식으로 구현하는 방법도 있었습니다.

     

    다른 기능들 또한 전역 변수로 관리해도 깔끔할 것 같다든지 여러 방법들이 떠올라 지금 구현한 것에 그치지 않고 다른 방식으로 다시 구현할 계획을 세워뒀습니다.

     

    그렇게 다양한 방법을 기록해 두는 제 모습을 보니 과거에 비해 훨씬 프로젝트에 열정적인 태도로 변했음을 깨달았습니다.

     

    5. 나의 근면성실을 어떻게 설명할 수 있는가

     

    프로젝트 과정을 꼼꼼하게 블로깅 하고 있습니다.

     

    그 속도는 빠르다고 할 수 없지만...

     

    그래도 까먹지 않기 위해 구체적인 상황, 참고한 자료, 시도/해결한 과정을 하나도 빠짐없이 적어두고 있습니다.

     

    당장은 구현을 완성하는 게 더 중요해서 가끔 기록하는 게 귀찮게 느껴졌지만, 까먹지 않을 정도로만 간단히 작성하는 것은 10분만 투자하면 되는 걸 알기에 꾹 참고 적어나갔습니다.

     

    또 그렇게 적고 보니 든든한 뒷받침이 되는 것 같아 뿌듯함을 느끼고 점점 고정된 습관으로 굳혀나가고 있습니다. 

     

    6. 나는 왜 업무를 즐기는가

     

    더 나은 방향으로 가는 방법만 존재한다는 걸 알기 때문에 즐기는 것 같습니다.

     

    이번주부터 본격적인 기능 구현에 나서게 되었습니다.

     

    확실히 UI 구현보다는 다양한 방면을 고민하게 되었습니다. 어떻게 해야 단순해질까, 불필요한 중복을 제거할까, 다른 방법은 무엇이 있을까 고민하다 보면 결국엔 현재 작성한 코드보다 더 나은 코드를 향해 달려가는 걸 느낄 수 있습니다.

     

    이전 코드와 이후 코드를 명확하게 비교할 수 있는 판정 기준이 있으니 적어도 점점 뒤로 퇴보할 일은 없다는 점에서 재밌게 코드를 작성할 수 있는 것 같습니다.

     

    이번주에도 useLikeBtn, useBookmark 훅을 useToggle로 합치면서 개선을 느꼈습니다. 또한 앞으로 테스트해보고 싶은 성능 개선 사항들(코드분할, 이미지 로딩, 전역상태관리 등)을 떠올리면 전후 비교 결과가 어떻게 나올지 정말 기대됩니다.

     

    7. 내 능력 중, 내가 구직하고자 하는 회사가 기대하는 것 이상의 능력이 무엇인가

     

    제가 맡은 프로젝트에 주인의식을 가집니다.

     

    최근 커리어리에서 어느 개발자의 게시물을 읽고 프로젝트를 향한 저의 태도에 대해 다시금 확신하게 되었습니다.

     

    게시물에선 책임(responsibility)과 주인의식(ownership)의 차이에 대해 설명했습니다.

     

    책임이란 주어진 바를 제대로 끝내는 것에 초점을 둔다면, 주인의식은 주어진 바로 끝나는 것이 아닌 더 나아가 어떻게 개선을 할 수 있는지 계속해서 고민하는 것입니다.

     

    조금 민망하긴 하지만 그래도 저는 제가 맡은 업무에 있어 주인의식이 강하다고 말할 수 있습니다. 늘 이후를 생각하면서 코드를 구현하느라 적당한 스트레스도 받고 즐거움도 느끼기 때문에 스스로 장담할 수 있습니다.

     

    현재 함수나 훅을 분리해서 구현하는 부분들도 전부 '나중에 00님이 어떤 기능을 추가하고 싶을 때 이것만 넣으면 되겠지'라는 생각이 든 부분들이었습니다.

     

    이미지 핸들러 훅에 ref를 못 보내 고민하던 것도, 그냥 분리하지 않고 한 파일에 합쳐 적으면 해결 될 문제였지만 다른 팀원이 맡은 게시물 작성 페이지에도 언제든 이미지 핸들러를 추가할 수 있도록 분리하여 작성했습니다.

     

    8. 내가 신뢰할만한 사람인 걸 어떻게 설명할 수 있는가

     

    코드 한 줄 한 줄에 나름의 근거가 있다는 점에서 신뢰도를 높일 수 있습니다.

     

    강점을 설명할 때도 말했지만, 최대한 근거 있는 코드를 짜려고 노력합니다.

     

    누군가 '왜 이런 방법으로 코드를 짰어?' 라고 물어봤을 때 어... 그냥? 다들 그렇게 해서. 라고 대답하면 신뢰할 수 있는 개발자라 말하기 어렵다고 생각합니다. '그냥 그렇게 해야되는 줄 알았다' 라는 대답은 절대 하지 않으려고 합니다.

     

    비록 부족한 코드일지라도 제 나름대로 체계적으로 생각하며 코드를 구현했다는 것을 증명할 수 있다는 점에서 신뢰가 간다고 생각합니다.

     

    9. 내가 체계적인 사람이란 걸 어떻게 증명할 수 있는가

     

    코드 흐름을 정확히 파악하려고 합니다.

     

    최근들어 훅 플로우 관련해서 자주 문제가 발생한다는 걸 깨달았습니다.

     

    리액트를 공부하면서 제일 잘 알고 있어야 하는 근본적인 부분인 만큼 직접 경험해보지 않으면 절대 머리에 녹일 수 없다고 판단되어 다양한 테스트를 해보았습니다.

     

    다양한 위치에서 상태를 변경해보고, 훅을 호출하고, useEffect를 따로 비교하면서 발생 시점들을 차근차근 출력했더니 그제야 흐름 파악에 조금 확신이 들었습니다.

     

    제가 잘못 판단했던 부분들이 하나둘 눈에 보이기 시작하자 문제 해결도 금방이었습니다. 다만 문제 해결을 위해 아주 돌고 돌긴 했지만 그 과정에서 코드가 실행되는 흐름을 깨달았기 때문에 전혀 아깝지 않았습니다.

     

    10. 내가 고객중심으로 사고하는지 어떻게 설명할 수 있는가

     

    현재 프로젝트와 관련된 성능 향상 방법에 대해 공부하고 있습니다.

     

    현재 프로젝트에서 맡은 업무는 포트폴리오 상세보기와 포트폴리오 작성/수정 입니다.

     

    포트폴리오라는 특성이 그렇듯 고화질 이미지를 업로드해야 하기 때문에 관련된 성능 향상 기법이 없는지 궁금했습니다.

     

    그 방법을 찾기 위해 프론트엔드 성능 최적화 가이드라는 책을 읽고 구체적인 방법들을 배우게 되었습니다.

     

    이미지 사이즈 최적화, 지연 로딩, 이미지 사전 로딩, 이미지 포맷, 레이아웃 이동 피하기 등 여러 기법을 읽으면서, 홈페이지를 이용하는 고객이 마주할 수 있는 다양한 문제에 대해 다시금 생각해보고 현재 작성한 코드에서 어떤 부분들이 그런 문제를 발생시킬지 추측하고 개선점을 찾게 되었습니다.

     

    11. 내가 다른 팀원과 다르다면 어디가 다른가

     

    DRY한 코드를 작성하려고 합니다.

     

    최대한 반복되는 코드는 적지 않으려 합니다. UI를 구현할 때나 기능을 구현할 때나 최대한 재활용 할 수 있는 부분을 간추려내 하나의 파일을 어디든 적용 가능하게 만들고자 합니다.

     

    12. 내가 한 모든 업무를 나열해 보시오

     

    1) 2주차 멘토링 코드리뷰 후 전체적인 코드 정리

    2) 좋아요, 북마크 기능 구현

    3) 카테고리별 태그 선택 기능 구현

    4) 프로젝트 작성/수정 페이지 POST 요청 MSW로 테스트

    5) React-Quill 이미지 업로드 기능 구현

Designed by Tistory.