oooooops 지금 우리는* 풀 스택 개발자라고 생각합니다

*"우리는"라면 프론트 엔드 개발자를 의미합니다.

불행한 산악 자전거 사고로 인해 내 출석을 막은 후 제작 된 2019 Jamstack Conf London 프레젠테이션의 서면 버전입니다. 나는 보관 목적으로 여기에서 그것을 다시 게시하고 WordPress Gutenberg의 기능을 보여줍니다.

? 안녕하세요! 저의 경력은 프론트 엔드 개발에 전념 했으며이 분야에서 다른 사람들이 탁월한 사람들을 돕습니다.

그리고 소년은 내 팔이 피곤합니다.

웹 개발 리소스 전용 웹 사이트 인 CSS- 트릭 (최근 12 주년을 기념하는)을 관리합니다.

또한 프론트 엔드 기술을위한 소셜 코딩 플랫폼 인 Codepen을 공동 설립했습니다.

또한 400 번째 에피소드에 가까운 Shoptalk Show Podcast를 공동 주최합니다.

이러한 경험을 통해 저는 수많은 개발자와 상호 작용하여 업계에 대한 귀중한 통찰력과 웹 사이트 제작의 다각적 인 특성을 얻었습니다.

프론트 엔드 개발자 역할 정의

✅ 직업 제목이자 공인 된 직업입니다.

이것은 단지 의미론이 아닙니다. 관련 고용 및 타이틀을 가진 진정한 일입니다. 재무 보상은 그 중요성을 강조합니다.

그러나 우리 가이 역할을 정의하는 방법 과 그 기대치는 주관적입니다.

모든 기술 구인 보드를 찾아 보면 프론트 엔드 개발자를위한 수많은 게시물이 있습니다.

프론트 엔드 개발자 역할 정의 (계속)

browser, 브라우저, 장치 및 사용자와 직접 상호 작용합니다.

많은 웹 전문가가 매일 브라우저를 사용하지만 프론트 엔드 개발자는 다양한 브라우저, 버전 및 플랫폼에서 DevTools를 사용하고 테스트를 활용하여 그 안에 살고 있습니다 .

결정적으로 접근성 고려 사항을 포함하여 사용자 경험의 우선 순위를 정합니다.

Mina Markham은 프론트 엔드 개발자 역할에 대한 높은 수준의 설명을 제공합니다. [사용 가능한 경우 Markham의 인용문 삽입].

백엔드 개발자와 구별이 존재합니다. 백엔드 개발자가 사용자를 무시하는 것은 아니라 책임이 배포됩니다.

Monica Dinculescu는 적절하게 말합니다. [사용 가능한 경우 Dinculescu의 인용문 삽입].

브라우저는 프론트 엔드 개발의 중심입니다. 브라우저에서 상황이 나타나고 작동하는 방식에 중점을두면 프론트 엔드 개발입니다. 자주 인정하는 것보다 더 어려운 일입니다.

프론트 엔드 개발자 역할 정의 (계속)

HTML, CSS 및 JavaScript에 대한 다양한 도구에도 불구하고 HTML, CSS 및 JavaScript에 의존합니다.

이들은 브라우저가 이해하는 기본 언어입니다. 다른 기술이 참여하는 동안 핵심 전달 가능은 이러한 언어로 거주하며 프론트 엔드 개발자는 이에 대해 책임을집니다.

숙련도 수준은 다양합니다. 일부 개발자는 최소한의 JavaScript를 작성할 수 있으며 다른 개발자는 그에 중점을 둡니다. 이것은 매혹적인 분열로 이어집니다.

나의 기사 "The Great Divide"는이 이분법을 탐구합니다. [가능한 경우 기사에 링크를 삽입].

이것은 단일 관점이 아닙니다. 수많은 개발자 들이이 분할을 인정합니다.

브래드 프로스트 (Brad Frost)는이 부문을 분류하기 위해 "전면 전면"과 "앞면"을 소개합니다. 그는이 다양성이 강점이라고 강조합니다.

Google 에서이 차이점은 두 커리어 경로에 대한 동등한 보상으로 작업 직책에 인식되고 반영됩니다.

2015 년 이후 JavaScript의 명성은 부인할 수 없습니다.

( 더 큰 전망의 경우 DevTools를 사용하십시오. 프론트 엔드 개발자입니다. )

우리의 역할은 본질적으로 매력적입니다! 우리는 모두 브라우저, 사용자 및 장치와 상호 작용합니다. 그러나 우리의 전문 지식과 기여는 크게 다릅니다.

일부는 디자인, 사진, 법적 측면, 성능 최적화, 접근성 또는 소셜 미디어를 전문으로합니다.

은유 적으로, 우리는 이것을 가지 트리로 시각화 할 수 있습니다. [가능한 경우 여기에 트리 다이어그램을 삽입].

이 은유는 완벽하지는 않지만 부서를 보여줍니다. 우리는 기본 기술을 공유하지만 다양한 전문 분야로 분기합니다. 한 지점은 JavaScript와 "앞면의 뒤쪽"작업에 크게 초점을 맞추고 다른 브랜치는 그렇지 않습니다.

이 토론은 프론트 엔드 개발자의 전체 스택 작업으로의 역할을 확장하는 데 중점을두기 때문에 더 강한 JavaScript 기술을 가진 사람들에게 초점을 맞추겠습니다.

웹 개발의 변화하는 환경

백엔드 작업은 JavaScript로 이동합니다

이전에 백엔드 책임을 고려한 많은 작업은 이제 JavaScript 영역 내에서 처리됩니다.

구성 요소 구동 설계 및 개발

감사합니다, JavaScript!

비 JavaScript 서버 측 렌더링 된 프로젝트는 구성 요소를 거의 수용하지 않아도됩니다 (예외는 존재하지만 광대 한 PHP CMS 및 Ruby on Rails Lincscapes를 고려하십시오). 템플릿과 포함은 존재했지만 실제 구성 요소 중심 개발과 비교할 때 창백합니다.

흥미롭게도 JavaScript 프레임 워크 간의 의견 불일치에도 불구하고 구성 요소의 개념은 보편적으로 받아 들여집니다. 기본 웹 구성 요소조차도이를 반영합니다.

Codepen (주로 반응하는 힘)을 살펴 보겠습니다. 작은 SVG 아이콘조차도 구성 요소입니다. 우리는 그것을 an이라고 부릅니다<svgicon></svgicon> 유용한 측면을 추상화하기 때문에 구성 요소.

숫자와 아이콘을 짝을 이루는 것은 반복 패턴과 잠재적 인 대화식 기능으로 인해 또 다른 구성 요소입니다.

한 줄의 MetaItem 구성 요소는 항목의 다른 디스플레이 측면과 함께 구성 요소가 될 수 있습니다.

결과적으로 전체 항목이 구성 요소가됩니다.

이들은 UI 구성을위한 시각적 및 기능적 추상화입니다. 시맨틱 HTML은 그것들을 뒷받침하지만 이러한 추상화는 맞춤형 빌딩 블록입니다.

더 큰 섹션은 구성 요소가됩니다. 항목의 그리드는 레이아웃과 페이지 매김을 관리하는 구성 요소가됩니다.

디자이너는 종종 구성 요소와 개념적으로 유사한 "Symbols"를 사용하여 Figma, Sketch 및 Adobe XD와 같은 도구에서 이런 방식으로 작동합니다.

많은 개발자들이 구성 요소를 쉽게 이해합니다.

사이트 수준 아키텍처/라우팅

JavaScript로 이동하는 백엔드 작업 (계속)

URL 처리 및 사이트 구조는 전통적으로 백엔드 문제였습니다. 이제 "라우팅"은 점점 더 프론트 엔드 책임입니다.

[여기에 코드 스 니펫 삽입]

Codepen의 UI에서 구성 요소화는 그리드를 넘어 확장됩니다. 탭, 제목, 버튼, 양식, 메뉴 및 사이드 바 : 모든 것이 구성 요소가됩니다.

궁극적으로 전체 페이지가 구성 요소가되어 URL을 구성 요소로 효과적으로 변환합니다.

모든 URL은 구성 요소가되어 전체 사이트를 제어 할 수 있습니다.

이 건축 책임은 상당합니다. 기존 프론트 엔드 워크로드를 고려하십시오. 사라지지 않습니다. 확장됩니다. 이것은 프론트 엔드 개발자에게 풀 스택과 같은 역할의 유병률이 증가하고 있음을 설명합니다.

주 관리, 데이터 수집 및 조작

JavaScript로 이동하는 백엔드 작업 (계속)

대부분의 JavaScript 프레임 워크의 중심 인 State Management는 과거의 많은 프론트 엔드 스파게티 문제를 해결합니다.

그러나 State는 종종 데이터 수집에 의존하며, 이제는 종종 프론트 엔드 책임입니다. 서버로 데이터를 업데이트하고 전송하면 더 복잡성이 추가됩니다.

GraphQL은 강력한 솔루션을 제공합니다. 그 가치는 다양하지만 저에게는 권한 부여에 관한 것입니다.

강력한 GraphQL 엔드 포인트와 Apollo와 같은 도구를 사용하여 프론트 엔드 개발자는 UI 구성에 필요한 모든 데이터에 액세스 할 수 있습니다.

[여기에 그래프 QL 쿼리 코드 스 니펫 삽입]

데이터 가져 오기 및 비동기 처리는 구성 요소 내에서 관리됩니다. 골격, 스피너 또는 지연 렌더링을 사용해야합니까? 오류 및 타임 아웃은 어떻게 처리됩니까?

GraphQL 돌연변이를 통해 데이터 조작 및 전송 업데이트도 처리됩니다.

[여기에 그래프 QL 돌연변이 코드 스 니펫 삽입]

돌연변이는 쿼리보다 훨씬 더 복잡하지는 않지만 이는 프론트 엔드 개발자의 워크로드에 추가됩니다. 이전에 백엔드에서 처리 된 작업.

이 예는 React의 Apollo 클라이언트를 통한 GraphQL을 보여줍니다.

구성 요소, 쿼리, 돌연변이 및 스타일과 관련하여 스타일링 정보를 공동으로하는 스타일을 고려해 봅시다.

프론트 엔드 개발자는 항상 스타일을 관리했지만 자체 포함 된 구성 요소 내에서 스타일링하는 스타일이 합리적입니다.

여기에서 CSS는 특정 구성 요소에 대한 범위 스타일을 모듈합니다. 추상화를위한 글로벌 스타일과 Sass가 여전히 사용됩니다.

[여기에 CSS 모듈 코드 스 니펫 삽입]

[스타일의 가져 오기를 보여주는 코드 스 니펫 삽입]

구성 및 공동 위치는 논리, 템플릿, 쿼리, 돌연변이 및 스타일을 포함하는 폴더를 초래합니다.

이것은 편리하고 긍정적 인 부작용이 있습니다. JavaScript 다발에는 필요한 것 (코드 분할) 만 포함합니다. 스타일링은 팽창하지 않습니다. 구성 요소가 사용되지 않으면 스타일이 제거됩니다. 파일 스코핑 이름 지정으로 인해 이름 지정이 단순화됩니다.

GraphQL 다큐멘터리는 통찰력이 있습니다. Kyle Mathews (약 20:24)는 프론트 엔드 문제와 그래프 QL의 유사한 효과에 대한 React의 영향에 대해 논의합니다.

모든 프로젝트에 적합하지는 않지만이 접근법은 크고 복잡한 응용 프로그램에 유리합니다.

기존 프론트 엔드 책임 :

• 설계 구현
• 설계의 시스템 통합
• 접근성 고려 사항
• 성능 최적화
• 크로스 브라우저 테스트
• 교차 장치 테스트
• UX 고려 사항

새로운 책임 :

• 구성 요소 중심 디자인
• 사이트 수준 아키텍처
• 라우팅
• 데이터 가져 오기
• API 상호 작용
• 데이터 돌연변이
• 국가 관리

워크로드가 크게 확장됩니다. 이것은 모든 사람이 모든 측면을 마스터해야한다는 의미는 아니지만 이러한 작업은 프론트 엔드 도메인에 속합니다.

Peggy Rayzis는 프론트 엔드 개발의 광범위한 범위와 증가하는 전문화에 대해 논의합니다.

많은 작업이 백엔드에서 JavaScript로 이동했습니다.

진화하는 기술 스펙트럼

기술 스펙트럼의 진화를 살펴 보겠습니다.

램프 (Linux, Apache, MySQL, PHP)는 오래된 스택에도 많은 CMS에 전원을 공급하지만 중요합니다. 이 스택의 프론트 엔드 개발자는 스펙트럼의 맨 끝에 있으며 스택의 핵심 기술과 최소한으로 상호 작용합니다.

평균 (MongoDB, Express, Angular, Node)에는 각도, 프론트 엔드 프레임 워크가 포함됩니다. 프론트 엔드 개발자의 작업은이 스택과 더 겹칩니다.

서버리스는 스택을 오른쪽으로 더 이동시킵니다. 서버 아이덴티티는 덜 관련성이 높아집니다. 초점은 서버 측 코드 및 API에 중점을 둡니다. 프론트 엔드 개발자는 서버리스 기능을 작성하고 API를 관리 할 수도 있습니다.

Shawn Wang은 디자인 시스템, Typescript, Apollo GraphQL 및 모든 프론트 엔드 기술을 반응했습니다.

기술 토론은 점점 더 프론트 엔드 개발자 스펙트럼에 중점을두고 있습니다.

프론트 엔드 기능의 서버리스 확장

Serverless Technologies에 대한 웹 사이트를 만들었습니다. [사용 가능한 경우 웹 사이트에 링크를 삽입].

Jamstack (JavaScript, API, Markup)이 서버리스 이동의 일부를 고려합니다. (Shamstack은 더 정확하고 혀 뺨이 될 수 있습니다).

다음은 서버리스 기술을 활용하는 Jamstack 사이트입니다. 다가오는 프론트 엔드 개발 컨퍼런스를 나열하는 사이트 : [사용 가능한 경우 사이트에 링크 삽입].

[여기에 Markdown 파일 코드 스 니펫 삽입]

각 회의는 메타 데이터에 대한 프론트 물질이있는 마크 다운 파일입니다. 정적 사이트 생성기와 플랫 마크 다운 파일은 자연스럽게 맞습니다.

이 사이트는 공개 Github 저장소입니다. 이것은 중요합니다 :

1. 전체 사이트는 Repo에 있습니다. 배포에는 복제 및 단일 명령이 포함됩니다.
2. 로그인, 권한 또는 자격 증명이 필요하지 않습니다.
3. 컨텐츠, 디자인 및 기능은 공개 기여를 위해 열려 있습니다.

GitHub 페이지는 사이트를 호스팅 할 수 있지만 NetLify는 중요한 이점을 제공합니다.

• 배포 미리보기
• 분석 통합
• 프로그래밍 방식 이미지 조작

Netlify CMS는 현장 컨텐츠 편집을위한 UI를 제공하여 코드 편집 또는 GIT를 제거합니다. Netlify Identity는 인증을 단순화합니다.

기능을 고려하십시오 : 버튼에 이메일 입력 양식이 표시됩니다. 이메일을 제출하면 회의 세부 정보가 포함 된 이메일이 발생합니다.

이를 위해서는 백엔드 기능이 필요합니다. 고객 측 기술만으로는 이메일을 보낼 수 없습니다. API가 사용되지만 API 키에는 안전한 관리를 위해 백엔드 코드가 필요합니다.

[여기에 SparkPost 코드 스 니펫 삽입]

SparkPost는 이메일 전송을 처리합니다. Node.js 라이브러리는 프로세스를 단순화합니다. 코드는 JavaScript입니다.

이것은 어떻게 실행됩니까? 클라우드 기능 (AWS Lambda, Azure Functions, Google Cloud Functions)은 서버리스의 핵심입니다. NetLify는 NetLify 함수 (후드 아래 AWS Lambda)를 사용합니다. 함수는 /functions/ 폴더에 배치되며 상대 URL을 통해 액세스합니다.

앞서서 전체 사이트를 구축하면 강력합니다.

재 방문 된 기술 스펙트럼

운영 체제 및 서버는 관련성이 떨어집니다. 전체 제품은 이것에 초점을 맞추지 않고 구축 할 수 있습니다.

데이터베이스는 덜 중요합니다. 데이터 상호 작용은 종종 API (Contentful, Faunadb와 같은 API 중심 도구 또는 Firestore와 같은 영역 라이브러리와 같은 헤드리스 CMS)를 통해 발생합니다.

기술 스펙트럼은 모든 부품과의 상호 작용을 허용합니다.

풀 스택 기능

첨가:

• 숙련도
• 테스트 기술
• 디자인 기능
• 프로세스 지식을 구축하십시오
• 성과 인식
• 접근성 전문 지식
• 배포 파이프 라인 설정

?
당신은 성가신
오른쪽으로 당황했습니다
풀 스택
개발자!

하지만,

스킬 셋은 광대합니다.

전문화가 가능하고 가능성이 높습니다.

"실제"유니콘 (웹 사이트 구축의 모든 측면에 능숙한 것)은 드 rare니다.

백엔드 개발자는 여전히 중요합니다. 웹 사이트 복잡성은 그들의 전문 지식이 필요합니다.

Codepen의 문제 추적기는 혼자서 다룰 수없는 작업을 보여줍니다. 백엔드 지원이 필수적입니다. 나는 나 자신을 풀 스택으로 생각할 수 있지만 백엔드 기술은 나의 약점이다.

현실은 종종 이것과 비슷합니다.

또는 내 경우 : [약점 영역을 강조하는 겹치는 겹치는 다이어그램 삽입].

이것은 멸시적인 것이 아닙니다. 은유입니다. 우리는 전체 말이나 용이지만 거친 가장자리가 있습니다.

기술을 통해 전체 프로세스를 포괄 할 수 있다는 것은 흥미 롭습니다. 복잡성이 진입 장벽을 높일 때 우려가 발생합니다. 그러나 기술이 프로세스를 단순화 할 때도 권장되어 개인이 독립적으로 물건을 구축 할 수 있습니다.

품질은 모든 사람의 책임이라는 것을 기억하십시오.

• 좋은 ux
• 좋은 성능
• 좋은 보안
• 좋은 접근성
• 사용자의 윤리적 치료

이러한 측면에 영향을 미치는 코드에 직접 관여하지 않더라도 적절한 취급을 옹호하십시오.

Codepen Pro (지역 장인 공예 소프트웨어 제품 지원)

위 내용은 oooooops 지금 우리는* 풀 스택 개발자라고 생각합니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!