Next.js 코드 가독성..

Question

안녕하세요 프론트앤드 1년차에 다가가고 있는 신입 개발자입니다.
현재 Next14를 사용하고 있으며 코드의 가독성, 효율성을 많이 고려하면서 코드를 짜려고하는데
너무 고민이 되네요
저보다 앞서서 달려가고 있는 개발자 선배님의 생각을 듣고싶습니다 ㅠㅠ...

2가지가 궁금합니다.
먼저 첫번째 이미지처럼 Version에 관련된 파일을 저렇게 분리했을 때

저는 Version의 최상위 Layout.tsx에서 모든 것을 선언하기가.. 너무 오히려 가독성이 안좋다고 생각을 하고 있습니다
즉, 변수나 함수를 모두 최상위 Layout.tsx에서 선언 및 정의를 해두고 props로 내려주는게 이상하다고 생각을 합니다.

변수, 함수, useEffect 모두 직접 해당 변수나 함수를 컨트롤하는 부분에서 선언 및 가공을 하는게 맞다고 생각을 합니다.

최상위 Layout.tsx가 너무 무거우면 오히려 나는 VersionDataTable에 관련된 변수나 함수만 보려고 하였으나 최상위 Layout.tsx를 보고 아 이게 VersionDataTable에 필요하구나 뭐가 필요없구나, useEffect의 의존성 배열까지 고려하는것이 불필요하다고 생각을 하고 있습니다..

근데 같이 프론트 앤드 개발하시는 분께서는 단기적으로 절대 코드가 변하지 않는다고 생각하면 그 말씀이 맞는데 그건 아니잖아요? 우리는 계속 유지보수를 할거고 그러면 결과적으로 A에서만 사용하던 변수나 함수들을 A,B,C에서 같이 사용할 수 있게 변경하게 되면 그때 변경하면 유지보수 측면에서 너무 안좋습니다.
최상위에 모두 선언이나 정의를 해두고 props로 내려주는게 맞다
이런 형식으로 코드를 작성하면 몇개월 뒤에 코드를 수정할 때 A가서 수정했다가 C가서 수정했다가 D가서 수정하실 거에요? 바로 알아보실 수 있겠어요?
라고 말씀을 하시더라구요..

물론 몇개월 뒤에 코드를 보거나 하면 제가 작성한 코드인데도 저는 헷갈리는 경우가 많습니다.

그러나 최상위에 모두 선언 및 정의해둬도 마찬가지 아닌가..?
유지보수 측면에서 뭐가 안좋은거지..? 라고 생각되게 됩니다.. 선배님의 말씀을 따라가고는 싶은데 이해가 안돼서요
제가 아직 기본기가 많이 부족한 상황이라 이 상황에서 말씀드리면 이론부터 말하며 설득시키기가 부족하다고 생각하기 때문에 말씀드리면 오히려 저는 이렇게 생각해요 틀렸는데요? 라고 말하는 것 같아 말다툼이 될 것 같습니다.

2. 밑 사진을 보면 modalTemplate라는 폴더, ConfirmTemplate이라는 폴더가 존재하는데요 이것에 대해서 저는 사용하는 용도에 따라서 Create면 Create
Create와 Update를 동시에 할 수 있는거면 BundleCreateAndUpdate
이런 형식으로 각각의 파일을 생성을 하고

문법상 공유되는 부분은 중복이 되어서 실제로 보여주는 부분을 영역으로 나눠서 BasicOptions, SelectList, VersionDetail, VersionOptions로 나누고 
각각의 파일에서 사용하는 부분만 불러와서 쓰는 형식으로 코드를 작성했습니다.

그러나 이렇게 용도에 따라 구분하지 않고 최상위 Layout.tsx파일 하나만 만들고 ModalType이라는 props를 받아서 ModalType이 create, update, create&update, delete ... 등 
JSX에서 삼항 연산자를 써서 처리를 할수도 있습니다.

저는 ModalType으로 처음에 구분하다보니 나는 create 속성일 때 어떤 형식으로 되는지 코드로 보고싶은데.. 그러면 너무 뜯어서 봐야하더라구요

그래서 용도에 맞게 파일을 만들고 거기서 form을 불러오기만해서 중복 코드를 줄이는 방식을 택했습니다.. (더 나은 코드라고 생각했습니다.)

그랬지만 선배님께서 ModalType으로 나누는게 더 좋아요 저렇게 지으면 가독성이 너무 떨어지고 파일의 이름이 너무 길어지잖아요 이상하지 않나요? 라고 말씀을 하시더라구요...
물론 가독성은 사람마다 다른거 알고있습니다.
그러나 ModalType으로 나누기 시작하면 한도 끝도없이 나누고 ModalType이 delete일 때만 사용하는 함수, create일 때만 사용하는 함수 등 필요없는 함수도 너무 많아져서

용도에 맞게 파일을 구분하고 거기서 중복 코드만 최대한 줄이자! 라고 생각하여 코드를 작성했는데

이 내용도 말씀드려 봤지만 가독성 이라는 이유 하나만으로 너무 안좋다고 합니다..
진짜 안좋은건가요..?

Next 도 그렇고 프론트 앤드 너무 어렵습니다..

이상래 · Answer

안녕하세요. 해당질문에 대한 개인적인 생각을 적어봅니다.

1. Container/Presentational Pattern
변수나 함수를 모두 최상위 Layout.tsx에서 선언 및 정의를 해두고 props로 내려주는게 이상하다고 생각을 합니다. 라고 말씀하셨는데, 이 부분에서 코드를 처음 코딩 하신분은 그래도 꽤 고민을 하시고 작성한 걸로 보입니다. 작성자분이 아직 생각을 못해봤을 수도 있는데, 해당 코드 개발 패턴은 container presenter pattern 입니다.

Container Components = 제일 상위에 변수, 함수, 비즈니스 로직 구현
Presentational Components: 데이터가 어떻게 사용자에게 보여질 지에 대해서만 다루는 컴포넌트.

이렇게 함으로써, React에서 관심사의 분리(SoC) 를 할 수 있습니다.
지금도 많이 사용하는 방식이지만, 말씀하셨던 것 처럼 요즘은 React Hooks로 대체 가능하다. React 에 Hooks가 추가되면서 Container 컴포넌트 없이도 stateless 컴포넌트를 쉽게 만들 수 있게 되었습니다.

그렇지만 아직까지도 각광 받는 이유는 바로 TDD를 쉽게 할 수 있습니다.
관련해서 학습을 해보시면 좋을 것 같아요.

2. 해당 부분에 대해서는 코드를 자세히 봐야 알겠지만, 보통 mode or type(상태)으로 말씀하셨던 것과 같이 하나의 Confirm 컴포넌트에서 상태에 따라 작업을 할 수 있게 해야 합니다. 예를들어 기획으로 인한 공통적인 추가 작업이 발생했을 때, 4~5개 의 컴포넌트를 공통적으로 고쳐야 하는 이슈가 생기고 이로인한 누락도 분명 발생할 것이기 때문에 유지보수 면에서 상당히 안좋다고 생각합니다.

결론적으로, 정답이 하나만 있는 것은 아닙니다. 어느 쪽이 더 맞는지는 프로젝트의 규모, 팀의 코드 스타일, 유지보수성 등을 고려해서 결정해야 합니다. 때로는 팀 내에서 코드 스타일을 통일하는 것도 중요한데, 이럴 때는 팀의 의견을 존중하면서도 본인의 의견을 설득력 있게 전달하는 것도 좋습니다.

상현 · Answer

글쓴이 분의 인사이트가 책임 소채 원칙에 강하게 묶여 있어서 다른 생각을 해보는 데에 제약을 주는 것 같네요.

어떤 컴포넌트를 작성한다 할 때 성격에 맞지 않는 이질적이거나 상관없는 코드가 그 자리에 있는 것을 꺼려하는 모습이나, 기능에 맞춰 매칭하는 컴포넌트를 만든 뒤에 거기에 있는 중복을 꺼내 정리하고 참조를 통해 해결하는 모습 등이 그러한데요. clean code 작성하기라는 트렌드에도 영향을 받은 듯 보입니다.

물론 코드 덩어리를 쪼개어 그 역할을 잘 분류하는 것은 좋은 습관입니다. 다만 모든 글쓰기가 그러하듯이 목적에 알맞는 방식인지, 알맞는 형태인지는 고려를 해보아야겠죠.

글쓴이 분의 글쓰기 방식은 내용은 명료하지만 주제는 명료하지 않을 수 있습니다. 대부분의 코드가 격리되거나 어디에 참조될 것을 염두하고 만들기 때문에 실제로는 재사용하는 범위가 좁거나 저변이 얕아질 수 있습니다. 달리 말하면 범용성이 떨어지는 것이겠죠. 이러면 코드는 캡처 이미지와 같이 폴더 트리의 하부에 몰리고, 상부는 그 두께가 얕아집니다. 맡은 것들을 하부에서 맡으면 전용하기는 쉽지만 그만큼 수정하기는 어려워질테죠.

프로젝트라는 책에 인물(1)보다는 고유한 이름을 가진 매튜, 프랑소와같은 캐릭터가 굉장히 많다면 그 책을 읽는 독자의 입장에서 기억해야 할 인물의 중요도를 구분하기 쉬울까요?

프로젝트를 경험할수록 대부분의 개발자들은 명료한 아키텍쳐를 선호하는 경향을 가집니다. 문제가 터졌을 때 그 문제의 범위를 격리하기에 좋고, 참조의 경로가 명확하고, 테스트하기 편리한 방식을 찾아갑니다. 그런 것들이 곧 패턴으로 만들어지고 유행하죠. 아예 처음부터 패턴을 설계하기도 하고요.

Layout에 코드가 몰려있는 것은 사수 분이 그러한 아키텍쳐를 시도한 모습이고, 그걸로 이전의 여러 문제를 제어할 수 있었거나 있을 거라는 견해에서 만들 결과물일 겁니다.

시비나 좋고 나쁨을 떠나 상대방의 글에도 이유가 있을 거라는 생각으로 접근해보시고, 그것을 구조적으로 이해해보려 하는 시도가 글쓴이 분의 성장에 도움이 되리라 생각해봅니다.