Rev. 2.73

아! 2015년에는 하나도 포스팅한게 없군요. 그래서 땜빵용으로 회고록을 몰래 끼워넣기로 했습니다. 2015년은 변화가 많았던 해였습니다. 모비즌2 프로젝트에서 나와 새로운 프로젝트를 제안하고 비전을 현실로 만드는 작업을 수행하고 있습니다. 알서포트에 재입사 한지도 벌써 3년째군요. 새로운 프로젝트에 걸맞은 새로운 기술을들 공부하다 보니 자바스크립트도 아주 많이 변하고 발전했습니다. 특히 문법적으로 많은 변화를 가져온 ES6을 접하면서 문맹이 된듯한 기분이 들었을 정도입니다.

API 문서 작성 - JSDoc3

모비즌2 프로젝트에서 발을 빼기 위해(?) JSDoc3를 이용해서 API 문서화 프로젝트를 별도로 진행했습니다. JSDoc은 JavaDoc과 비슷한 것으로 코드에 표현한 주석을 이용하여 API 문서를 자동으로 생성해 주는 도구입니다. 함수의 파라미터 설명은 기본이고 클래스 간 관계 표현이나 이벤트 리스너와 트리거의 링크를 제공하는 등 작성한 코드를 협업자가 별 어려움 없이 이해하고 사용할 수 있도록 할 수 있습니다. 느낀 점들:

  • 총 6만 라인이었던 소스코드가 8만 라인 정도로 늘어났습니다. 약 20%~30% 정도 늘어납니다.
  • 문서를 작성하면서 구조적으로 관계가 더욱 명확해지는 것을 발견했습니다.
  • LINT에서는 발견하기 어려운 구조적 문제점 발견하고 개선할 기회가 됩니다.
  • 템플릿을 이용하여 문서를 뽑아내는 데까지 3개월 정도 걸렸습니다.
  • 함수에 매개변수를 설명하는 주석 정도만 충실히 달았어도 이렇게 오래걸리지는 않았을 것이라는 반성을 했습니다.
  • 템플릿은 davidshimjs님의 jaguarjs-jsdoc이 예쁩니다.

웹 UI 테스트 자동화 - Nightwatch.js

웹 프로젝트의 UI 테스트 자동화를 도입하기 위해 Headless browser 방식의 여러 가지 방법을 검토해 보았는데, 가장 와 닫는 것이 Nightwatch.js이었습니다. 이 녀석은 End-to-End 테스트가 가능한 녀석으로, Node.js로 작성되었으며 Selenium WebDriver API를 이용하여 DOM 요소에 직접 접근하는 방식으로 테스트 코드를 작성할 수 있습니다. 느낀 점:

  • 테스트는 필수입니다. 총 작업 시간의 최소 3할 이상을 테스트하는 것에 소비해야 합니다.
  • 테스트를 자동화해 놓으면 테스트에 들어가는 시간과 노력의 비용을 낮출 수 있습니다.
  • 유닛 테스트는 프로젝트 빌드 직전인 시점에, UI 테스트는 빌드 이후에 자동으로 수행하도록 grunt나 gulp을 이용해서 구성하는 게 좋습니다.
  • 모든 기능을 사람이 직접 쓰는 것처럼 테스트 해 주니, 주위 사람들이 신기해합니다.
  • 동적 테스트입니다. 정적 테스트보다 변수가 많고 기능이 추가되거나 변경되었을 때 테스트 코드 유지/보수에 추가적인 리소스를 투자해야 합니다.
  • 브라우저별로 동일한 테스트를 반복하게 할 경우, 상당히 오래 걸립니다. 별도의 테스트 머신에서 돌리거나 퇴근 직전에 돌리고 가는 것이 좋겠다는 생각이 들었습니다.
  • UI에 웬 스트레스 테스트냐 하는 분도 있겠지만, 가능하긴 합니다.

웹기반 데스크탑 애플리케이션 개발 - Electron

NW.jsElectron 둘 중에 Electron이 뭔가 더 깔끔한 것 같다는 생각이 들어서 선택했을 뿐입니다. GitHub에서 만들었고, Atom editor가 이 녀석을 이용해서 만들어졌고요. 새롭게 시작하는 프로젝트의 데스크탑 애플리케이션이 필요한 부분에 쓰이고 있습니다. 구글 크롬 브라우저와 Node.js를 포함하고 있어서 하나의 브라우저에서 작동하는 것에만 집중할 수 있습니다. 이 밖에도:

  • 하이브리드하게 개발하는 모든 장점을 안고 있습니다. 특히, 크로스-플랫폼
  • 프로세스를 관리해야 하고 IPC 스타일 통신에 익숙해져야 합니다.
  • 크로스-브라우징을 하지 않는 대신에 OS별 특징들을 관리해야 합니다.
  • React와 환상의 궁합입니다. 요런 컴포넌트가 마구 쏟아진다고 생각해 보세요.
  • 네이티브 require를 WebView에서 사용할 수 있습니다.
  • ES6과 같은 Transpile이 필요한 코드를 더욱 마음껏 사용할 수 있습니다.

UI 라이브러리 - React

React는 Facebook 개발자들이 만든 UI 라이브러리입니다. 복잡하고 귀찮은 MVC 개념 따위 과감하게 던져버리고 로직에만 집중할 수 있게 한 새로운 개념 덩어리라고 볼 수 있습니다. 지금까지 OO스럽게 프로그램하려고 상당히 노력해왔는데 그 목마름을 React에서 찾은듯한 느낌입니다. React를 학습하면서 메모했던 내용을 공유합니다.

  • React의 컴포넌트는 소유관계이다. 부모는 자식 컴포넌트의 값이나 상태 등을 변경할 수 있지만, 자식은 부모가 가진 모든 것에 접근할 수 없다.
  • 심지어 자식은 자신이 가진 값(props)도 변경할 수 없으며, 오직 부모에 의해 변경되거나 할당 받을 수 있다.
  • HTML 코드를 자바스크립트로 직접 만들어 낼 필요가 없다. state가 변하면(setState) 항상 render가 호출되기 때문에 그때 처리하면 된다.
  • DOM event를 직접 바인딩 할 필요 없다. render 메소드 안에서 컴포넌트 메소드에 직접 매핑할 수 있기 때문이다.
  • render는 무조건 하나의 객체(요소?)만을 리턴해야 한다.
  • show/hide, active/disable 등과 같은 상태성 코드를 작성할 필요가 없다. 만약 이와 같은 코드가 존재한다면 state와 render의 상호작용으로 작동되도록 다시 작성하는 것을 고민해야 한다.
  • 마찬가지로 dom-storage에 의존할 필요도 없다. 만약 dom-storage를 이용하는 코드가 존재한다면 props와 render의 상호작용으로 작동되도록 다시 작성하는 것을 고민해야 한다.
  • 같은 레벨의 자식들끼리 소통할 수 없으며 오직 부모에 의해 자식들의 행동이 결정되어야 한다.
  • state는 자신이 스스로 값을 변경할 수 있지만, 부모에서 refs 속성으로 접근하여 변경할 수도 있다.
  • Virtual DOM을 이용하기 때문에 DOM 선택자를 이용하는 비용을 줄일 수 있다.
  • JSX와 궁합이 아주 잘 맞지만, 별도의 Transpiler를 필요로 한다.
  • ES6과의 호환성이 좋다. 특히 ES7의 Decorator와 잘 어울린다.
  • state를 너무 남용하면 불필요한 렌더링이 자주 발생하기 때문에 컴포넌트의 값을 props와 state중 어디에 담을 것인지 신중히 정하자.
  • 7가지 생명주기를 가진 컴포넌트 메소드들의 명세를 항상 숙지하고 있어야 한다.
  • React 컴포넌트 클래스는 우리가 일반적으로 생각하는 자바스크립 클래스와는 크게 다르며, 모든 메소드는 private으로 작동한다. statics 속성을 이용하여 static 메소드를 작성할 수 있지만, 인스턴스의 this에는 접근할 수 없다.
  • 그래서 React 컴포넌트의 메소드를 밑줄(_)을 이용하여 private으로 구분해야 할 필요가 없다.
  • 클래스 상속과 유사한 개념으로 mixins 기능을 제공한다. 이것은 단순히 공통 메소드를 공유하는 목적일 뿐이다.

변화

개인적인 변화로는 가을에 결혼한 것인데, 덕이 부족하여 생각보다 쉽지 않은 변화된 환경에 적응을 잘하지 못하고 있습니다. 이런저런 변화에 대처하느라 자원를 효율적이지 못하게 소모해 버린 정신없는 한 해였던 것 같습니다.

2016년에는 일단 정신줄부터 다잡고 진행 중인 프로젝트 성공적으로 마무리 지을 수 있도록 노력하고, 개인적으로는 Cordova를 이용한 하이브리드 모바일 앱 개발에 도전해 보고 싶습니다.

Comments

Got something to add? You can just leave a comment.

Your Reaction Time!

captcha

avatar