result 관련 페이지 타입 분리

[lhk3337]

변경된 것

일단 Result page 관련 타입을 분리하였는데 이런 방식으로 하는것이 맞는지 확인 부탁드립니다.

관련 스크린 샷

• 스키마 변경 여부

[Ho-s]

여기는 이름 뒤에 Props가 빠져있는 이유가 있을까요?

[Ho-s]

컴포넌트 props 아니고서는 얘기를 안 나눴던 것 같긴 합니다!

[lhk3337]

Answers가 props로 쓰이기도 하고 변수의 타입으로 사용되어 일단 선언하지 않았습니다.

[pkiop]

props가 아닌건 types로 빼자고 했었던 것 같습니다.
그냥 Answers라는 이름이 적절하진 않은 것 같은데 딱히 좋은게 생각안나니 이대로 가도 좋을 것 같아요

[pkiop]

파일이름 type.ts 로 하지말고 우선 index.ts 로 합시다
import 할 때 'types' 로 쓸 수 있게요.

[pkiop]

이거 props는 컴포넌트 안에 두기로 하지 않았었나요??

[lhk3337]

항목을 다시 확인 해보니 컴포넌트에 두는것이 맞네요 수정하겠습니다.

[Ho-s]

이런식으로 잡히는 것만 먼저 하는 것도 괜찮지만, 이렇게 되면 어떤 부분이 작업이 끝났는지 알기 힘들거 같아서요, 그냥 하나의 page나 organism을 잡고 그 안에 있는 모든 것에 대해서 저희가 얘기 나눈 것에서 맞는 부분은 전부 다 바꾸는 것이 어떨까요? 그럼 무엇을 더 작업해야하는지 알기 쉬울 것 같아서요

[lhk3337]

이런식으로 잡히는 것만 먼저 하는 것도 괜찮지만, 이렇게 되면 어떤 부분이 작업이 끝났는지 알기 힘들거 같아서요, 그냥 하나의 page나 organism을 잡고 그 안에 있는 모든 것에 대해서 저희가 얘기 나눈 것에서 맞는 부분은 전부 다 바꾸는 것이 어떨까요? 그럼 무엇을 더 작업해야하는지 알기 쉬울 것 같아서요

연관 부분이 많을경우 하나의 컴포넌트 뿐만 아니라 다른 컴포넌트의 수정해야 양이 많이 늘어 날꺼 같아요

[Ho-s]

이런식으로 잡히는 것만 먼저 하는 것도 괜찮지만, 이렇게 되면 어떤 부분이 작업이 끝났는지 알기 힘들거 같아서요, 그냥 하나의 page나 organism을 잡고 그 안에 있는 모든 것에 대해서 저희가 얘기 나눈 것에서 맞는 부분은 전부 다 바꾸는 것이 어떨까요? 그럼 무엇을 더 작업해야하는지 알기 쉬울 것 같아서요

연관 부분이 많을경우 하나의 컴포넌트 뿐만 아니라 다른 컴포넌트의 수정해야 양이 많이 늘어 날꺼 같아요

네 그렇긴 한데, 그것은 어쨋든, 해야 할 일들을 지워나가는 거니까 크게 상관 없을 것 같습니다.

저희가 한 페이지에서 신경 써야할 것이 15가지 정도의 룰을 정했잖아요? 그것을 한 명이 신경쓰면서 그 페이지를 완전히 마무리하면 다음에는 그 페이지를 볼 일이 없습니다.

하지만, 만약 15가지중에 3가지의 룰에 해당하는 것만을 수정했다고 치면 다음 사람은 이 페이지에서 어떤 부분이 마무리 되었고 어떤 부분이 마무리되지 않았는지까지를 신경써야하기 때문에 비효율적이라는 생각이 들어서요.

어떻게 생각하시나요?

[lhk3337]

이런식으로 잡히는 것만 먼저 하는 것도 괜찮지만, 이렇게 되면 어떤 부분이 작업이 끝났는지 알기 힘들거 같아서요, 그냥 하나의 page나 organism을 잡고 그 안에 있는 모든 것에 대해서 저희가 얘기 나눈 것에서 맞는 부분은 전부 다 바꾸는 것이 어떨까요? 그럼 무엇을 더 작업해야하는지 알기 쉬울 것 같아서요

연관 부분이 많을경우 하나의 컴포넌트 뿐만 아니라 다른 컴포넌트의 수정해야 양이 많이 늘어 날꺼 같아요

네 그렇긴 한데, 그것은 어쨋든, 해야 할 일들을 지워나가는 거니까 크게 상관 없을 것 같습니다.

저희가 한 페이지에서 신경 써야할 것이 15가지 정도의 룰을 정했잖아요? 그것을 한 명이 신경쓰면서 그 페이지를 완전히 마무리하면 다음에는 그 페이지를 볼 일이 없습니다.

하지만, 만약 15가지중에 3가지의 룰에 해당하는 것만을 수정했다고 치면 다음 사람은 이 페이지에서 어떤 부분이 마무리 되었고 어떤 부분이 마무리되지 않았는지까지를 신경써야하기 때문에 비효율적이라는 생각이 들어서요.

어떻게 생각하시나요?

저도 그렇게 생각을 하고 있는데, 한 페이지에서 수정하는 과정에서 다른 여러 페이지까지 관련된 부분이 있으면, 그 페이지도 그 법칙에 따라 다 수정해야 하기 때문에 작업 량이 많아 질 수도 있을 꺼 같습니다.

[pkiop]

refactoring/resultpage 라는 중간 브랜치를 만들어서 이 브랜치에 지금 홍규님 PR정도의 규모로 PR 보내도록 하고
병호님 말씀대로 refactoring/resultpage에 15가지 수정사항이 다 반영됐다고 판단하면 그 때 refactoring/resultpage -> develop 으로 PR 날리면 될 것 같습니다.

PR 규모는 딱 이정도가 좋은 것 같아요

[lhk3337]

refactoring/resultpage 라는 중간 브랜치를 만들어서 이 브랜치에 지금 홍규님 PR정도의 규모로 PR 보내도록 하고
병호님 말씀대로 refactoring/resultpage에 15가지 수정사항이 다 반영됐다고 판단하면 그 때 refactoring/resultpage -> develop 으로 PR 날리면 될 것 같습니다.

PR 규모는 딱 이정도가 좋은 것 같아요

리팩토링 작업을 처음 해봐서 기준점을 어디에 잡아야 할지 잘 몰랐는데, 명확하게 기준점 잡아주셔서 효율적으로 작업을 할 수 있을꺼 같습니다.

[Ho-s]

그럼 명확히 무엇을 했다 이러기에는 너무 복잡하니, 일단 어느정도 보이는 것만 진행하고 나중에 기능개발할 때에도 보완해가면 되겠네요