언제부터 정리해야지 정리해야지 하다가. W3CKIG에서 발표를 하게 되어서 꾸역 꾸역 정리했다. -_-;
사실 이미 많은 사람들이 정리해서 내용은 크게 차이는 없는데 내가 좀 흥미롭게 본 부분은 EcmaScript 2015의 goals 중 하나가 타언어가 변환하는데 EcmaScript로 잘 쓸 수 있도록 지원하는 부분이다.
이걸 보면서 EcmaScript가 플랫폼에 가까운 모습으로 가지 않나라는 생각이 든다.
어쨌든 아래는 정리한 내용.
----
이런 공개한 줄 알았는데 안했네.
내가 느끼기에 FE성능은 크게 로딩 성능과 인터랙션 성능으로 구분되는데 어디에 포인트를 주고 할 것 인가에 따라 과정이나 결과물이 완전 다르다. 그래서 개선작업을 할 때 어떤 부분을 포인트를 주고 할 것 인지 설정한 후 진행하는게 좋다.
기본적으로 포인트의 키워드를 보면 로딩 성능의 핵심은 요청 횟수이고 인터랙션 성능의 핵심은 DOM이다.
자세히 들어가면 다양한 테크닉과 도구의 사용법이 있는데 이는 너무 잘 정리된 아티클이나 책에서 많이 나와있어 굳이 설명하자 않아도 많을 것 같다.
두 성능 중 인터랙션 성능은 비교적 전문 FE개발자가 아니면 쉽게 접근하기 힘든 부분인데 이 부분을 잘 정리한 글이 있어서 공유한다. 이 아티클은 모바일웹의 인터랙션 성능을 튜닝하고 싶다면 반드시 한번쯤 따라해보면 갑자기 고수가 되는 경험을 하게 될 정도로 잘정리되어 있다.
https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/pub
가끔 특정 분야의 경험이 다른 분야에서 재인(recongnition)이 되는 순간들이 종종있다. 그럴 때마다 나름 통찰을 얻게 되는데 이러한 경험을 최근에 한 적이 있어 정리를 하면 좋을 것 같아 정리를 한다.
요즘 사용자 경험 스케치[링크]라는 책을 보고 있는데 여기서는 빠르게 스케치를 하여 괜찮은 스케치들을 프로토타이핑 해보고 사용자 경험을 구체화하는 것이 괜찮은 방법이라고 조언한다.
스케치/프로토타이핑의 장점은 여러가지가 있겠지만, 내가 생각하는 장점은 쉽고 빠르게 만들고, 편히 버릴 수 있는 것이다. 또한 다른 시각에서 보는게 가능하다. 이는 한참 만들고 삽집하는 비용을 줄일 수 있다.
내 경험한 바로는 처음에 스케치나 프로토타이핑의 퀄리티를 보고 웃기기도 하고 효용성에 대해 의심했는데 생각보다 얻는게 있다. 작년에 우연히 Design Thinking 수업을 청강할 일이 있었는데 이 강의에는 프로토타이핑을 role play로 했다. 프로토타이핑이라고 해서 뭔가 만들 줄 알았는데 그게 아니라 내가 만들 도구가 있다고 생각하고 사용하는 상황을 만들어 연기를 하는 것이다. 물론 어색하지만, 시각의 변화를 통해 아무것도 없이 연기만 해도 그 동안 활동을 통해 얻지 못한 아이디어들이 발견되어 신선했다. (나는 대본을 만들고 했는데 대본없이 하는 방법도 좋다고 김창준님이 조언을 줬다. 비록 해보진 않았지만 더 번뜩이는 아이디어가 많을 것 같다.)
이와 같은 느낌을 개발하면서 느꼈다. 공통 기능을 만들어 제공하는 일이 많은데 초반에는 어떻게 만들지 interface 디자인한 후 바로 개발했다. 그러다 보면 만드는 중간이나 만들고 나서 개선하거나 문제가 생기는 상황이 많았다. 그래서 추가한 방법이 interface 디자인을 하고 코드를 사용하는 상황을 만들어 내가 사용자가 되어 코드를 작성하는 것 이다. 이렇게 하면 생각하지 못했던 상황들이 종종 발견되고 리뷰, 조언을 들을 때도 상황이 있기 때문에 좀 더 의미있는 대화가 많아진다. 이때 가끔 동작하는 코드를 만들기도 하지만 동작하지 않아도 도움이 많이 된다. 또한, 이런 코드는 테스트 코드가 되어 도움을 준다.
개인적으로 뭔가를 구체적으로 만들기 전에 위와 같이 가볍게 프로토타입핑을 해보는 것을 다양하게 활용해봐야겠다.
