우리를 화나게 만드는 프론트엔드 기술을 피하는 방법

프런트엔드가 얼마나 혼란스럽고 압도적인지에 대해 많은 글이 쓰여지고 있습니다(개요는 JavaScript 프레임워크 - 2025년으로 향함 참조). 존재하는 공백을 메우고 더 건강한 생태계를 만들기 위해 무엇이 필요한지 논의합니다.

개발자의 현실

프런트엔드 개발자가 다양한 기술을 고려할 때 이해관계자(비즈니스 담당자 및 동료 개발자 모두)를 설득할 수 있는 방법이 필요하며, 이를 수행할 수 있는 유일한 방법은 사물을 구축하고 측정하여 이점을 입증하고 기대를 관리합니다. (동인은 완전히 새로운 것을 구축하거나, 이미 존재하는 것을 개선하거나, 변경이 필요하지 않으며 대안을 통해 얻을 수 있는 이점이 없다는 것을 증명해야 할 수도 있습니다. 회사가 이를 고려하도록 압력을 가하고 있습니다.)

예를 들어 더 많은 React 서버 구성요소 활용을 고려 중인 개발자가 있을 수 있습니다(RSC 자체에 초점이 맞춰져 있지 않으며 다른 프레임워크 또는 다른 기술일 수도 있습니다). 서버를 포함하도록 아키텍처를 조정하고, 새로운 프로그래밍 패턴을 채택하고, 이러한 새로운 라우터 및 지시문을 사용하여 파일 구성에 대해 생각하고, 모든 제약 조건에 대해 추론하고, 이 모든 것에 대해 사람들에게 교육하고, 내부 모범 사례 및 요구 사항에 맞춰 조정해야 합니다. 고객과 대화하고 SLA와 문서를 업데이트하세요. 이 모든 것은 비용이 많이 들고 위험하므로 가볍게 결정을 내리면 안 됩니다.

(다양한 기술을 비교하고 아키텍처 마이그레이션을 수행하는 이 힘들고 비용이 많이 드는 프로세스는 전 세계의 많은 팀이 겪고 있는 일입니다. 실패한 약속에 대해 얼마나 많은 블로그 게시물과 비디오가 있었는지 생각해 보십시오. 기술의 일부(Next.js가 필요하지 않습니다 – 가장 최근의 것 중 하나로 Next에서 React로 마이그레이션한 이유).

그러나 POC 구축을 시작하자마자 개발자는 많은 기술 제품이 "Trust us bro" 인수를 통해 광고된다는 사실을 깨닫게 됩니다.

프레임워크 주방에서 나오는 모든 새로운 기술은 상당히 플라스틱적인 데모를 통해 놀라운 개선에 대한 이야기를 들려줍니다. 그러나 현실은 훨씬 더 혼란스럽고 이점이 미미한 경우가 많지만 실험과 마이그레이션에는 비용이 매우 많이 듭니다. 문제는 모든 회사와 모든 팀이 바퀴를 재발명하고 특정 사례에 실제로 어느 정도 유용성이 있음을 증명할 수 있는 방법을 찾는 것입니다. 다양한 옵션을 총체적이고 철저하게 고려하고 테스트하려면 엄청난 양의 리소스와 사내 전문 지식이 필요합니다.

Trust Me Bro™ 주장에서 알 수 있듯이 Yet Another™ 기능을 The Now Best Thing Ever™로 내세우는 회사가 개발자에게 이를 구매하고 마이그레이션하려고 노력했지만 실제로 어려운 문제는 해결하기 어렵고 ROI도 없다는 사실을 발견했습니다. 시간이 지남에 따라 이러한 방식으로 너무 자주 화상을 입으면 분노, 탈진 및 향후 위험에 대한 전반적인 혐오감이 발생합니다.

이러한 멋진 신기술을 개발하는 회사(정말 멋질 수도 있습니다!)는 사람들이 분노를 느끼고 이러한 종류의 노력에 필요한 작업량과 검증 가능한 전달 방법이 접근하기 어렵다는 점을 고려하지 않는 것처럼 보일 수 있다는 사실에 놀랐습니다. 현실적인 기대는 무엇일지. 모든 것이 부정직해 보일 수 있습니다.

이러한 신기술을 구축하는 회사는 광고를 통해서뿐만 아니라 개발자에게 의사 결정을 안내하고 이점을 스스로 확인할 수 있는 도구를 제공함으로써 기술이 작동한다는 것을 증명할 책임이 있다는 사실을 깨달았습니다. .

도구

그럼 해당 도구는 실제로 어떤 모습일까요?

도구는 개발자가 관심을 갖고 있는(객관적으로 측정할 수 있는) 측정항목을 지속적으로 보고하고, 개발자가 절충안을 이해하는 데 도움이 되도록 개발자가 수행하는 변경 사항과 전체적으로 결합 및 상호 연관되어 있습니다.

• 번들 크기(페이지별 및 공유 번들에 대한 철저한 보고, 지연(상호작용 시) 및/또는 자동(서비스 작업자, 사전 로드 및 기타 준비)으로 로드되는 추가 번들에 대한 통찰력)
• 네트워크 측정항목(더 많은 직렬화를 통해 클라이언트의 실제 절감액이 무엇인지, 서버와 클라이언트 간의 통신에 어떤 영향을 미치는지 파악하는 것이 좋습니다)
• 타이밍 분할 및 성능(서버와 클라이언트 모두 포함, 예: 콘텐츠를 렌더링하는 데 걸리는 시간, 서버 대 클라이언트에 있는 콘텐츠의 양, 네트워크 대기 시간 및 전송 등)
• 웹 바이탈(점진적으로 로드되고 렌더링되는 웹페이지의 여러 부분에 대해 더 세분화된 분할이 필요합니까? 더 이상 초기 로드에 대해서만 일회성 측정항목으로 충분합니까?)
• 전체 프로젝트 수준에서 이러한 다양한 측정 항목 모두 간의 추세(시간 경과) 및 상관 관계(팀이 상황 진행 방식을 추적하고 시간이 지남에 따라 성능이 저하되거나 극단적인 사례가 발생하는 것에 대해 불쾌하게 놀라는 것을 방지할 수 있도록 함) 일부 장소 및 일부 페이지에서만)

여기에 언급된 사항은 모든 팀이 관심을 갖는 몇 가지 사항과 동일하지만 이러한 종류의 통찰력을 얻기 위한 도구는 설정하기 어렵고 복잡해 보이며 때로는 검은색처럼 작동하는 프레임워크를 처리할 때 실제로 불가능합니다. 상자.

인센티브

이런 종류의 도구는 이러한 새로운 기술을 직접 개발하는 동일한 회사에서 반드시 제공할 필요는 없지만 다른 회사에서 구축할 수도 있습니다(이미 유사한 고려 사항에 대한 힌트가 있을 수 있음 ? Evan You - Vue, Vite, VoidZero 및 JavaScript 도구의 미래 또는 Evan이 말하는 내용을 잘못 해석할 수 있습니다. 하지만 저는 새로운 기술을 개발하는 회사가 자신의 이익을 검증할 수 있는 도구를 제공하는 회사여야 한다고 믿습니다. 왜냐하면 인센티브가 회사 측에 있기 때문입니다.

다양한 측정항목과 다양한 구현 간의 차이점을 투명하게 보고하는 도구를 구축함으로써 새로운 기술/프레임워크를 구축하는 회사는 먼저 진행 상황과 주장을 내부적으로 확인하고 절충점을 이해하고 최적화할 수 있습니다. 올바른 측정항목. 이를 통해 회사는 책임감 있고 정직하게 유지됩니다. 따라서 전체 개선 피드백 루프는 대중에게 공개되기 훨씬 전에 내부적으로 발생할 수 있습니다.

또한 동일한 도구를 대중에게 제공함으로써 회사는 허위 주장과 실망의 위험을 피할 수 있으며 대신 모든 사람이 자신의 프로젝트에서 스스로 간단하게 확인할 수 있는 기능을 제공할 수 있습니다. 그러면 더 많은 신뢰와 감사가 생길 것입니다.

기술을 구축하는 회사는 이를 위한 도구를 구축하는 데 가장 좋은 위치에 있습니다. API와 기능을 가장 잘 이해하고, 도구가 작동하도록 공개하는 데 필요한 정보의 양과 양을 가장 잘 이해합니다(이는 또 다른 방법입니다). 정직하고 공정한 회사를 유지하기 위해).

궁극적으로 회사가 해당 도구를 유료화하여 비즈니스 모델을 확장하려는 경우 그렇게 할 수 있습니다. (현재 유사한 접근 방식은 일반적으로 고객 회사와의 계약 및 직접 참여를 통해 나타나지만, 도구를 사용하면 모든 당사자에게 이익이 될 수 있는 전체 작업을 훨씬 더 자체적으로 수행할 수 있습니다.)

결론

우리는 최고의 단일 솔루션이 없고 점점 더 커지고 있는 프로젝트에 대한 아키텍처 마이그레이션이 저렴하지 않은 경쟁 기술 시대에 있습니다. 현명하게 결정하고 움직일 수 있으려면 결정, 변경 및 절충을 지속적으로 안내하고 평가하며 모든 작업이 완료된 후에만 보고하는 것이 아닌 보다 포괄적인 도구 및 보고가 필요합니다.

이러한 새로운 기술과 프레임워크를 구축하는 기업은 이러한 도구로부터 가장 많은 혜택을 누리고 이를 구축할 수 있는 가장 좋은 위치에 있습니다.

위 내용은 우리를 화나게 만드는 프론트엔드 기술을 피하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!