아, 고전적인 개발자 논쟁: **"더 적은 줄에 더 적은 파일" vs "더 적은 줄에 더 많은 파일". 마치 피자 토핑을 선택하는 것과 같습니다. 모두가 자신만의 선호도를 갖고 있으며 어느 누구도 완전히 만족할 수는 없습니다.
풀 리퀘스트(PR)용 코드를 구성할 때 일부는 한 곳에 보관하는 단순성을 선호하는 반면, 다른 일부는 코드를 더 작고 집중된 파일로 나누는 것을 선호합니다.
궁극적으로는 귀하만의 문제가 아닙니다. 나중에 지저분한 코드베이스를 풀지 않도록 귀하와 귀하의 팀이 미래를 구하는 것입니다.
실제 시나리오를 살펴보겠습니다. 개발자가 대시보드 페이지에 위젯 목록을 렌더링하는 임무를 맡고 있다고 상상해 보십시오. 초기 구현은 다음과 같습니다.
// Dashboard.js export default function Dashboard() { const widgets = getWidgets(); // Handles widget deletion const handleDelete = (id) => {}; // Handles widget title update const handleUpdate = (id, newTitle) => {}; return ( <div> <h1>Dashboard</h1> <div className="widget-container"> {widgets.map((widget) => ( <div className="widget"> <h2>{widget.title}</h2> <p>{widget.description}</p> <span onClick={handleDelete}>?️</span> <span onClick={handleUpdate}>✎</span> </div> ))} </div> </div> ); }
검토 중에 누군가 개별 위젯을 자체 구성 요소로 렌더링하는 로직을 분리할 것을 제안했습니다. 개발자는 다음과 같이 코드를 리팩터링합니다.
// Dashboard.js export default function Dashboard() { const widgets = getWidgets(); // Handles widget deletion const handleDelete = (id) => {}; // Handles widget title update const handleUpdate = (id, newTitle) => {}; return ( <div> <h1>Dashboard</h1> <div className="widget-container"> {widgets.map((widget) => ( <Widget key={widget.id} widget={widget} onDelete={handleDelete} onUpdate={handleUpdate} /> ))} </div> </div> ); } // Widget component for individual widget function Widget({ widget, onDelete, onUpdate }) { return ( <div className="widget"> <h2>{widget.title}</h2> <p>{widget.description}</p> <button onClick={() => onDelete(widget.id)}>?️</button> <button onClick={() => onUpdate(widget.id, "New Title")}>✏️</button> </div> ); } // Can be even further moved to a separate file // Widget.js export default function Widget({ widget, onDelete, onUpdate }) { return ( <div className="widget"> <h2>{widget.title}</h2> <p>{widget.description}</p> <button onClick={() => onDelete(widget.id)}>?️</button> <button onClick={() => onUpdate(widget.id, "New Title")}>✏️</button> </div> ); }
특히 분석 처리와 같은 추가 로직이 위젯에 밀접하게 연결되어 소품 및 컨텍스트 전환이 증가하는 경우 초기 구현이 더 간단하고 간단해 보이지 않았나요? ? 이는 중요한 질문을 제기합니다. 대시보드 구성 요소는 어떤 접근 방식을 취해야 합니까? 인라인 구현을 유지해야 할까요, 리팩터링된 구조를 채택해야 할까요, 아니면 하이브리드 접근 방식을 선택해야 할까요? ?
이 DashBoard 예에서는 프로젝트 규모와 구성 요소의 의도된 역할에 따라 선택이 달라집니다. 이는 위젯이 재사용되지 않는 작은 예이므로 단일 파일이 잘 작동합니다.
// Dashboard.js export default function Dashboard() { const widgets = getWidgets(); // Handles widget deletion const handleDelete = (id) => {}; // Handles widget title update const handleUpdate = (id, newTitle) => {}; return ( <div> <h1>Dashboard</h1> <div className="widget-container"> {widgets.map((widget) => ( <div className="widget"> <h2>{widget.title}</h2> <p>{widget.description}</p> <span onClick={handleDelete}>?️</span> <span onClick={handleUpdate}>✎</span> </div> ))} </div> </div> ); }
규모가 크거나 성장하는 프로젝트의 경우 위젯을 분리하는 것이 유연성과 유지 관리 측면에서 유리할 것입니다
'단일 파일에 더 많은 줄'과 '더 적은 줄에 더 많은 파일'의 균형을 맞추는 것은 프로젝트 범위, 팀 규모, 성장 궤적에 따라 다릅니다. 결정할 때 다음 사항을 고려하십시오.
누군가 PR 검토 중에 구성 요소를 별도의 파일로 옮기라고 제안하는 경우 이점이 이러한 고려 사항과 일치하는지 다시 확인하세요.
위 내용은 더 적은 수의 파일, 더 많은 라인 vs. 더 많은 파일, 더 적은 코드 라인의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!