하지 마세요: mapStateToProps에서 새 배열이나 새 객체를 반환합니다. 객체를 반환해야 하는 경우 나중에 변경되지 않는지 확인하세요. 이로 인해 이 개체가 조금만 변경되면 전체 구성 요소와 하위 트리가 다시 렌더링될 수 있습니다. 

Do: mapstateToProps는 상태에서 직접 가져온 기본 요소와 배열만 반환해야 합니다(mapStateToProps에서 새 배열을 만들지 마세요. 필요한 경우 인수 계산에서 결과 배열을 캐시하는 선택기를 만듭니다). 나중에 반복될 배열에는 렌더링할 항목의 문자열 ID가 포함되어야 합니다. 목록 항목은 props에서 전달된 id를 사용하여 전역 상태에 대한 정보를 찾는 역할을 담당합니다.

해야 할 일: 나만의 사용자 정의 후크를 만들 때 반환할 배열도 메모되었는지 확인하세요. 조기 최적화는 승인되지 않지만 가능한 가장 최적의 방식으로 무언가를 구축하는 것은 어떨까요? 상당한 노력이 필요하지 않으며 코드를 작업하는 다른 엔지니어의 학습을 촉진합니다. 팀의 기술을 향상시키세요!

Do: 큰 개체를 만들 때 키를 알파벳 순서로 정렬합니다. 객체의 크기가 커질 가능성이 높으며 속성을 검색하는 데 매우 많은 시간이 소요될 수 있습니다. 특히 매장에서는 감속기를 알파벳순으로 주문했는지 확인하세요.

하지 마세요: 구축 중인 페이지/화면과 관련된 리듀서를 구축하세요. 다른 페이지/화면으로 어떻게 확장할 수 있는지 생각해 보세요. 귀하가 만들고 있는 페이지/화면의 향후 사용 가능성을 알아보려면 팀에 문의하세요.

해야 할 일: 맞춤형 API를 사용하여 외부 API와의 통신을 래핑해야 합니다. 향후에 서비스를 교체해야 하는 경우 이 맞춤형 API를 통해 교체할 수 있습니다. 예를 들어 Bugsnag를 생각해 보세요. 나중에 Sentry를 사용하려는 경우를 대비해 맞춤형 API로 아기를 감싸세요.

Do: 같은 메모에서. 백엔드뿐만 아니라 프런트엔드에서도 오류를 처리하는 방식을 표준화하세요. 앱의 모든 작업은 try/catch 블록에 래핑되어야 하며 catch 블록은 버그 보고 도구에 보고서를 보냅니다. 또한 앱은 오류 경계로 전체 앱을 래핑해야 합니다. 나는 올바른 패턴을 확립하는 적절한 방법이 있다고 믿습니다. 모든 오류를 잡아내고 의미 있는 정보를 보고할 수 있는 패턴입니다.

실행: Sonar와 같은 코드 품질을 강화하는 도구를 사용하면 누군가 if ... else 대신 if ... return을 사용하기로 결정했기 때문에 코드 검토 중에 많은 시간을 절약할 수 있습니다. . 개발자의 창의성을 떨어뜨리고 코드 품질에 대한 소나 표준을 따르도록 만드는 작은 세부 사항입니다. 이러한 세부 사항까지 철저하게 따르는 코드베이스는 첫날부터 쉽게 코딩할 수 있습니다.

결론

현재 제가 가지고 있는 의견은 이게 전부입니다. 패턴을 적용하는 코드베이스가 있으면 사람들은 코드베이스의 다른 곳에서 코드 조각을 가져와 붙여넣고 문구를 약간 변경할 수 있습니다. 짜잔, 가능한 모든 방법으로 생산 표준을 충족하는 기능이 있습니다. 의견이 있지만 적어도 글을 쓰는 시점에는 실제로 가장 효과적인 작업 방법이 있습니다. 다른 접근 방식이 나올 수도 있지만 작성하는 순간에 코드를 작성하는 가장 효율적인 방법은 코드를 작성하는 유일한 방법입니다. 마감 시간의 괴물을 만나기 전까지는 말처럼 쉽지 않습니다.