이번 글에서는 Frontend 개발 시 Health Check 개선 방법에 대해 살펴보도록 하겠습니다. API 헬스 체크 방법에 대해서는 이전 글에서 살펴본 적이 있으니 아래 글을 참고하시길 바랍니다.
모든 사용자 스토리를 구축했으며 앱이 작동합니다. 이제 완료한 대로 제출할 준비가 되었으므로 인생을 계속 진행할 수 있습니다. 하지만 모든 일이 그렇게 만만하진 않습니다 ^^;
먼저 코드에 상태 확인을 제공해야 합니다. 전문 가수는 마이크와 스피커를 모두 확인하기 전에는 노래를 시작하지 않습니다. 프런트엔드, 백엔드 및 그 사이의 모든 것을 확인할 때까지 배포해서는 안 됩니다.
참을성이 없는 사람에게도 코딩은 인내심을 요구하곤 합니다. 개발자가 되면 적어도 두 번 생각하고, 코드가 작동할 때까지 질문하고, 성공을 축하하기 전에 잠시 기다리는 법을 배워야 합니다.
좋은 제품은 결코 만들어지지 않기 때문에 반복이 핵심입니다. 핵심은 당신이 자랑스러워하는 버전을 반복하는 것입니다. 라이브 준비가 된 버전이 아닙니다. 따라서 라이브로 전환하기 전에 아래의 체크리스트를 꼭 확인하는 습관을 들이는 것이 필요합니다.
반응성 체크
브라우저 창의 크기를 조정할 때 앱은 어떻게 작동합니까? 코드에서 중단점은 어디에 있습니까? 더 큰 문제 없이 모든 크기에 맞도록 충분히 유동적입니까?
끝없이 다양한 화면 크기가 있습니다. 모든 장치를 손이 닿는 곳에 두는 것은 불가능하지만 동작을 에뮬레이션하는 것은 쉽습니다.
Code Review Room에서 시간을 보내면서 많은 사람들이 실제로 모바일 장치에서 앱을 먼저 테스트해야 할 때 데스크탑용 개발에 집중한다는 것을 알게 되었습니다.
브라우저 도구를 사용하면 다양한 화면 크기와 방향에서 디스플레이를 에뮬레이션할 수 있습니다. 그것들을 사용하세요, 그것들은 무료입니다.
Chrome에서는 페이지의 요소를 마우스 오른쪽 버튼으로 클릭하고 “요소 검사”를 선택한 다음 모바일 보기로 이동하고 다른 장치를 에뮬레이션하여 디버그 보기로 이동할 수 있습니다.
엣지 케이스, 앱 상태 등 사전 고려
비어 있음, 오류, 성공, 대기 중, 404 페이지 또는 API 응답을 기다리는 동안 중복된 버튼 클릭 – 앱은 이에 어떻게 반응합니까? 코딩한 이상적인 상황과는 거리가 먼 이러한 상태에 관심이 있습니까? 사용자가 이러한 문제를 만났을 때 도움이 되는 피드백이 있습니까? 이러한 특별한 경우에 대해 테스트해 보셨습니까? 앱에서 듣고 응답합니까, 아니면 모든 말을 합니까?
모든 상태에 대한 설계, 코딩 및 테스트. 사용자 흐름을 확인하면 이러한 쉽게 포기한 지점과 막다른 골목을 제거하는 데 많은 도움이 될 수 있습니다. 일부 사용자와 함께 작업을 테스트하거나 최소한 직접 수행하는 것이 필요합니다.
발생할 수 있는 다양한 시나리오를 상상하여 사용자의 입장이 되어보고 이 앱은 이 사람에게 완전히 새로운 것임을 기억해야 합니다. 잘못된 데이터 입력, 전혀 입력 안 함, 철자 오류 등을 시도해보세요. 상상력을 발휘하여 코드를 해독해보세요. 사용자보다 먼저 수행하는 것이 좋습니다.
성능 최적화
Google PageSpeed Insights는 무엇을 더 잘할 수 있는지 알려주는 데 큰 역할을 합니다. 다른 사람이 코드를 읽고 검토할 수 있도록 하려면 JavaScript 또는 CSS를 축소하지 마세요. 다른 사람이 읽기 어렵게 만들 수 있습니다.
프로덕션의 경우 Grunt와 같은 도구를 사용하여 처리 및 기타 작업 최적화를 수행할 수도 있습니다. PageSpeed와 같은 테스트를 사용하면 성능뿐만 아니라 사용성 문제에 대한 빠른 의견을 얻을 수 있습니다.
테스트 결과는 코드를 개선하는 방법에 대한 준비된 제안을 제공합니다. 다시 말하지만 모두 수락할 필요는 없으며 달성하려는 목표에 맞는 제안을 선택하기만 하면 됩니다.
크로스 브라우저 테스트 (사용 가능한 모든 장치 대상)
우리 중 많은 사람들이 적어도 두 개의 서로 다른 장치(컴퓨터와 스마트폰)에 액세스할 수 있으며 일부는 서로 다른 운영 체제를 이중 부팅하기도 합니다. 브라우저 에뮬레이션에는 결함이 있으므로 가능하면 기본 하드웨어를 사용하세요.
위키 항목이나 지역 날씨를 보여주는 작은 앱이 작동하는지 확인하기 위해 단위 테스트를 작성할 필요가 없습니다. 테스트 기반 개발은 좋은 방법이지만 신입 코더에게는 가장 쉬운 방법이 아니며 짧은 코드 스니펫의 형식을 초과할 수 있습니다.
당신이 알아야 할 것은 같은 방에서 당신 옆에 거대한 테스터 팀이 있더라도 테스트는 프런트 엔드 개발자의 일의 일부라는 것입니다. 티켓을 다른 팀원에게 할당하기 전에 티켓이 작동하는지 확인해야 합니다. 함부로 넘겨 짚거나 가정하지 말고 확인을 직접 해야만 합니다.
코드를 사용하면 작동하거나 작동하지 않습니다. 어쩌면 없을 것입니다. 크로스 브라우저 테스트는 시간이 오래 걸릴 수 있지만 더 효율적으로 만들 수 있는 트릭이 많이 있습니다. 예를 들어 테스트할 때마다 다른 브라우저를 사용해 보십시오.
프로젝트를 반복하면서 테스트하기 때문에 앱 자체를 만드는 동안 다양한 브라우저에서 코드를 여러 번 테스트할 수 있습니다. 그런 다음 최종 버전을 실행하기 전에 빠른 브라우저 상태 확인을 수행하는 것이 훨씬 빠릅니다. 대부분의 문제가 이미 발견되어 수정되었기 때문입니다.
브라우저 개발자 도구 및 확장 기능을 사용하면 프로젝트를 실행하기 전에 접근성 제약 조건을 쉽게 검색할 수도 있습니다. 브라우저 간 테스트를 수행하는 데 도움이 되는 BrowserStack을 사용할 수도 있습니다.
끊임 없는 관심과 집중
HTML의 헤드 섹션을 다시 확인하고 메타 설명, 모바일용으로 설정된 뷰포트, 제목 태그 및 파비콘이 있는지 확인하세요. 설명 및 작성자와 같은 최소한의 기본 메타 태그는 유지해야 합니다. SEO 규칙은 빠르게 변경되지만 유익한 설명은 복잡한 검색 결과 페이지에서 클릭될 가능성을 높일 수 있습니다.
작업 공유에 대해 진지하게 생각한다면 다른 사람들이 쉽게 협업할 수 있도록 하세요. README.md 파일을 간결하고 설명적으로 유지하세요. 대부분의 사람들이 GitHub에서 프로젝트를 보는 방법이므로 저장소에서 이 파일을 생략하면 안됩니다.
CodePen에서 일부 소규모 프로젝트를 코딩하는 경우 설정 섹션으로 이동하여 펜 및 태그에 대한 기본 설명을 추가합니다. 이렇게 하면 다른 사람이 작업을 더 쉽게 발견하고 이해할 수 있습니다.
자산과 라이브러리를 적절하게 가져왔는지 확인하세요. CodePen에서 다른 서버로 프로젝트를 이동하려는 경우 펜에서 사용한 외부 라이브러리, 프레임워크 및 스타일시트가 포함되어 있는지 확인해야 합니다.
Github용 사본만 원하고 소규모 프로젝트인 경우 간단히 펜을 gist로 내보낼 수 있습니다. 이렇게 하려면 Editor View의 오른쪽 하단 모서리에 있는 내보내기 버튼을 사용합니다.
코드 최적화
건조한 상태를 유지해야 하며, 완료되면 코드를 다시 한 번 살펴봐야 합니다. 반복하는 스니펫이 있을 수 있으며 하나의 스마트 기능으로 대체될 수 있습니다.
코드를 다시 한 번 분석하고 무엇이 더 잘 작성될 수 있는지 살펴보십시오. 코딩을 많이 할수록 DRY에서 더 현명해집니다. 일정 시간이 지난 후 자신의 코드로 돌아와서 리팩터링하는 것이 좋은 학습 코드 연습이라고 합니다.
모든 콘솔 로그는 생성 중 디버깅에 유용하지만 프로덕션 코드에는 환영받지 못합니다. 팀원 모두가 같은 언어를 사용하지 않는 한 코드를 읽는 다른 사람을 위해 간결하고 명확하게 주석을 작성하고 가급적이면 영어로 작성하는 것이 좋습니다.
콘솔 오류가 없는지, 모든 자산이 제대로 로드되는지 확인하십시오(브라우저의 개발자 도구에서 네트워크 탭 확인). JavaScript, HTML 및 CSS용 코드 유효성 검사기를 사용할 수 있습니다. PageSpeed와 마찬가지로 핵심은 최적화할 가치가 있는 것이 무엇인지 이해하는 것입니다.