인터페이스 개발 학교: 민스크 및 모스크바의 새로운 세트에 대한 작업 분석

오늘 새로운 등록이 시작되었습니다. Yandex 인터페이스 개발 학교 모스크바에서. 7단계 교육은 25월 3일부터 XNUMX월 XNUMX일까지 진행됩니다. 다른 도시의 학생들은 원격으로 또는 직접 참여할 수 있습니다. 회사는 호스텔에서의 여행 및 숙박 비용을 지불합니다. 마지막 단계이기도 한 두 번째 단계는 XNUMX월 XNUMX일까지 지속되며, 직접 방문해야만 완료할 수 있습니다.

제 이름은 Yulia Seredich입니다. 우리는 Sergei Kazakov와 함께 이 게시물을 썼습니다. 우리는 둘 다 Yandex 민스크 사무소의 인터페이스 개발자이자 지난 몇 년 동안 SRI를 졸업했습니다.

모스크바 등록 개시를 계기로 우리는 여기 민스크의 이전 학교에 대한 입문 과제 분석을 출판하고 있습니다.

SRI 과제의 내역을 추적하면 해마다 우리는 프로그래머를 위한 세 가지 중요한 기술을 테스트했습니다.

• 공들여 나열한 것. 모든 개발자는 레이아웃을 할 수 있어야 합니다. 팀 전체를 위해 디자인하는 Seryozha 삼촌이 있고 스크립트만 작성하는 경우는 없습니다. 그러므로 모든 학생은 조판 방법을 어떻게 아는지 보여주어야 합니다.
• 자바스크립트. 문제가 레이아웃에만 국한된다면 인터페이스 개발 학교가 아니라 레이아웃 디자이너 학교가 있을 것입니다. 아름답게 디자인된 인터페이스가 부활해야 합니다. 따라서 항상 JS의 과제가 있지만 때로는 알고리즘의 과제이기도 합니다. 우리는 이를 너무나 좋아합니다.
• 문제 해결은 아마도 개발자의 가장 중요한 기술일 것입니다. 인터페이스 생성과 관련하여 상황은 매우 빠르게 변화하고 있습니다. 루이스 캐럴의 말과 같습니다. "같은 자리에 머물려면 최대한 빨리 달려야 하고, 다른 곳으로 가려면 두 배 더 빨리 달려야 합니다." 우리는 매일 새로운 기술을 접하게 됩니다. 우리는 이를 고려하고 이해할 수 있어야 합니다. 따라서 세 번째 과제에서는 초보 개발자가 일반적으로 익숙하지 않은 기술에 대한 이해를 제안했습니다.

각 작업을 분석하면서 올바른 절차뿐만 아니라 흔히 발생하는 실수에 대해서도 알려드립니다.

작업 1: 포트폴리오

첫 번째 작업은 레이아웃 방법을 알고 있는 Yandex.Collections 디자이너 Alexey Cherenkevich와 그의 서비스 동료인 인터페이스 개발자 Sergey Samsonov가 수행했습니다.

조건

포트폴리오 웹사이트를 만드세요: 자신과 학업, 학교에 대한 기대에 대해 알려주세요. 사이트는 제안된 레이아웃과 최대한 일치해야 합니다(레이아웃 링크: 1000px, 600px, 320px, 사양). 우리는 레이아웃에만 관심이 있으므로 JavaScript를 사용하지 마십시오.

확인할 때 다음 사항을 고려합니다.

• 들여쓰기 크기, 색상 정확성, 글꼴 스타일, 글꼴 크기;
• 의미론적 레이아웃;
• 다양한 상태의 요소 존재: 커서를 가리키면 버튼과 링크 표시, 활성 입력 필드 강조 표시 등
• 브라우저 간 호환성(인기 브라우저의 최신 버전에서 테스트됨)

장점은 다음과 같습니다.

• 최신 CSS 솔루션 사용: flexbox, 그리드 등
• 적응형 레이아웃
• 전처리기 및/또는 후처리기 사용, 조립, 축소, 출력 코드 최적화
• HTML 양식 유효성 검사, 양식화된 파일 업로드 버튼.

작업이 상당히 방대하므로 작동하지 않는 작업은 건너뛸 수 있습니다. 이렇게 하면 점수가 약간 낮아지지만 여전히 지식을 입증할 수 있습니다. 완료되면 귀하의 포트폴리오와 GitHub의 소스 코드에 대한 두 개의 링크를 보내주십시오.

과제에서 제안한 레이아웃은 모바일 기기, 태블릿, 데스크톱의 화면뿐만 아니라 실제 사양에도 맞춰져 있었습니다.

첫 번째 작업 확인 결과에 최대한 객관성을 부여하기 위해 이번 확인에는 많은 기준이 있었습니다.

기준

디자인된 웹사이트. 이것은 당연한 것처럼 보이지만 어떤 사람들은 시간을 절약하고 싶었거나 할 수 없었기 때문에 일부 블록을 완전히 건너뛰었습니다. 레이아웃은 대략 네 가지 기본 화면으로 나눌 수 있습니다. 아바타가 포함된 기본 화면, SRI의 기대 사항 목록이 포함된 블록, 포트폴리오가 포함된 블록, 연락처 정보가 포함된 블록입니다. 섹션으로 만들 수도 있고 간단히 div를 사용하여 만들 수도 있습니다. 가장 중요한 점은 네 개의 블록을 모두 사용할 수 있다는 것입니다.

레이아웃과 레이아웃 준수. 디자이너는 응시자가 쉽게 사용할 수 있도록 별도의 사양(색상, 타이포그래피, 버튼 상태 등)을 만들었습니다. 하단에는 첫 화면의 들여쓰기와 기능에 대한 힌트가 있었습니다. 디자이너의 모든 요구 사항을 고려한 직원들이 매우 기뻤습니다. 예를 들어 첫 번째 화면은 뷰포트 높이 이상이어야 했습니다.

적응형 레이아웃 - 이것은 세 가지 해상도에서 레이아웃의 모든 것이 픽셀 단위가 되도록 인터페이스가 단지 레이아웃되지 않은 경우입니다. 중간 상태에서도 레이아웃이 무너져서는 안 됩니다. 일부는 컨테이너의 최대 너비를 제한하고 모든 것을 1920픽셀로 설정하는 것을 잊어버렸고, 일부는 배경을 엉망으로 만들었지만 전반적으로 후보자들은 이 작업에 잘 대처했습니다.

의미론적 레이아웃. 링크가 , 버튼 – 으로 디자인되어야 한다고 “그들은 세상에 몇 번이나 말했습니까?” 다행히도 대부분의 지원자들이 이 요구 사항도 충족했습니다. SRI의 기대에 모두가 숨겨진 목록을 인식하지는 못하여 div 태그를 사용하여 만들었지만 그다지 나쁘지는 않습니다. 필요한 부분과 필요하지 않은 부분 등 자신이 알고 있는 모든 의미 태그를 삽입한 후보자가 있었습니다. 예를 들어 목록 대신 - 및 . 결국 의미론은 페이지 구성과 각 블록의 목적(대부분은 여기에서 관리함), 전처리기 및/또는 후처리기(몇몇은 여기에서 관리했지만)의 사용을 이해하는 것입니다. 또한 요점이 있었습니다. 대부분 less 및 scss를 사용했습니다.

작동하는 슬라이더. 과제에서 JS를 사용할 수 없다고 썼습니다. 여기에서 문제 해결 능력이 테스트되었습니다. 여러 개를 사용하여 슬라이더를 만들 수 있습니다. 그리고 . 모든 마법은 선택기 수준 #button-N:checked ~ .slider-inner .slider-slides에서 발생합니다. 입력 체크박스 중 하나를 클릭하면 체크된 상태가 됩니다. 이를 활용하여 슬라이드가 포함된 컨테이너에 필요한 번역을 할당할 수 있습니다: 변환: 번역(-33%). 슬라이더의 구현을 볼 수 있습니다. 여기에.

드롭다운 목록. 여기에 모든 것이 내려졌습니다. 유사한 선택기: .accordion-item input:checked ~ .accordion-item__content. 구현된 모습을 볼 수 있습니다 여기에.

:hover, :active 및 :focu* 상태의 가용성. 매우 중요한 점입니다. 인터페이스와의 상호 작용 중 편안함은 이에 달려 있습니다. 사용자는 항상 자신의 행동에 대한 피드백을 받아야 합니다. 이 항목은 설문지와의 상호작용 전반에 걸쳐 확인되었습니다. "전화하기" 버튼을 클릭했는데 시각적으로 아무 일도 일어나지 않았다면(요청이 전송되었음에도 불구하고) 이 버튼을 계속해서 클릭하게 되므로 이는 잘못된 것입니다. 결과적으로 XNUMX개의 요청이 전송되고 XNUMX번의 회신을 받게 됩니다. 모바일 장치에는 마우스가 없다는 점을 잊어서는 안 됩니다. 이는 마우스 오버가 없어야 함을 의미합니다. 그리고 의미론에 대한 요점을 충족한 사람들에게 영향을 미치지 않은 또 하나의 요점입니다. 컨트롤이 대화형 요소가 아닌 경우 컨트롤 위로 마우스를 가져가면 커서가 표준으로 유지됩니다. hover에 대한 반응을 작성했음에도 불구하고 매우 어수선해 보입니다. 커서를 과소평가하지 마세요: 포인터.

애니메이션. 요소와 함께 발생하는 모든 반응이 원활하게 진행되는 것이 중요합니다. 인생에서 순간적인 것은 없기 때문에 마우스 오버 및 활성 상태에서 전환하는 것만으로도 인터페이스를 더욱 즐겁게 만들 수 있었습니다. 음, 슬라이더와 목록에 애니메이션을 적용한 사람들은 일반적으로 훌륭합니다.

최신 기술 사용. 많은 사람들이 flex를 사용했지만 그리드를 사용하여 작업을 완료한 사람은 아무도 없었습니다. flex가 올바르게 사용되면 포인트가 계산됩니다. 이러한 유연성으로 인해 레이아웃이 어딘가에서 분리된 경우 아쉽게도 추가 포인트를 받지 못했습니다.

양식 검증. 필요한 것은 양식의 각 입력에 필수 속성을 추가하는 것뿐이었습니다. 이메일 항목을 이메일로 인증해주신 분들께 포인트를 추가하였습니다.

파일 업로드 버튼 스타일 지정. 우리는 다음과 같은 조합을 볼 것으로 예상했습니다. 파일을 선택합니다 . 다음으로 입력을 숨기고 레이블의 스타일을 지정해야 했습니다. 또 다른 일반적인 방법이 있습니다. 투명한 입력을 만들어 버튼 위에 놓는 것입니다. 그러나 모든 브라우저가 스타일 지정을 허용하는 것은 아닙니다. , 이러한 솔루션은 완전한 크로스 브라우저라고 할 수 없습니다. 그리고 라벨을 만드는 것이 의미상 더 정확합니다.

브라우저 간 호환성. 우리는 두 가지 최신 버전의 최신 브라우저(IE가 없고 참가자들은 운이 좋았음)와 iPhone의 Safari 및 Android의 Chrome에서 모든 것이 괜찮은지 확인했습니다.

반대로 누군가가 JS나 Bootstrap을 사용하면 점수가 차감됩니다. 둘 다 전체 작업의 목적을 무너뜨리게 됩니다. 또한 Bootstrap 참가자는 마이너스를 받았을 뿐만 아니라 의미 및 구현 요소에 대해서도 많은 점수를 잃었습니다.

인터넷 어딘가에 사이트를 호스팅한 사람들은 특별한 이점을 얻지 못했지만 리뷰어들은 저장소를 다운로드하여 컴퓨터에서 로컬로 실행할 필요가 없어서 매우 기뻤습니다. 그래서 이것은 카르마에 플러스 역할을 했습니다.

첫 번째 작업은 주로 학생에게 매우 유용했습니다. 우리가 수락하지 않은 사람들은 이제 준비된 이력서를 갖게 됩니다. 모든 응답에 자랑스럽게 첨부하거나 gh-페이지에 게시할 수 있습니다.

작업 2: 운송 경로

이 작업의 작성자는 검색 인터페이스 그룹 Denis Balyko의 책임자입니다.

조건

별 지도가 있나요? 각 별의 이름은 물론, 해당 별에서 다른 별까지의 거리도 광초 단위로 표시됩니다. 세 가지 인수를 취해야 하는 솔루션 함수를 구현합니다. 키가 별의 이름이고 값이 별까지의 거리(우주에서의 일방향 교통)인 객체와 별의 이름입니다. 경로의 시작점과 끝점 - 각각 시작과 끝. 이 함수는 시작 별에서 끝 별까지의 최단 거리와 따라야 할 경로를 반환해야 합니다.

기능 서명:

const solution = function(graph, start, finish)  {
    // Ваше решение
} 

입력 데이터 예시:

const graph = {
  start: { A: 50, B: 20 },
  A: { C: 40, D: 20 },
  B: { A: 90, D: 90 },
  C: { D: 160, finish: 50 },
  D: { finish: 20 },
  finish: {}
};
const start = 'start';
const finish = 'finish'; 

예제 출력:

{
    distance: 90,
    path: ['start', 'A', 'D', 'finish']
} 

참고: 솔루션 스켈레톤은 src/ 폴더에 있습니다. 솔루션을 Solution.js에 넣으세요.

두 번째 작업의 검증은 가장 자동화되고 객관적이었습니다. 대부분의 사람들은 Dijkstra의 알고리즘을 구현하는 것이 필요하다고 추측했습니다. 설명을 찾아내고 알고리즘을 JS로 구현한 분들은 수고하셨습니다. 그런데 과제를 확인해 보니 같은 오류가 있는 논문이 많이 보였습니다. 우리는 인터넷에서 코드 조각을 검색하여 참가자들이 알고리즘을 복사한 기사를 찾았습니다. 많은 사람들이 작성자의 의견과 함께 기사의 코드를 복사했다는 것이 재밌습니다. 이러한 작품은 낮은 점수를 받았습니다. 우리는 어떤 출처의 사용도 금지하지 않지만, 우리는 사람이 자신이 쓴 내용을 탐구하기를 원합니다.

기준

테스트에 대한 주요 포인트가 부여되었습니다. 때로는 사람들이 저장소를 조작하고 폴더 이름을 바꾸며 필요한 파일을 찾을 수 없다는 이유만으로 테스트가 실패할 것이 분명했습니다. 올해 우리는 그런 사람들을 도우려고 노력했고 그들을 위해 모든 것을 제자리로 되돌려 놓았습니다. 하지만 내년에는 콘테스트 시스템으로 전환할 계획이고, 이는 더 이상 용서되지 않을 것입니다.

또한 "인간", 수동 기준도 있었습니다. 예를 들어 단일 코드 스타일이 있습니다. 공백 대신 탭을 사용해도 점수가 차감되지 않으며 그 반대도 마찬가지입니다. 알려진 규칙에 따라 작은따옴표를 큰따옴표로 바꾸고 세미콜론을 무작위로 배치하는 것은 또 다른 문제입니다.

솔루션의 명확성과 가독성은 별도로 고려되었습니다. 세계의 모든 컨퍼런스에서는 프로그래머의 직업 중 80%가 다른 사람의 코드를 읽는 것이라고 말합니다. 학생들도 큐레이터와 서로의 코드 리뷰를 받습니다. 그래서 이 기준은 상당한 비중을 차지했습니다. 한 글자 이상의 변수가 없는 작품도 있으니 그러지 마세요. Stella Chang의 의견과 동일한 의견을 제외하면 참가자들의 의견은 매우 고무적이었습니다.

마지막 기준은 자동 테스트의 존재입니다. 소수의 사람들만이 그것을 추가했지만 모든 사람에게 그것은 카르마에 큰 플러스가 되었습니다.

올바른 솔루션:

const solution = function(graph, START, FINISH)  {
    // Всё не бесплатно в этом мире
    const costs = Object.assign({[FINISH]: Infinity}, graph[START]);

    // Первая волна родительских нод
    const parents = { [FINISH]: null };
    Object.keys(graph[START]).reduce((acc, child) => (acc[child] = START) && acc, parents)

    const visited = [];
    let node;

    // Ищем «дешёвого» родителя, отмечаем пройденные
    do {
        node = lowestCostNode(costs, visited);
        let children = graph[node];
        for (let n in children) {
            let newCost = costs[node] + children[n];

            // Ещё не оценена или нашёлся более дешёвый переход
            if (!costs[n] || costs[n] > newCost) {
                costs[n] = newCost;
                parents[n] = node;
            }
        }
        visited.push(node);
    } while (node)

    return {
        distance: costs[FINISH],
        path: optimalPath(parents)
    };

    // Возврат назад по самым «дешёвым» родителям
    function optimalPath(parents) {
        let optimalPath = [FINISH];
        let parent = parents[FINISH];
        while (parent && parent !== START) {
            optimalPath.push(parent);
            parent = parents[parent];
        }
        optimalPath.push(START);
        return optimalPath.reverse();
    }

    // Минимальная стоимость из текущей ноды среди непросмотренных
    function lowestCostNode(costs, visited) {
        return Object.keys(costs).reduce((lowest, node) => {
            if (lowest === null || costs[node] < costs[lowest]) {
                if (!visited.includes(node)) {
                    lowest = node;
                }
            }

            return lowest;
        }, null);
    };
};

작업 3: 이벤트 캘린더

인터페이스 개발자 Sergey Kazakov와 Alexander Podskrebkin이 준비했습니다.

조건

일정을 표시할 미니 달력을 작성해 보세요. 원하는 일정을 택할 수 있습니다. 예를 들어 2019년 프론트엔드 컨퍼런스 일정입니다.

달력은 목록처럼 보여야 합니다. 다른 디자인 요구 사항은 없습니다. 이벤트 알림을 3일, 7일, 14일 전에 미리 설정할 수 있습니다. 인터넷에서 처음 다운로드한 후에는 캘린더가 열리고 오프라인으로 작동해야 합니다.

유용한 자료

프론트엔드 컨퍼런스 일정:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

서비스 작업자:
개발자.mozilla.org/ru/docs/Web/API/Service_Worker_API/Using_Service_Workers
개발자.google.com/web/fundamentals/primers/service-workers

알림 API:
개발자.mozilla.org/ru/docs/Web/API/Notifications_API

세 번째 작업은 테스트하기에 가장 흥미로웠습니다. 각각 고유한 솔루션이 너무 많았기 때문입니다. 우리는 후보자가 익숙하지 않은 기술을 어떻게 처리하는지, 즉 그가 연구하는 방법을 알고 있는지, 자신의 솔루션을 테스트하는지 확인했습니다.

기준

접힌 달력. 예, 아직 배치가 필요했습니다. 조건을 너무 문자 그대로 받아들이고 CSS 코드 한 줄도 삽입하지 않는 사람들도 있었습니다. 그다지 매력적이지는 않았지만 모든 것이 작동하면 포인트가 줄어들지 않았습니다.

소스에서 이벤트 목록 가져오기. 이는 레이아웃 작업이 아니므로 포함된 이벤트 목록은 계산되지 않습니다. 언제든지 회의를 취소하거나 일정을 변경하거나 새 회의를 추가할 수 있습니다. 그래서 외부로부터 데이터를 받고, 받은 JSON을 기반으로 레이아웃을 렌더링하는 작업이 필요했습니다. 어떤 방식으로든(fetch 메서드를 사용하거나 XMLHttpRequest를 사용하여) 데이터를 얻는 것이 중요했습니다. 어떤 사람이 가져오기용 폴리필을 추가하고 추가 정보에 자신의 선택을 표시한 경우 이는 플러스로 간주되었습니다.

오류 없는 서비스 워커 등록 첫 번째 다운로드 후에는 오프라인으로 작업할 수 있습니다. 다음은 그 예입니다. 첫 번째 부팅 시 일정 캐싱을 사용하는 서비스 워커. 서비스 작업자, 해당 기능 및 작업 방법(캐시 작업 전략, 오프라인 작업)에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

알림을 설정하는 기능그래서 실제로는 3, 7, 14일 후에 작동합니다. 알림 API를 이해하는 것이 필요했습니다. 링크 임무를 수행 중이었어. 우리는 푸시할 시점인지 확인하기 위한 특정 구현을 기대하지 않았습니다. 모든 작업 옵션이 허용되었습니다: localStorage에 저장, IndexDB 또는 서비스 워커에 의한 정기적인 폴링. 푸시 서버를 만드는 것도 가능했습니다(여기 예), 하지만 오프라인에서는 작동하지 않습니다. 페이지가 닫힌 후 푸시를 수신하고 일정 시간이 지난 후 열리는 것도 똑같이 중요했습니다. 페이지가 닫히는 동시에 알림이 종료되면 솔루션이 계산되지 않습니다. 사람들이 리뷰어에 대해 생각하고 3 일을 기다리지 않도록 지금 당장 추진할 수 있도록 만든 것은 멋진 일입니다.

바탕 화면에 아이콘을 배치하는 기능 (PWA). 파일의 존재를 확인했습니다 manifest.json 올바른 아이콘으로. 어떤 사람들은 이 파일을 만들었지만(또는 CreateReactApp에서 생성된 채로 두었음) 올바른 아이콘을 추가하지 않았습니다. 그러다가 설치하려고 하면 “다른 아이콘이 필요합니다” 같은 오류가 발생했습니다.

코드 스타일 및 프로젝트 구조. 두 번째 작업과 마찬가지로 단일 코드 스타일을 살펴보았습니다(비록 우리 코드 스타일과 일치하지 않더라도). 어떤 사람들은 린터를 망쳤습니다. 정말 좋습니다.

콘솔 오류. 콘솔에 문제가 있다는 표시가 있고 참가자가 이에 주의를 기울이지 않은 경우 점수가 차감됩니다.

결과

참가자들의 결정에서 재미있는 점은 무엇입니까?

• 한 설문지에는 다음과 같은 텍스트가 포함되어 있습니다. “프로그래머 친구가 제가 React 애플리케이션을 만드는 데 도움을 주었습니다. 나는 그에게 방법과 이유에 대한 질문을 퍼부었고 그는 나에게 말했습니다. 정말 마음에 들었어요. 더 알고 싶어요.” 우리는 이 지원서를 온 마음을 다해 응원하고 있었지만 안타깝게도 후보자의 친구는 지원서가 작동하는 데 별로 도움이 되지 않았습니다.
• 한 후보자는 RAR 아카이브가 있는 GitHub에 대한 링크를 보냈습니다. 이에 대해 언급하기가 어렵습니다. 🙂
• 또 다른 후보자는 Solution.js 파일 첫 줄의 댓글에서 자신이 알고리즘을 복사했다는 사실을 솔직하게 인정했다.

76명의 후보자로부터 지원서를 받아 23명을 선발했습니다. 우리는 민스크뿐만 아니라 모스크바, 상트페테르부르크, 심지어 타타르스탄에서도 설문지를 보냈습니다. 그 중 일부는 현재 직업으로 인해 우리를 놀라게 했습니다. 그 중 한 명은 법의학 전문가이고 다른 한 명은 의과대학생이었습니다.

그 결과 작업 완료 성공률의 흥미로운 분포가 나타났습니다. 참가자들은 첫 번째 작업을 평균 60%, 두 번째 작업을 50%, 세 번째 작업이 가장 어려워 평균 40% 정도 완료했습니다.

언뜻 보면 작업이 복잡하고 시간이 많이 걸리는 것처럼 보입니다. 그 이유는 가능한 한 많은 후보자를 제거하고 싶기 때문이 아닙니다. 공부하는 동안 학생들은 채팅 만들기, 어린이를 위한 Yandex.Music, 날씨에 의존하는 사람들을 위한 Yandex.Weather 등 실제 작업에 직면하게 됩니다. 이를 위해서는 시작 기반이 필요합니다.

80년 전 SRI 입학 과제를 보고 절대 풀지 못할 거라고 생각했던 기억이 납니다. 이 순간 가장 중요한 것은 앉아서 조건을주의 깊게 읽고 시작하는 것입니다. 조건에 솔루션의 거의 XNUMX%가 포함되어 있는 것으로 나타났습니다. 예를 들어, 세 번째 작업(가장 어려운 작업)의 조건에서는 MDN의 서비스 워커 및 알림 API에 대한 링크를 추가했습니다. 링크 내용을 공부한 학생들은 어렵지 않게 완수했습니다.

앞으로 SRI 입학을 계획하고 있는 지원자, 민스크 학교에 입학하지 못한 지원자, 다른 시험 과제를 시작하는 지원자가 이 글을 꼭 읽었으면 좋겠습니다. 보시다시피 그렇게 하는 것이 가능합니다. 당신은 자신을 믿고 저자의 모든 조언을 듣기만 하면 됩니다.

출처 : habr.com