전제

다음은 여기에서 찾을 수 있는 Josh Collinsworth의 아름다운 기사에 대한 답변입니다.

저는 그가 자신의 기사에서 작성한 각 요약 인용문을 취합하고 각 인용문에 제 의견을 응답하는 방식으로 이 콘텐츠를 구성하기로 결정했습니다.

따라서 이 기사는 개인적인 의견을 나타내는 일련의 아이디어로 간주됩니다. 보고된 12개의 인용문 중 ✅ 8에 동의하고 ❌ 3에 동의하지 않으며 에 대해서는 의견이 없습니다. 1.

[TL;DR] 나는 일반적으로 저자의 의견과 관점에 동의합니다. 그러나 어떤 경우에는 기사로 인해 왜곡된 관점으로 인해 일부 진술에 동의하지 않는 경우도 있습니다. 내 생각에 편견에 대한 분석은 저자의 개발 세계에 대한 많은 편견을 야기했습니다.

프론트엔드 관행이 광범위하게 감소하고 있는 것 같습니다. 거의 모든 곳에서 그 중요성이 최소화되고 과제가 하찮아지는 것을 발견했습니다.

✅ 이 말에 전적으로 동의합니다.

프런트엔드는 너무 오랫동안 백엔드의 "동생"으로 여겨져 왔는데 이는 실수입니다. 프런트엔드는 최종 사용자가 보고 상호 작용하는 애플리케이션의 일부이므로 제품 성공의 기본입니다. 그 중요성은 과소평가할 수 없지만 이런 일은 너무 자주 발생하며 나 자신도 때때로 프론트엔드 개발자로서의 내 작업이 백엔드에서 수행한 작업보다 "열등"하다고 생각했습니다.

왜 이런 일이 발생하나요? 내 관점에서는 지난 10년 동안 프론트엔드 개발 세계가 모든 사람이 작업을 더 간단하고 더 쉽게 액세스할 수 있게 만든 프레임워크와 라이브러리에 의해 침범되었기 때문이라고 생각합니다. 이로 인해 과거에 발생한 많은 문제에 대응할 수 있게 되었고, 프론트엔드 개발이 "더 단순해졌습니다". 이로 인해 종종 "코드 원숭이"로 간주되는 프런트엔드 개발자의 역할이 평가절하되었습니다. 그러나 단순하다는 것이 쉽다는 의미는 아니며 프론트엔드 개발자는 복잡한 문제를 해결하고 중요한 결정을 내려야 하는 경우가 많습니다. 이는 프레임워크에 의해 이미 해결된 "간단한" 문제를 더 이상 해결하기를 기대하지 않고 오히려 오히려 복잡한 문제를 해결해야 하기 때문입니다. 새롭고 혁신적인 방식으로 사용자 경험을 풍부하게 합니다.

CSS가 기괴한 양자 상태에 존재하는 것과 같습니다. 어쨌든 사용하기에는 너무 복잡하지만 동시에 심각하게 받아들이기에는 너무 간단합니다.

✅ 여기에도 동의합니다.

CSS는 웹 개발 세계에서 가장 과소평가되고 평가절하된 언어 중 하나입니다. CSS는 강력하고 복잡한 언어로, 복잡하고 상세한 사용자 인터페이스를 만들 수 있습니다. 그러나 일반적인 코드 작성 방식, 특정 구문 및 작동 논리와의 거리로 인해 마스터하고 사용하기가 어려운 경우가 많습니다. CSS는 숙달하는 데 시간과 헌신이 필요한 언어이며, CSS-in-JS 운동에서 일어난 일은 커뮤니티가 존재하지 않았던 문제를 어떻게 해결하려고 했는지를 보여주는 분명한 예입니다. 이미 매우 복잡한 언어에 추상화를 추가하는 동시에 새로운 언어입니다.

여러 면에서 CSS는 사용자 경험에 다른 어떤 언어보다 더 큰 영향을 미치며, 이는 종종 성공에 직접적인 영향을 미칩니다. 그렇다면 왜 그 역할이 그토록 과소평가되는가?

✅ 동의합니다.

이전 인용문에 대한 답변에서 언급했듯이 CSS의 문제는 운영 논리와 특정 구문 때문이라고 생각합니다. 문제는 JavaScript에 비해 "보조" 언어로 간주되는 경우가 많지만 실제로는 그 자체로 규칙과 특성을 지닌 언어이고 프로그래밍에 버금가는 학습 시간이 필요하다는 것입니다. CSS는 강력하고 복잡한 언어이며 그 역할을 과소평가할 수 없습니다.

대부분 실제로 프런트엔드가 덜 중요하다거나 덜 현실적이다거나 그렇게 똑똑할 필요는 없다고 말하는 사람은 없습니다. 하지만 종종 암시되는 것 같습니다.

✅ 부분적으로 동의합니다.

솔직히 말해서 나는 이 주제가 저자가 말한 것보다 훨씬 더 명백하다고 생각합니다. 사실 저는 프론트엔드를 백엔드에 비해 "사소한" 일로 생각하고, 프론트엔드 개발자는 프로그래머가 아니라 [ 실제 작업인 백엔드를 수행하는 사람들을 &&&]지원합니다. 내 역할이 무엇인지 묻는다면 나는 항상 풀스택이라고 대답한다. 왜냐하면 나의 훈련과 성장에는 다양하고 다른 요소들이 있고, 두 측면 모두 나에게 중요하고 중요하기 때문이다.

저는 커뮤니티가 이러한 사고방식을 근절하기 위해 더 많은 노력을 기울여야 한다고 믿습니다. 프론트엔드 개발자는 모든 면에서 전문가이며, 그의 작업은 제품 성공의 기본입니다.

프론트엔드 개발자는 끊임없이 진화하는 도구의 지원을 받아 인지 부하를 크게 증가시키는 복잡한 문제를 해결하고 성공적인 제품의 보루인 사용자 경험에 직접적인 영향을 미치는 중요한 결정을 내려야 합니다.

우리의 결과물은 어느 정도 예술적이며, 예술적인 것들은 단순하고 재미있어 보인다는 이유만으로 비극적으로 평가 절하된 오랜 역사를 가지고 있습니다.

✅ 동의합니다.

역할과 책임에 대한 이해 부족은 우리 업계에서 근본적인 역할을 합니다. 프론트엔드 개발자는 종종 “예술가”, “창의적인” 사람으로 여겨지며 그의 작업은 백엔드 개발자처럼 “기술적”이지 않기 때문에 평가절하됩니다. 이는 두 가지 측면에서 실수입니다.

우선, 애플리케이션의 디자인을 결정하는 것은 프론트엔드 개발자가 아니라 디자이너(UX, UI, 원하는 대로 부르세요)인 경우가 많습니다. 프런트엔드 개발자는 디자인을 코드로 변환하고 이를 효율적이고 고성능 방식으로 수행해야 합니다. 이를 위해서는 단순히 코드를 작성하는 것 이상의 기술적 능력과 구체적인 지식이 필요합니다.

둘째, 위에서 이미 언급했듯이 프런트엔드 개발자의 책임은 단순히 코드를 작성하는 것 이상의 역할을 하는 경우가 많습니다. 백엔드 애플리케이션의 코드를 수정하면 자동 테스트에서 가능한 한 빨리 회귀를 알아차릴 가능성이 높습니다. 프런트엔드 애플리케이션의 코드를 수정하는 경우 회귀를 확인할 수 있는 유일한 방법은 애플리케이션을 수동으로 테스트하거나 최종 고객의 보고서를 기다리는 것입니다*. 이로 인해 프런트엔드 개발자의 작업은 생각보다 훨씬 더 복잡하고 까다로워집니다.

비즈니스 로직과 상태 관리의 양은 말할 것도 없고 둘 다 프런트엔드에 즉각적으로 쏟아져 역할이 점점 비즈니스와 통합되게 만듭니다.

*참고: 저는 엔드투엔드 테스트의 존재를 잘 알고 있지만, 그 구현은 기존 자동 테스트보다 훨씬 복잡하고 비용이 많이 듭니다. 또한 무작위 및 외부 조건으로 인해 신뢰성에 의문을 제기하는 경우가 많습니다.

언어는 인터페이스가 소프트웨어의 실제 부분이 아니라 소프트웨어에서 분리되어 있음을 의미합니다.

? 이에 대한 의견은 없습니다.

여기서 언급된 내용은 우리 부문에서

개발자와 엔지니어 사이에 차이가 있는 것처럼 보이고, 이는 반드시 더 많은 것. 나는 이 문제에 대해 의견이 없지만 오늘날 제목과 배너의 확산이 우리 각자가 실제로 하는 일과 관련하여 물을 탁하게 만들 뿐이라는 데 동의합니다.

CSS를 작성하는 것은 암묵적인 성차별과 회의실에서 메모 작성자의 중요성에 대한 평가절하로 완성되어 회의에서 메모를 하는 것과 매우 유사하게 간주되는 것 같습니다.

✅ 동의합니다.

이 기사에서 이미 언급한 바와 같이 나는 CSS와 프런트엔드 세계 전반의 잘못된 평가절하에 동의합니다. 또한 기사의 이 부분에서는 우리 분야에 존재하는 국수주의에 대해 언급하고 있으며, 비록 직접적으로 인식한 적은 없지만 그 현실과 심각성을 이해합니다. 우리 업계는 여전히 여성에게 적대적인 환경인 경우가 많습니다. 저는 커뮤니티가 이러한 사고방식에 맞서기 위해 더 많은 노력을 기울여야 한다고 믿습니다.

과거, 현재, 미래의 모든 가능한 장치, 운영 체제, 화면 크기, 브라우저, 사용자 선호도 및 인터페이스를 지원하는 거의 불가능한 작업이 너무 단순하기 때문에 지루했기 때문에 모든 복잡성을 스스로 발명했습니다.

✅ 이 진술의 본질적인 의미에 동의합니다.

오늘날 세상의 복잡성으로 인해 프런트엔드 개발자의 역할이 그 어느 때보다 더 복잡해지고, 프런트엔드 농담과

핵심 대사가 편견이 되면 오류에 빠지기 쉽습니다. 프론트엔드 작업자의 작업을 평가절하하는 함정.

네, 그룹으로서 우리는 새로운 것에 흥미를 느낍니다. 하지만 그것이 왜 우리를 호기심이나 적응력, 호기심으로 만들지 않습니까? 제자리에 머물기를 거부했다는 이유로 폄하되는 대신, 배움의 기쁨에 대해 공로를 인정받는 것이 어떨까요?

❌ 이 부분에 대해서는 덜 동의합니다.

앞서 언급한 것처럼 프런트엔드 세계의 진화로 인해 아이디어, 도구 및 방법론이 확산된 것은 사실이지만,

빛나는 개체 증후군은 특히 다음과 같은 분야에서 현실적이고 광범위한 문제입니다. 프론트엔드 커뮤니티. 이는 호기심이나 적응력이 없어야 한다는 의미가 아니라, 장점과 단점을 완전히 이해하지 못한 채, 실제로 필요한지 여부를 평가하지 않은 채 새로운 기술을 채택하는 함정에 빠지는 경우가 많다는 뜻입니다.

우리의 기술이 조직의 결점을 메워주는 덕트 테이프만큼 가치가 있다면, 잠재적으로 이를 예방할 수 있는데도 그러한 결함을 초래한 계획과 의사 결정 중에는 가치가 없는 이유는 무엇입니까?

✅ 전적으로 동의합니다.

소프트웨어 설계자(또는 기술 책임자 또는 아키텍처를 담당하는 사람)로서 최종 결정권과 궁극적인 책임이 있음에도 불구하고 아키텍처 선택에 팀의 모든 구성원을 참여시켜야 합니다. -애플리케이션 생성 또는 그 일부로 이어지는 프로세스 제작에는 프런트엔드 개발자를 포함한 팀의 모든 구성원이 참여해야 합니다. 이 일을 오랫동안 해오신 분들은 사용자 경험이나 디자인에서 다른 사람들이 볼 수 없는 공백을 찾아내고, 이들을 의사 결정 과정에 참여시켜 더 나은 사용자 경험과 성공적인 제품을 만들 수 있을 것입니다.

프런트엔드 도구는 마치 프런트엔드가 아무도 하고 싶어하지 않는 일인 것처럼 스스로를 홍보하며, 아무도 필요한 것 이상으로 신경써서는 안 됩니다.

❌ 글이 발전할수록 답답함이 커지는 걸 확실히 보실 수 있지만, 이 경우에는 동의할 수 없습니다.

Josh가 정의한 것처럼 프런트엔드 도구의

마케팅은 몇 가지 드문 예외를 제외하고는 개발자의 과제를 결코 사소화하거나 단순화하려고 시도한 적이 없습니다. 이러한 도구는 점점 더 프런트엔드 개발자의 작업을 더욱 단순하고 효율적으로 만드는 것을 목표로 하지만 결코 진부한 것이 아니며 방향은 동일하게 유지되는 것이 옳습니다. 약속은 결코 프론트엔드 개발자를 코드 원숭이로 만드는 것이 아니라 그가 진정으로 중요한 것, 즉 성공적인 사용자 경험을 창출하고 비즈니스와 주변 세계에 미치는 영향에 집중할 수 있도록 하는 것입니다. 개발자가 기술적 선택이나 구성 문제보다는 제품에 집중할 수 있도록 도구가 발전한 백엔드 세계에서도 마찬가지입니다.

마지막으로, 개발자 관계(Developer Relations)의 세계는 최근 몇 년 동안 체계적으로 발전해 왔으며 일부 회사의 실수가 표준으로 간주되어서는 안 된다는 점을 기억하시기 바랍니다.

더 이상 누구도 프런트엔드를 제품의 중요한 부분으로 생각하지 않는 것 같습니다. 그들은 그것을 제품이 들어 있는 멋진 상자로만 생각합니다.

❌ 여기서도 아쉽게도 Josh의 의견에 동의하지 않습니다.

프런트엔드는 제품의 기본 부분이며 그 중요성을 과소평가할 수는 없습니다. 하지만 그렇다고 해서 반드시 복잡성과 추상화에 빠져야 한다는 의미는 아닙니다. 프론트엔드 개발은 이미 매우 복잡한 디자인이나 난해한 아키텍처가 필요 없을 정도로 복잡하며, 백엔드 세계와 마찬가지로 표준화도 사실에 대한 완전한 지식을 바탕으로 수행된다면 불필요한 인지 부하를 추가하지 않고 다른 측면에 집중할 수 있게 해줍니다. 제품의.