1차 리팩토링에 관해서

1차 리팩토링을 하게 된 이유.

• 공개소프트웨어 개발자 대회 공모전 1차가 붙었기에 무지성 개발을 좀더 탈피하고자,, 시간이 들더라도 리팩토링을 해야함.
• 개발 기간때, 코드 리뷰시 너무 대충했던 것 같음 (로직만 확인하고, 정확하게 동작하는지, 이 코드가 여기에 있어야 하는지, 등을 검사히진 않았음.. 난그럼)
• 덕분에 PR갯수가 많이 쌓임

어떤것을 해야 하는가?

• 현재 리팩토링은 아키텍쳐 구조를 수정하거나 로직을 변경하는 사항이 아님.
• 그저 방학때 불성실했던 코드 리뷰때문에 발생한 처음에 설계했던 컨트롤러/서비스/래포지토리 패턴이 맞는가? 에 대해서
  • 예를들어 validation - controller - service 가 각각 네이밍(feature)에 맞게 설게되었는지,
• 로직을 최적화 할 수 있는가? (불필요한 예외처리?)
• 불필요한 코드(혹은 안쓰이는 코드) 가 있는가?
  • eslint를 설정할때 no-unused-vars 옵션은 꺼뒀음. 이거 서로 코드 리팩토링 이후 다시 부활 예정. 리팩토링때 제대로 검사하자.(리팩토링하면서 on 해도 됨)
• repository 코드 최적화
• ..etc

누가 어떤걸 리팩토링 해야 하는가?

• 본인이 개발한 feature,
• 성웅 : Oauth, Channel, Post(현재는 채널 안), Search
• 인혁 : Auth, Profile, Chatting, Image, Room
• 애매한것은 즉시 카톡 바람

리팩토링 과정

• 이제부터 모든 branch를 issue 단위로 남기자!
• 리팩토링 또한 branch를 새로 파서 만들어야 하기 때문에 issue를 만들고 branch를 feat/issue-[이슈번호] 이렇게 새로 만들어서 합시다.
• 리팩토링 하기전에 issue에 어떤걸 리팩토링 할지 자세하게 적기는 힘들 것 같음. 그래서 issue를 만들때 그냥 간단하게 적거나 정 안되면 지금 이 문서 링크 달고라고 이슈 생성.
• 리팩토링 하고 나서 Pull Request에 남길때는 어떻게 리팩토링을 했는지 자세하게 서술,
  • 위에적은 feature 별로 자세하게 적어도 되고, controller, service, validation, repository 단위로 적어도 됨,
• Pull Request 이후 issue 삭제. Closes #이슈넘버

기간 및 제약사항

• 1차 리팩토링 기간. (9월 ~31)
• 개발자회의때 추가 개발할 사항이 있더라도, 리팩토링 이후 추가 개발하도록 할 것.