[회고] - 2023년 3월 회고

in 회고 on 회고, 3월


3월 회고

2월에는 회고를 못했다. 그래서 2~3월것 까지 회고를 해보자.

신규 팀원

2월 20일부터는 신규 팀원이 생겼다.

내 고등학교 후배였는데 고등학교 동아리를 통해서 알게된 친구였다.

대학교 졸업시즌이 되어서 조언을 얻고자 나에게 연락을 했었는데 마침 우리 팀에서 신규 개발팀원을 뽑으려고 진지하게 고민하던 시기여서 서로 대화가 잘 되어서 면접까지 보게 되었다.

면접에서 다른 팀원들도 다 좋게봐주셨고, 그렇게 2월 20일부터 정식 출근을 하게 되었다.

이제 패러다임시프트에서도 내 아래 팀원이 생기기 시작했고, 이제 팀적인 부분도 진지하게 고민하면서 업무를 해나가야 겠다.

Try : 창민이를 성장시키기 위해서는 내가 어떻게 해야할지 고민해보자. 단순히 어떤 업무를 맡기기 보다 그 사람을 성장 시키기 위한 관점으로 테스크를 줘보자.

그리고 앱이 v2를 기획을 거의 한달가까이 진행했고, 2주안에 개발을 끝내야 하는 상황이였다. 이번에는 그래도 코드와 폴더 구조를 어느정도 정하고 진행하였고, (VAC 패턴 등) 창민이와 나눠서 개발 할 수 있어서 처음 앱을 1주안에 만들때보다는 훨씬 여유 있었다.

VAC패턴을 적용한다고 했지만 여전히 개발속도 때문에 어느정도 무시하면서 간 부분도 많았고, 코드리뷰도 할 시간이 없었기 때문에 서로가 이해한 구조가 조금씩 달랐다. 이 부분은 앞으로 리팩토링을 조금씩 해나가기로 했다.

VAC 패턴 회고

그리고 VAC 패턴도 어떻게 적용하면 좋을지 고민하게 되었다. 아직 우리 정도의 규모에서 아토믹 패턴을 적용하기에는 이르다고 생각이 들었고, View와 로직을 구분하기 위해서 Container를 나눠서 개발하였다.

그런데 여기서 코드리뷰를 못하고 달리는 상황에서 서로의 구조적 차이들이 발생하기 시작했다.

그래서 팀원과 함께 논의후 우리가 어떤 원칙을 가지고 구조를 잡을지 논의해보았다.

먼저, 리팩토링을 왜 하는지를 고민해보았다.

당연히 리팩토링 및 코드리뷰를 하는 이유는 보다 좋은 코드를 만들기 위함이다.

그럼 좋은 코드는 무엇인가?

chatGPT가 말한 좋은 코드는 다음과 같다.

  • 가독성: 코드가 쉽게 읽히고 이해할 수 있어야 합니다. 변수명, 함수명, 주석 등을 명확하고 간결하게 작성하여 코드를 이해하기 쉽게 만들어야 합니다.
  • 유지보수성: 코드가 변경되거나 수정되어야 할 때, 쉽게 수정할 수 있어야 합니다. 코드가 잘 구조화되어 있고, 중복 코드를 최소화하고, 함수와 모듈 등이 잘 분리되어 있으면 유지보수성이 높아집니다.
  • 효율성: 코드가 빠르고 메모리를 효율적으로 사용해야 합니다. 불필요한 반복문이나 재귀함수를 피하고, 적절한 자료구조를 선택하여 효율적인 코드를 작성해야 합니다.
  • 안정성: 코드는 예상치 못한 에러나 버그를 최소화해야 합니다. 예외 처리를 적절하게 해주고, 디버깅이 쉽도록 로그를 작성하는 등의 방법으로 코드의 안정성을 높일 수 있습니다.
  • 일관성: 코드는 일관된 스타일과 패턴을 따라야 합니다. 코드 포맷팅, 들여쓰기 등의 스타일을 통일하고, 프로젝트 전반적으로 일관성 있는 스타일을 유지하는 것이 좋습니다.
  • 확장성: 코드는 변화하는 요구사항에 대응할 수 있도록 작성되어야 합니다. 추상화와 인터페이스를 이용하여 코드의 유연성과 확장성을 높이는 것이 좋습니다.
  • 테스트 용이성: 코드는 테스트하기 쉽게 작성되어야 합니다. 모듈화와 의존성 주입 등의 기법을 사용하여 테스트 용이성을 높일 수 있습니다.

일단 위의 내용에서 나는

  1. 가독성
  2. 유지보수성
  3. 일관성

위 3개에 집중하고 싶었다.

유지보수를 위해서 코드를 개선한다면, 추후에 새로운 팀원이 해당 코드에 신규기능 혹은 수정사항이 발생했을때 (심지어 몇달 뒤에 코드를 다 까먹은 내가 될 수도 있다) 해당 코드에서 수정해야 하는 포인트를 빠르게 찾아서 해당 부분을 수정할 수 있어야 한다. 그리고 해당 부분의 Side Effect 적인 부분도 고려되어있어야 한다.

그러기 위해서는 Side Effect는 적게, 해당 비즈니스 로직은 적절히 있어야할 위치에 있어야 한다고 생각한다.

그래서 정한 원칙은 다음과 같다.

  1. 해당 페이지의 핵심 로직은 가장 상위에 선언한다. (해당 페이지에 들어가면 바로 볼 수 있도록)
  2. 그외의 View관련된 로직은 해당 View의 상위 Container에서 관리한다.
    • 필요하다면 상태만 상위로 끌어올리자. (ex, 2개의 View가 같은 상태를 사용해야하는 상황)
  3. 파일이름에 Suffix는 꼭 붙이자. View, Container, Modal 등

Version 2

앱이 대대적으로 개편 되었고, 사실상 앱을 거의 새로 만들었다. (핵심 비즈니스 로직은 어느정도는 그대로 쓰긴 했지만 UI가 거의 다 바뀌었다)

transform 과련된 css를 많이 썻다. (카드가 이동한다던지… 등등)

이번에도 타이트하게 달리다보니 저번보다는 그래도 코드를 신경썼지만 아직 부족한 부분이 많다. 추후에 리팩토링을 해나가기로 했다.

개발하면서 알게 된 사항은 iOS14이하는 flex-gap 속성이 동작하지 않는다… 당연히 될 줄 알았는데…

그리고 이제 DB에 대한 이슈가 있어서 슬슬 Bubble.io에서 db migration을 고민할 시기가 다가오고 있다.

다음 한달 동안은 중간 redis 캐시 서버를 두는 등으로 조금이나마 성능을 개선해보고자 한다.

version2회고

  • mixpanel event가 자주 누락되는 사건이 있었다. 급해도 항상 코드는 리뷰를 통해서 서로 더블 체크하면서 가자.
  • 핵심 로직에 대해서는 테스트 코드에 대한 고민이 생기기 시작했다. 아직 프론트엔드에서 테스트 코드를 어떻게 짜야할지 잘 모르겠다… (공부를 안했다가 더 정확할 지도) 그런데 이제 핵심 비즈니스 로직들은 더욱 더 테스트가 필요하겠다는 생각이 든다. (내가 이제 백엔드도 같이 봐야한다면 더욱 더)
  • sentry등을 더욱 잘 활용하자. 이슈가 발생한 상황을 빠르게 발견하고 해당 부분을 빠르게 수정하도록 하자.

마무리

이번달은 version 2 만든다고 정신 없는 한달을 보냈다. 이제 다음달 부터는 레퍼럴 이벤트 관련한 변경사항 말고는 기능적으로 큰 피쳐는 그렇게 많지 않을 것 같다. (커뮤니티 개선 정도?) 그외에는 조금 더 앱의 완성도 측면, 에러대응 적인 측면을 고민해봐야겠다.

그리고 이제 QA 프로세스나 Test코드등을 통해 조금 더 Production 코드는 검증된 상태에서 배포해야겠다. (mixpanel 누락 등도 어떻게 하면 체크할 수 있을지 고민해보자)

Keep :

  • 결국 개발 또한 비즈니스를 위한 도구이다. 비즈니스 상황을 고려해서 포기해야할 부분은 포기하고 가자. (예를들어 이벤트 페이지는 코드 리뷰 필요없다 빨리 만들어서 빨리 뿌리자)

Problem

  • 너무 속도에 치중하다가 코드가 개판이 된 부분이 좀 있다.
  • 배포 프로세스가 아직 체계가 안잡혀있다.

Try

  • 배포는 신중히 해야하니 그런 프로세스를 고민해보자.
  • 바쁘더라도 코드 리뷰를 하자.
  • 폴더 구조를 더욱 명확히 정리해보자.
  • Redis등으로 백엔드 단에서도 성능적인 부분을 고민하자.
  • Sentry등 에러 대응을 잘 준비하자.

공부 하고 있는 것

  • 이팩티브 타입스크립트 (짱짱)

공부 해야 할 것

  • Sentry
  • React Test
  • Redis