티스토리 뷰

활동/Dev Course 회고

감동이 있는 STU-TI 회고

geonwoopaeng@gmail.com 2022. 8. 18. 20:57

STU-TI

STUDY + MBTI

MBTI 와 개발자 스터디를 결합하여 성격이 맞는 사람끼리 스터디를 진행 하도록 하는 서비스 입니다.

배포: https://stu-ti.netlify.app/
Github: https://github.com/prgrms-web-devcourse/Team_KPPL_STUTI_FE
YouTube: https://www.youtube.com/watch?v=MlLwIza06fw

많이 사용을 해주시고 문제점을 알려주시면 계속해서 리팩토링을 해보도록 하겠습니다.!!! 할 것이 여러개 보이긴 합니다. : )

FE 팀 팀장으로 프로젝트를 하면서 많은 경험을 했지만 가장 기억에 남는 것들 위주로 회고를 작성하겠습니다.

😶‍🌫️ 프로젝트 순서

  1. 팀 Commit, Code Convention 및 Git Branch 전략 짜기 -> Github 보기
  2. Figma를 보면서 어떤 기능, 데이터가 필요한지 파악 및 유저 시나리오 작성
  3. UI 뼈대 만들기 + Storybook
  4. 1번을 보면서 기능 구현하기 + Mock Data Test
  5. Page에 붙이기
  6. Page내에서 필요한 기능 개발(무한스크롤 등...)

🤨 FE 와 BE

> 의사 소통의 중요성 및 팀 문화 <

FE 5인 + BE 3인의 다수의 인원이 팀을 이루어 프로젝트를 하고 FE 팀장을 맡으면서 뭔가 진행자 역할도 맡게 되었습니다.

팀장, 팀원으로의 책임감과 프로젝트를 잘 마무리 하고 싶은 마음에 BE 와 FE의 중간다리 역할을 하도록 노력했었습니다.

BE와 FE 협의 하면서 프로젝트에 대한 화면 및 기능을 마무리 했는데 추후 BE에서 연락을 받게 되었습니다.
BE의 작업량이 생각보다 너무 적어 도메인을 나눌 수가 없고 중간 프로젝트보다 더 많은 것을 해보고 싶다는 것 이였습니다.

처음에는 왜? 협의를 해서 마무리 했는데 ? 코드를 더 최적화하면 되지 않나? 라는 생각이 있었지만
좀 더 BE입장에서 생각을 해보니 FE와 같이하는 프로젝트이고 좋은 기회이니 장점, 스킬을 더 어필 하고 싶은 것이 당연하다는 생각을 하게 되었습니다.

그래서 이에 대한 내용을 FE팀에 잘 전달하려 했지만 FE도 빠듯해서 크게 추가를 안하는 편이 좋다는 의견이 나와 초반에 의견 대립이 있었습다.

중간에서 힘들게 이야기하는 편보다 같이 편하게 이야기를 해보는 편이 좋다고 판단이 되어 같이 이야기를 진행하여 커뮤니티 부분을 추가하는 식으로 합의가 빠르게 되었습니다. 이로 인해 자신의 생각을 자유롭게 드러내는 팀 문화 와 의사소통이 중요하다는 것을 깨닫게 되었고 문제점이 있을 때는 왠만하면 전체에 알리려 했고 같이 이야기를 나눠 좀 더 단단하고 소통이 원할한 팀이 되었습니다.

> BE 지식 <

개발을 진행하면서 ERD등 BE에 대한 주요 언어 인식 부족과 Api에서 PATCH는 FormData를 전송하지 못한다는 문제등 BE에 관련 지식부족으로 인해 의사소통이 삐걱이는 문제가 있었습니다.

구글링을 하고 물어보며 문제를 해결하였지만 개발 시간이 좀 지체되어서 꼭 BE를 공부 해야겠다는 생각을 하게 되었습니다.

진짜 의사 소통이 중요하다....

😎 화면 및 기능 명세

회의를 통해 어떻게 하면 팀원과 멘토님이 한눈에 파악할 수 있을까? 고민을 한 결과 회의 내용을 바탕으로 명세를 한번 만들어 보았습니다.

012

Design 부분과 기능 부분이 추가 되기도 했지만 정말 좋은 방법인 것 같고 이번에는 완성된 Design과 기능에서 활용하지 못했지만 Figma내부에 명세를 같이 넣어서 활용하고 싶습니다. :) 

🥸 New Tech

FE 팀에서는 기술을 사용할 때 회의를 통해 왜? 라는 이유를 가지고 기술을 선택하였습니다.

그러나 TS의 Type 맞추기, Mui Props, Component 파악, Mui + Formik 사용 등등 새로운 기술을 사용해 짧은 시간안에 퍼포먼스를 내는 것은 쉽지 않았습니다. =.=

처음에는 하나하나 개념부터 찾아보려 했지만 프로젝트 완료 기간을 맞추기 위해 링크로 적어두고 빠르게 구글링과 팀원에게 물어보는 식으로 문제를 해결하고 나아갔습니다.

그래도 많은 것을 얻게 되었고 다음에는 더 쉽게 나아갈 수 있을 것 같고 Error를 많이 발견한 만큼 계속 성장하고 있다는 생각이 들어 기분이 좋습니다. :)

🤯 rebase

이번 팀에서는 깔끔한 것을 원했기 때문에 git rebase를 사용하였습니다.

gitrebase

그런데 PR을 날리려고 보는데 git commit 부분이 여러개 겹쳐있었습니다.

Screen Shot 2022-07-31 at 12 15 14 AM

그래서 왜? 겹치게 보이는지 생각을 해본 결과
rebase를 하면서 다 다시 merge한 것을 다시 add하고 commit해서 생긴 문제인가? 생각을 했습니다.

그래서 중간 중간에 push를 하지 않고 commit으로 해당 컴퓨터에 저장하고 한번에 push하자 라고 생각을 했지만 문제는 해결되지 않았습니다.

그래서 계속 고민을 하고 여러 방법을 사용해본 후 동료한테 물어본 결과 push -f로 공통된 것을 덮어씌우지 않아 생긴 문제였습니다.
push만 사용하였을까.... 역시 물어보길 잘했다!!!!

추가로 적어둔 git rebase 방법입니다. :)

Screen Shot 2022-08-18 at 7 45 50 PM

😎 Community Post

커뮤니티 부분 즉 Facebook과 같은 피드들을 만드는 작업을 맡았습니다.
(여기서는 피드를 포스트라고 부르겠습니다. )

쉽게만 봤던 포스트를 만드는데 포스트 안에는 Modal, 댓글, 사진등 많은 것들이 들어 있었고 막판에 많은 문제들을 BE분과 같이 해결하고 깨닫는 시간이어서 회고에 작성을 하게 되었습니다.

> Ellipsis & ReadMore<

처음에는 4줄 넘어가면 Ellipsis 처리 해야겠다 라는 생각으로 CSS에서 Ellipsis를 처리하면 끝이 나는 줄 알았습니다.

export  const  ContentsWrapper = styled.div`
    text-overflow: ellipsis;
    overflow: hidden;
    display: -webkit-box;
    -webkit-line-clamp: 4;
    -webkit-box-orient: vertical;
`;

그런데 더보기(ReadMore) 버튼을 생각하지 않아 문제가 발생하였습니다.

처음에 문자 길이에 맞춰 slice()하여 ...을 마지막에 추가하는 방식으로 개발을 했었습니다.

그런데... 단어를 중간에 끊는 것이 예뻐보이지 않아 split('')로 단어 개수에 맞춰 Ellipsis 처리하는 식으로 개발을 했습니다.

그런데... 이 방법도 다 각각 Ellipsis 처리 범위가 달라 문제가 발생하였습니다.
길이 만으로는 해당 문제를 해결할 수 없겠다 느껴 높이로 한번 해봐야겠다 라고 생각을 하게 되었습니다.
그래서 getBoundingClientRect()를 사용하여 높이를 파악 후 값을 파악해서 Ellipsis 처리가 되게 만들었습니다.

더보기 버튼 문제를 해결 !!!

const [isExpand, setIsExpand] = useState<string | number>('none');
const contentsRef = useRef<HTMLInputElement>(null);

useLayoutEffect(() => {
    if (contentsRef.current) {
        const contentsHeight = contentsRef.current.getBoundingClientRect().height;
    if (contentsHeight > 96) {
        setIsExpand(4);
        }
    }
}, []);

return(
    ...
    <ContentsWrapper maxLine={isExpand}>
        <Typography ref={contentsRef}>
        {body.map((content, index) => {
            if (content === '') ? <br key={index} /> : [content, <br key={index}/>];
        })}
        </Typography>
        </ContentsWrapper>
        {isExpand !== 'none' && (
            <CommunityPostTypographyButton onClick={() => setIsExpand('none')}>
                더보기
            </CommunityPostTypographyButton>
        )}
    </ContentsWrapper>
    ...
)

아직 약점이 너무 많은 코드인 것 같습니다.
더 좋은 방법이 떠오르게 되면 바꿔서 적용 시켜봐야겠습니다. :)

> Comments <

Redux를 왜 쓰는지 알게 해준 곳입니다.

댓글 부분이 공통으로 들어가 있어 가져다가 사용을 하게 되었으나 만드신 분(Padd)이 댓글 관련 내용을 Redux로 제작을 하였습니다.
Padd의 댓글부분은 한 페이지에서만 보여주는 것 이였고 저는 여러개의 포스트 각각에 댓글을 가지고 있는 형태로 Padd와 같이 공통된 전역관리(Redux)를 하면 안되었습니다.

그래도 비슷하게 Key Value 값을 사용하여 제작을 하였지만 생각을 해본 결과... 엄청 많은 데이터가 들어가면 Redux가 감당할 수 있나? 더 복잡해질 것 같다 라는 생각에 전역관리(Redux)대신 지역관리(Component내에서 State관리)로 변경하여 문제를 해결하였습니다.

전역으로 사용해서 불편한 점을 느껴 Redux를 왜 쓰는지 알게되는 좋은 경험이었습니다. :)

> 낙관적 업데이트 <

개발을 진행하면서 사용자 편의성을 위해 무조건 빠르게 작동하는 것을 보여주는 것이 좋다고 생각하여 낙관적 업데이트를 좋아요, 댓글등 다 넣었습니다.

그런데...
중간 프로젝트 멘토링때 낙관적 업데이트가 그렇게 좋은 것은 아니다 라는 말을 들었습니다.

그래서 그때는 조금 의아 했는데 Api 연결을 하면서 댓글 부분에서 빠름보다 정확성이 더 필요해 보인다 라는 생각과 함께 멘토님의 말씀이 떠올랐습니다.

그래서 다음에는 정확성과 빠름이 필요한 곳을 구분하여 낙관적 업데이트를 사용하는 곳을 잘 나눠야 할 것 같습니다. :)

> 무한 스크롤 <

무한 스크롤이 될 때가 있고 안될때가 있었습니다.
IntersectionObserver()
forwardRef()를 통해 각 Component에 연결하여 값을 가져왔는데 잘 되지 않았습니다.

그래서 해당 Component를 감싸는 곳에 useRef()를 연결하여 되고 안되고의 문제는 해결 했하였고 Slow Network에서Debounce처리가 되어 있지 않아 엄청 많은 값들이 생기는 문제도 useEffect(), IIFE를 이용하여 문제를 해결하였습니다.

 useEffect(() => {
    (async () => {
      try {
        setLoading(true);
        const res = await getCommunityDataApi(5);
        dispatch(setPost(res));
      } catch (e) {
        console.error(e);
        setError(true);
      } finally {
        setLoading(false);
      }
    })();
  }, []);

useEffect(() => {
  if (lastPostId === 0) return;
      (async () => {
        if (!hasNext) return;
    	  try {
    	    setLoading(true);
			const res = await getCommunityDataApi(5, lastPostId);
			dispatch(addPost(res));
		  } catch (e) {
			console.error(e);
		  } finally {
			setLoading(false);
		  }
	  })();
}, [lastPostId]);

이 때 팀원의 도움이 정말 커서 팀원의 소중함과 Debounce처리를 꼭 해야겠다는 생각을 가지게 되었습니다.

😜 마치며

이번 프로젝트에서 팀을 정말 잘 만나서 팀 역할 분배도 잘되었고 문제가 있을 때 해결도 잘되어 정말 기뻤고 계속 생각이 날 것 같고 아직 고칠 것이 많은 프로젝트니 계속 지켜봐야겠습니다. :)
추가로 데브 코스를 하면서 많은 좋은 사람들을 만나고 경험을 하여 한층 성장을 하였고 우수 TIL?도 받고 게임대회 1위도 하고 최종 프로젝트 1위도 하여 아주 만족스러운 결과를 얻었지만 마무리라는 것이 정말 아쉽다는 생각이 들었습니다. 그러나 계속적으로 소통을 하며 지낼 것이라 다음이 더 기대 됩니다.

이젠 메니저님 말씀처럼 교육이라는 안정감에서 벗어나 사회랑 부딪쳐보며 깨지고 부셔지며 다시 일어나서
사회, 회사에 도움이 되는 사람이 되고 싶습니다. :)

긴 글 읽어주셔서 감사합니다.

반응형

'활동 > Dev Course 회고' 카테고리의 다른 글

토론 커뮤니티 Web 회고(w. React, Team Project)  (0) 2022.06.25
Code Review 회고(Vue)  (0) 2022.05.23
Code Review 회고(1~7)  (0) 2022.05.23
영화 검색 회고 (w. Vue)  (0) 2022.05.19
Airbnb 회고(SCSS)  (0) 2022.05.05
공지사항
최근에 올라온 글