IT/모바일
제공 : 한빛 네트워크
저자 : Ariya Hidayat
역자 : 조석규
원문 : End-to-End JavaScript Quality Analysis
단일 페이지 웹 애플리케이션의 대두는 프론트 앤드 개발자들이 네트워크 전송 최적화 뿐만 아니라 화면이 그려지는 성능에도 신경을 써야 한다는 것을 의미한다. 자바스크립트로 쓰여진 애플리케이션에서, 언어 자체의 도구는 개발 단계에서 필요하게 되는 풍부하고 정렬된 성능 계측법에 대한 요구에 부응하지 못했다. 다행히도, 브라우저 자체가 이런 계측법에 대한 네이티브 지원을 해 주기 전에 쓸 만한 몇 가지 새로운 도구들이 나타났다.
코드 커버리지
전체적인 단일 페이지 애플리케이션의 성능을 결정짓는 한 가지 중요한 것은 애플리케이션 코드의 계측이다. 가장 명백한 유스케이스는 코드 커버리지를 분석하는 것이다. 특히 유닛 테스트와 기능 테스트를 돌릴 때는 더욱 더 그렇다. 테스트 과정에서 실행되지 않은 코드는 일어날 기회만 노리는 사고와 같다. 코드 커버리지가 100%가 되는 것은 말이 안 되지만, 커버리지 데이터가 전혀 없는 것은 확신을 줄 수 없다. 최근에는 Istanbul과 Blanket.js 같은 사용하기 쉬운 커버리지 툴이 널리 사용되고 Jasmine, Mocha, Karma나 그 이외의 유명한 테스트 프레임워크와 잘 연동된다.
복잡성
계측된 코드는 실행시간 확장 같은 다른 형태의 분석을 위해 활용될 수 있다. 성능은 종종 경과시간으로 계측된다. 예를 들어 어떤 작업을 수행하는데 시간이 얼마나 걸렸나 하는 식이다. 이 스톱와치 접근법은 절반 정도 쓸모 있다. 예를 들어, 10개의 연락처를 10ms 안에 주소록에서 정렬하는 성능 테스트는 주소록의 복잡성에 대해서는 알려주지 않는다. 100개의 연락처에는 어떻게 대응할 것인가? 1000개는? 애플리케이션 코드의 복잡성을 추정하기 위한 공식적인 분석이 항상 쓸모있지는 않기 때문에 우회책으로 실증적인 실행시간 복잡성 추정이 이루어진다. 이 예제에서 정렬 구현의 특정 부분(아마 "두 개의 항목을 교환"하는 기능)을 계측하고 감시하는 것으로 수행될 수 있다.
자바스크립트 애플리케이션이 더욱 복잡해지고 있기 때문에, 코드를 가능한 읽기 편하고 이해하기 편하게 유지하기 위한 단계가 필요해졌다. JSComplexity 같은 도구를 사용해서 정적 분석단계에서 코드 복잡성 계측이 가능하다. 거기다, 모든 기능의 시간에 대한 McCabe의 복잡도와 Halsted 복잡도를 추적 가능하다. 이는 우연히 복잡도를 증가시키는 코드 변경이 추가되는 것을 방지해준다. 간단한 몇 단계만 거치면 애플리케이션 대시보드나 지속적 통합 패널에서 이 복잡성 계측을 Plato를 이용하여 시각화할 수 있다.
방어적 작업 흐름
최적화된 애플리케이션 개발 흐름은 애플리케이션 성능을 나중에 고려할 것으로 취급하지 않는다. 성능은 사양이고, 그러므로 작업 흐름의 일부로 통합되어 계측되어야 한다. 여기서 다층 방어 접근이 많은 도움이 될 수 있다. 심지어 QA팀이 일련의 철저하고 집중적인 테스트를 수행할 수 있다고 해도, 간단한 스모크 테스트(아마도 명령행에서 PhantomJS따위를 통해 자동화 할 수 있는)는 가능한 빠른 시점에 실수를 발견할 수 있게 해 준다. 결국 주소록에서 정렬 기능이 갑작스레 참을 수 없을 만큼 느려지는지 알기 위해 망치질을 했던 목적이 뭐겠는가?
방어적 작업흐름은 개발자의 기초적인 도구에서 시작될 수 있다. 코드 편집기/IDE, 버전 관리 도구. 이상적으로, 어떤 프로그래머의 편집기든지 사용자에게 간단한 문법 검사부터 좀 더 심각한 문제, 예를 들어 전역 변수 누수 같은 것까지 문제가 될 소지가 있는지 알려줘야 한다. Git 같은 요즘의 버전 관리 도구는 변경이 반영되기 전에 특정 스크립트를 실행해주는 소위 커밋전처리기 개념을 지원한다. 만일 스크립트가 어떤 테스트를 수행하다가 에러가 발생되면, 반영되지 않는다. 이 사전 조치는 나쁜 코드가 코드 저장소에 숨어드는 것을 방지해준다.
복잡한 애플리케이션은 완전히 다른 개발 전략을 요구한다. 이런 새로운 자바스크립트 툴들을 사용하기 위해 공을 들이는 것을 팀에게 정당화 하는 것은 상대적으로 쉬울 것이다. 왜냐하면 자동화된 성능 측정의 장점는 너무 확연해서, 한 명의 개발자가 큰 팀으로 성장하는 것과 같기 때문이다.
저자 : Ariya Hidayat
역자 : 조석규
원문 : End-to-End JavaScript Quality Analysis
단일 페이지 웹 애플리케이션의 대두는 프론트 앤드 개발자들이 네트워크 전송 최적화 뿐만 아니라 화면이 그려지는 성능에도 신경을 써야 한다는 것을 의미한다. 자바스크립트로 쓰여진 애플리케이션에서, 언어 자체의 도구는 개발 단계에서 필요하게 되는 풍부하고 정렬된 성능 계측법에 대한 요구에 부응하지 못했다. 다행히도, 브라우저 자체가 이런 계측법에 대한 네이티브 지원을 해 주기 전에 쓸 만한 몇 가지 새로운 도구들이 나타났다.
코드 커버리지
전체적인 단일 페이지 애플리케이션의 성능을 결정짓는 한 가지 중요한 것은 애플리케이션 코드의 계측이다. 가장 명백한 유스케이스는 코드 커버리지를 분석하는 것이다. 특히 유닛 테스트와 기능 테스트를 돌릴 때는 더욱 더 그렇다. 테스트 과정에서 실행되지 않은 코드는 일어날 기회만 노리는 사고와 같다. 코드 커버리지가 100%가 되는 것은 말이 안 되지만, 커버리지 데이터가 전혀 없는 것은 확신을 줄 수 없다. 최근에는 Istanbul과 Blanket.js 같은 사용하기 쉬운 커버리지 툴이 널리 사용되고 Jasmine, Mocha, Karma나 그 이외의 유명한 테스트 프레임워크와 잘 연동된다.
복잡성
계측된 코드는 실행시간 확장 같은 다른 형태의 분석을 위해 활용될 수 있다. 성능은 종종 경과시간으로 계측된다. 예를 들어 어떤 작업을 수행하는데 시간이 얼마나 걸렸나 하는 식이다. 이 스톱와치 접근법은 절반 정도 쓸모 있다. 예를 들어, 10개의 연락처를 10ms 안에 주소록에서 정렬하는 성능 테스트는 주소록의 복잡성에 대해서는 알려주지 않는다. 100개의 연락처에는 어떻게 대응할 것인가? 1000개는? 애플리케이션 코드의 복잡성을 추정하기 위한 공식적인 분석이 항상 쓸모있지는 않기 때문에 우회책으로 실증적인 실행시간 복잡성 추정이 이루어진다. 이 예제에서 정렬 구현의 특정 부분(아마 "두 개의 항목을 교환"하는 기능)을 계측하고 감시하는 것으로 수행될 수 있다.
자바스크립트 애플리케이션이 더욱 복잡해지고 있기 때문에, 코드를 가능한 읽기 편하고 이해하기 편하게 유지하기 위한 단계가 필요해졌다. JSComplexity 같은 도구를 사용해서 정적 분석단계에서 코드 복잡성 계측이 가능하다. 거기다, 모든 기능의 시간에 대한 McCabe의 복잡도와 Halsted 복잡도를 추적 가능하다. 이는 우연히 복잡도를 증가시키는 코드 변경이 추가되는 것을 방지해준다. 간단한 몇 단계만 거치면 애플리케이션 대시보드나 지속적 통합 패널에서 이 복잡성 계측을 Plato를 이용하여 시각화할 수 있다.
방어적 작업 흐름
최적화된 애플리케이션 개발 흐름은 애플리케이션 성능을 나중에 고려할 것으로 취급하지 않는다. 성능은 사양이고, 그러므로 작업 흐름의 일부로 통합되어 계측되어야 한다. 여기서 다층 방어 접근이 많은 도움이 될 수 있다. 심지어 QA팀이 일련의 철저하고 집중적인 테스트를 수행할 수 있다고 해도, 간단한 스모크 테스트(아마도 명령행에서 PhantomJS따위를 통해 자동화 할 수 있는)는 가능한 빠른 시점에 실수를 발견할 수 있게 해 준다. 결국 주소록에서 정렬 기능이 갑작스레 참을 수 없을 만큼 느려지는지 알기 위해 망치질을 했던 목적이 뭐겠는가?
방어적 작업흐름은 개발자의 기초적인 도구에서 시작될 수 있다. 코드 편집기/IDE, 버전 관리 도구. 이상적으로, 어떤 프로그래머의 편집기든지 사용자에게 간단한 문법 검사부터 좀 더 심각한 문제, 예를 들어 전역 변수 누수 같은 것까지 문제가 될 소지가 있는지 알려줘야 한다. Git 같은 요즘의 버전 관리 도구는 변경이 반영되기 전에 특정 스크립트를 실행해주는 소위 커밋전처리기 개념을 지원한다. 만일 스크립트가 어떤 테스트를 수행하다가 에러가 발생되면, 반영되지 않는다. 이 사전 조치는 나쁜 코드가 코드 저장소에 숨어드는 것을 방지해준다.
복잡한 애플리케이션은 완전히 다른 개발 전략을 요구한다. 이런 새로운 자바스크립트 툴들을 사용하기 위해 공을 들이는 것을 팀에게 정당화 하는 것은 상대적으로 쉬울 것이다. 왜냐하면 자동화된 성능 측정의 장점는 너무 확연해서, 한 명의 개발자가 큰 팀으로 성장하는 것과 같기 때문이다.
TAG :
이전 글 : PHP를 이용한 앱 엔진에서의 비동기 처리
최신 콘텐츠