<< Previous | Home | Next >>

AngularJS 사용하면서 정리한 것들

작년부터 AngularJS 도입해 사용하면서 도움이 될만한게 뭐있나 고민하다가 초기에 알아두면 좋을법한 내용을 정리해 보려고 합니다. MVW에 대한 고민하면서 코딩을 했는지, 내가 AngularJS를 문제없게 코딩했는지 등에 대한 불안을 어느정도 회피해 줄 수 있는 생각들을 공유합니다.

AngularJS 기반 MVW 이해하기



MV* 패턴 적용의 목적은 프레젠테이션과 도메인을 격리시키는 것이다. 분리의 장점은 아래와 같다.
  • 프리젠테이션 로직과 도메인 로직이 분리되면 이해도가 올라간다.
  • 같은 베이스 프로그램을 중복코드 없이 여러 프리젠테이션에 대응할 수 있다.
  • 사용자 인터페이스는 테스트가 어렵기 때문에 그것을 분리하는 것은 테스트 가능한 로직을 유지할 수 있다.
  • 스크립트에 대한 API나 서비스로 구체화하기 위한 API를 쉽게 추가 할 수 있다.(다른 프리젠테이션 영역에서도 볼 수 있는)
  • 프레젠테이션 부분의 코드는 도메인 부분의 코드와 다른 지식과 기술이 필요하다.
1. Model 역할
데이터 관리, 서버측과 통신 등의 역할을 하며 서비스와 데이터로 나뉘어 지는데 데이터와 관련된 일반적인 작업은 Service, Factory에 위임하는 것이 코드가 깔끔해진다.
  • Service : JavaScript 클래스. 런타임은 new로 인스턴스가 생성된 싱글톤으로 취급된다. 다른 개발에서 만든 JavaScript 클래스 등을 전용할 수 있기 때문에 유연성, 사용 용이성이 좋다.
  • Factory : 실체로는 function(함수 참조). 특성으로는 내부 변수를 사용하면 함수 범위에 숨겨지며 private처럼 취급 된다.(Controller에서 참조 불가).
2. View 역할
레이아웃(HTML)과 프리젠테이션 로직으로 나눌 수 있는데 내부 로직이 복잡해지면 Directive나 Filter를 사용하면 된다. 그런데 코드는 깔끔해지나 제3자가 볼 때 이해도가 확실히 떨어진다는 단점을 가지고 있다.

3. Controller 역할
주로 이벤트 핸들링과 Data Binding에 집중하는 역할을 한다.
  • 이벤트 핸들링(Event -> Model): 이벤트를 Model에 전달해 값 변경 등을 실현한다. 이것은 ng-model에서 직접 실현하거나 ng-click 등으로부터 Model의 function을 부르는 형태로 구현될 수 있어 다양한 방법들이 존재한다.
  • Data Binding(Model -> View): 모델의 변경을 View에 반영한다. 이것은 Angular.js는 의식할 필요가 없다 ($watch 통해 Model의 변경이 감시되고 변경되면 자동으로 업데이트 됨).
다음부터는 AngularJS를 잘 이해하지 못하고 코딩을 하면 돌아는 가는데 문제가 될 여자가 많은 코드를 생산할 수 있어서 이를 도구를 통해 미연에 조금이나마 방지할 수 있는 방법들을 설명한다.

AngularJS Hint 사용하기

AngularJS를 사용하여 개발한 응용 프로그램에 통합 실행하면 오류가 발생 주거나 모범 사례를 준수하는지 여부를 확인하여 준다. 그리고 현재의 angular-hint 프로젝트 상태는 WIP(Work In Progress)라고 써 있는 것으로 보아 아직 개발중인 것 같다.

1. angular-hint 사용 방법
angular-hint를 사용하려면 github에서 소스를 가져 와서 빌드하거나 npm을 통해 가능하다.
$ npm install angular-hint

node_modules/angular-hint/dist/hint.js라는 파일을 찾아서 해당 프로젝트에 카피해서 사용하면 된다. 사용 방법은 아래와 같다.
angular.js 뒤에 hint.js를 읽어들이게 하고
<script type="text/javascript" src="resources/angularjs/hint.js"></script>
ng-app을 지정하는 부분에 ng-hint를 추가하면 된다.
<html lang="ko" data-ng-app="App" ng-hint>

2. angular-hint 표시되는 메세지 정보
1번에서 설명한대로 한 다음 WAS를 구동해서 console 로그를 보면 오류 등의 정보를 확인할 수 있다.


여기서 알려주는 내용은 Modules, Controllers, Directives, DOM, Events, Interpolation의 6 종류의 카테고리로 제공하고 메세지 수준은 오류, 경고 및 제안 등 세가지로 분류되어 표시된다.

AngularJS 성능 관련

AngularJS는 Batarang이란 편리한 도구(Chrome Developer Tools 확장 기능)가 존재한다. 이 도구는 AngularJS의 디버깅이나 성능 메트릭스 등에 참고할만한 정보를 보여줘 개발시에 참고하면 좋다. 그리고 시작은 AngularJS 탭의 Enable 체크만 하면 된다.


AngularJS는 양방향 데이터 바인딩의 구조가 매우 유용하지만 성능에 영향을 줄 수 있는 이슈가 나올 수 있어 성능상의 병목을 짚어보는 것은 중요하지만 먼저 이 구조를 이해하는게 더 중요할 수 있다.

1. 데이터 바인딩 구조 이해
데이터 바인딩 메커니즘의 실현 방법에는 여러 가지 방법이 있지만, 여기서는 두가지정도 언급하고 만다. 첫번째의 경우는 Knockout.js의 경우로 데이터의 값이 변경될 때 이벤트 리스너에서 View에 통지하는 방식을 취하고 있고, 두번째인 AngularJS는 dirty-checking라는 방식으로 구현되어 있는데, 이것은 바인딩 되는 모든 변수에 대해 특정 시간에 이전 값과 현재 값을 비교하고 값에 변화가 있으면 DOM을 갱신하는 구조이다.

이를 순차적으로 기술해 보면
- HTML을 분석하여 지시문(directive)을 컴파일할 때 바인딩되는 변수를 $scope.$watch()로 등록한다.
- $rootScope 자식들의 scope를 차례로 검색해, watch에 등록된 모든 변수의 변경 검사를 수행한다. 이 과정을 $digest 루프라고 부르고, 아래와 같은 타이밍에서 실행된다.(정기적인 폴링은하지 않습니다)
  • $scope.$apply()를 부를 때.
  • DOM 이벤트 (onChange, onClick 등)가 발생한 후.
  • $http와 $resource에서 응답이 돌아왔을 경우.
  • $location에서 URL을 변경한 후.
  • $timeout이벤트가 발생한 후.
- 변경 검사가 완료되면 변경된 부분의 DOM을 다시 시작한다.

2. 개선 포인트는 어떻게
- 불필요한 $scope 변수나 $scope.$apply()를 하지 않는다.
$digest 루프에서는 watch하고 있는 변수의 수와 변수의 비교 처리 시간이 성능에 크게 영향을 준다. 그래서 watch 변수의 수는 가능한 적게, 객체의 비교 처리는 가능한 한 가볍게하는 것이 좋다. watch 변수의 수 기준은 2000개 이하, 비교 처리 시간의 기준은 25μsec라고 알려져 있다.(여기)
Batarang을 사용하면 $scope의 트리 구조를 시각화되므로 watch하고 있는 변수의 수를 확인할 수 있다.

- $watch에서 무겁고 느린 처리를 만들지 말자.
그러면 응용 프로그램 전체가 느려집니다. JavaScript가 단일 스레드인 특성상 $digest 루프는 단일 스레드에서 처리된다.

- 예기치 않는 동작을 방지하도록 될 수 있으면 angularjs 모듈들을 사용하자.
  • setTimeout 대신 $timeout을 사용.(angular의 digest와 apply주기에 따라 setTimeout에서 수행 한 작업이 angular에 반영되지 않는 경우가 있기 때문에, 아래도 비슷한 이유이다.)
  • window 대신 $window를 사용.
  • document 대신 $document를 사용.
  • $.ajax 대신 $http를 사용.

- 다른 콘트롤러와 통신할 때 주의하자.
$emit, $broadcast, $watch를 사용하게 되는데, 일반적으로 $watch는 $emit이나 $broadcast 같은 event 방식에 비해서 성능 소모가 많다고 알려져 있다.(여기)
$rootScope.$broadcast의 경우, AngularJS가 관리하는 모든 scope에 방문해야 하기 때문에 성능 문제가 있을 수 있다. 기본적으로 통신은 줄이데 공유 데이터는 서비스에서 처리하도록 하자.

- ngShow/ngHide/ngIf를 적정한데 사용하자.
ngShow/ngHide는 CSS를 통해 표시를 전환하고 ngIf는 DOM의 추가나 삭제를 할 수 있게 되어 있다. 그래서 ngShow/ngHide는 ngRepeat와 같이 쓸경우 리스트가 많게 되면 초기 로드가 느릴수 있고 화면 전환(보이고/안보이고)은 빠르게 되고 반대로 ngIf는 초기 로드는 빠르지만 화면 전환이 느린 특성이 있으니 잘 활용하자.

- 기타
  • ng-cloak : 페이지 로딩 중 등에서, angular 처리되기 전에 마크업이 보여 버리는 것을 방지한다.
  • 변수나 메서드 이름에 $접두사를 사용하지 않는다. 이 접두사는 AngularJS에서 예약되어 있다.
  • $scope를 더럽 히지 말자. 템플릿에서 사용하는 메소드나 변수만 추가하자.
  • 전역 변수를 사용하지 말자. 의존성 주입을 사용하여 모든 종속성을 해결하자.
  • 콜백 대신 promise($q)를 사용한다. 그러면 코드는 더 우아하고 깨끗한되고 콜백 지옥에서 벗어나게 해준다.
  • 가능할 땐 $http 대신 $resource를 사용. 높은 수준의 추상화는 번잡한 작업으로부터 해방시켜 준다.
  • 될수 있으면 angularjs 내장 함수들을 사용하자. angular.element, angular.forEach 등.

[참조 사이트]

Vim에 대해 점진적으로 학습하기

본 포스트는 "Learn Vim Progressively"라는 아티클을 번역한 것으로 Vim에 대해서 모르시는 분들이나 되새김질을 하고 싶은 분들에게 좋은 글이 될 거 같아 정리해 보았습니다.



TL;DR: 여러분은 vim(인류 역사상 가장 많이 알려져 있는 텍스트 에디터)을 가능한 한 빨리 습득하고 싶을 것이다. 그래서 여기에 그렇게 될 수 있는 방법을 소개한다. 그리고 살아남을 수 있는 최소한의 내용으로 학습을 시작하고 그 뒤에 천천히 트릭 부분을 추가하겠다.

Vim - 60억 달러 텍스트 에디터
더 좋고, 더 강하고, 그리고 더 빠른
vim을 배워라 그러면 당신이 배우는 마지막 텍스트 에디터가 될 것이다. 내가 알고 있는 더 나은 텍스트 에디터는 없다. 배우기는 어렵지만, 사용하기에는 더 없이 좋다.

Vim을 네단계로 배우는 것을 제안한다:

1. 생존하기.
2. 편안함 느끼기.
3. 더 좋고, 더 강하고, 그리고 더 빠름 느끼기.
4. Vim의 막강한 힘 사용하기.

이 여정의 끝에서 당신은 Vim에 대해 슈퍼 스타가 될 것이다.

그러나 시작하기 전에 경고하나 하겠다. Vim 학습은 처음에는 고통스러울 것이다. 시간이 걸리고 많은 악기를 연주하는 것 같을 것이다. 3일보다 더 적은 노력으로 다른 편집기보다 Vim을 더 효율적으로 사용할 수 있다는 기대는 하지 마라. 현실적으로, 실상은 3일은 커녕 거의 2주는 걸릴 것이다.

1. 첫번째 레벨 - 생존하기


1. Vim 을 설치하고
2. Vim 시작시키고
3. 아무것도 하지 마라! 그냥 읽어라.

일반 편집기에서 키보드를 타이핑하는 것만으로도 원가를 쓰고, 화면에서 읽을 수가 있다. 여기 Vim에서는 그렇지가 않다. Vim은 본래 Normal모드이다. 자! Insert 모드로 가보자. i글자를 타이핑해라.

당신은 약간 더 좋은 느낌을 가질것이다. 이제 당신은 일반적인 에디터처럼 문자를 입력할 수 있다. Normal모드로 되돌아가기 위해서는 ESC키를 누르면 된다.

당신은 Insert 모드와 Normal모드 사이의 전환이 어떻게 하는지를 배웠다. 그리고 지금 당신이 Normal모드에서 살아남기 위해 필요한 커맨드 목록은 아래와 같다:
- i → Insert 모드. ESC를 누르면 Normal모드로 되돌아간다.
- x → 커서의 위치해 있는 문자를 지운다.
- :wq → 저장 후 종료(:w 저장 :q 종료).
- dd → 현재 행 삭제(그리고 복사된다)
- p → 붙여 넣기

추천 :

- hjkl (특히 필수는 아니지만 강력 권장) → 기본적인 커서 이동(← ↓ ↑ →). 
힌트 : j 아래쪽 화살표처럼 보인다. - :help <커맨드><커맨드>에 관한 도움말을 표시한다.
<커맨드>없이 :help를 사용하면 일반적인 help 내용을 볼 수 있다.
단지 5개의 커맨드다. 이것이 시작하기 위해 필요한 전부이다. 이 커맨드의 시작한 뒤 자연스럽게 사용할 수 있다면(하루정도가 되겠지만) 당신은 레벨 2로 이동하면 된다.

하지만 우선 조금 더 Normal모드에 대해 이야기하고자 한다. 일반 에디터에서는 복사를 하는데 Ctrl키(Ctrl-c)를 사용한다. 사실, Ctrl을 눌렀을 때, 그것은 키의 의미를 바꾸는 것이 된다. Normal mode로 Vim을 사용하면 에디터에서 Ctrl키를 계속 누르고 편집하는 것과 같다.

표기에 대한 내용 :
- Ctrl-λ대신에 나는 <C-λ>를 쓸 것이다.
- :로 시작하는 커맨드는 <enter>로 끝나야 한다. 예를 들어, :q 라고 썼다면 :q<enter>를 나타낸다.

2. 레벨 2 - 편안함 느끼기


당신은 생존하기 위해 필요한 커맨드를 알고 있다. 몇 가지 더 커맨드를 학습하자. 내가 제시하는 것은 아래와 같다:

1. Insert 모드의 다양성 :
- a → 커서 뒤에 삽입
- o → 현재 행 다음에 새로운 행 삽입
- O → 현재 줄의 앞에 새로운 행 삽입
- cw → 커서의 위치에서 단어의 끝까지 교체

2. 기본적인 이동
- 0 → 행의 시작 부분으로 이동
- ^ → 행의 공백이 아닌 첫 번째 문자로 이동
- $ → 행의 끝으로 이동
- g_ → 행의 공백이 아닌 끝 문자로 이동

- /pattern → pattern 검색

3. 복사/붙여넣기
- P → 커서 전에 붙여 넣고, p는 커서 뒤에 붙여넣기가 된다는 것을 기억하라.
- yy → 현재 행을 복사. 쉽게 말하면 ddP와 같다.

4. 실행 취소/재실행
- u → 실행 취소
- <C-r> → 재실행

5. 로드/저장/종료/파일(버퍼) 변경
- :e <path/to/file> → 파일 열기
- :w → 파일 저장
- :saveas <path/to/file> → <path/to/file>에 저장
- :x, ZZ 혹은 :wq → 저장 후 종료
- :q! → 저장하지 않고 종료. 또한 숨겨진 버퍼에 변경이 있어도 :qa!는 종료.
- :bn (관련 :bp) → 다음(관련 이전) 파일(버퍼)을 표시.

이들 커맨드 모두를 배우는데 시간이 걸린다. 한번 해보면 다른 편집기에서 할 수 있는 모든 것을 할 수 있을 것이다. 당신은 약간 어색함을 느낄수 있을 수도 있다. 그러나 다음 단계를 따라온다면 그 이유를 알 수 있을 것이다.

3. 레벨 3 - 더 좋고, 더 강하고, 그리고 더 빠름 느끼기


여기까지 온 것에 대해 축하합니다! 지금 우리는 더 재미있는 것을 시작할 수 있다. 레벨 3에서는 이전 vi와 호환되는 커맨드에 대해 이야기할 것이다.

3.1 더 좋은 점
Vim은 사용자의 반복 동작에 대해 어떻게 도움 수 있는지를 살펴 보자:

1. . → (도트)는 마지막 명령을 반복하게 할 것이다.
2. N<커맨드> → 커맨드를 N번 반복한다.

다음은 몇가지 예를 나타낸다. 파일을 열고 타이핑하자 :
- 2dd → 2행을 삭제를 할 것이다.
- 3p → 해당 텍스트를 3번 붙여넣기를 할 것이다.
- 100idesu [ESC] → "desudesudesudesudesudesudesudesudesudesudesudesu
desudesudesudesudesudesudesudesudesudesudesudesudesu
desudesudesudesudesudesudesudesudesudesudesudesudesu
desudesudesudesudesudesudesudesudesudesudesudesudesu
desudesudesudesudesudesudesudesudesudesudesudesudesu
desudesudesudesudesudesudesudesudesudesudesudesudesu
desudesudesudesudesudesudesudesudesudesudesudesudesudesu
desudesudesudesudesudesudesudesudesu"로 100개 desu가 쓰여진다. - . → 방금 전 마지막 명령 "desu" 100개 쓰기가 다시 실행된다. - 3. → 3개의 "desu"를 쓴다.(300개가 아니다.)

3.2 더 강한점
Vim을 사용하여 효율적으로 이동하는 방법을 안다는 것은 매우 중요하다. 이 섹션을 건너 뛰지 마라.

1. NG → N행으로 이동
2. gg → 1G 바로 가기. 파일의 처음으로 이동,
3. G → 마지막 행으로 이동
4. 단어 이동 :
- w → 다음 단어의 시작 부분으로 이동
- e → 낱말의 끝으로 이동합니다.

기본적으로 단어는 문자와 밑줄로 구성되어 있다. WORD는 공백 문자로 구분된 문자 그룹이라고 부르기로 하자.
WORD로 간주하려면 단지 대문자를 사용하자. - W → 다음 WORD의 시작 부분으로 이동 - E → 해당 WORD의 끝으로 이동.

이제부터 매우 효율적인 이동에 대해 설명하자:
- % : (, {, [에 대응하는 곳으로 이동.
- *(관련 : #) : 커서가 위치해 있는 다음 단어(관련 : 이전)로 이동.

저를 믿으세요. 마지막 세 커맨드는 금입니다.

3.3 더 빠른점
vi에서의 이동의 중요성을 기억하라. 여기에는 이유가 있다. 대부분의 커맨드는 다음과 같은 일반적인 형식을 이용하여 사용할 수 있다.
<시작 위치> <명령> <마지막 위치>
예를 들면 : 0y$의 의미는 다음에 기술되어 있다.

- 0 → 이 행의 시작 부분으로 이동
- y → 양크
- $ → 이 행의 끝으로

ye 같은 것을 할 수 있으며, 여기에서 단어의 끝까지를 양크한다. 하지만, y2/foo는 두 번째에 있는 foo까지 양크한다.

하지만, y(양크)뿐만 아니라, d(삭제), v(시각적 선택) gU(대), gu(소문자) 등도 비슷하다.

4. 레벨 4 - Vim의 강력한 힘


앞서 언급한 커맨드를 Vim에서 사용하면 편안함을 느낄것이다. 그러나 다음부턴 킬러 기능들이 소개된다. 이들 기능중의 일부가 내가 Vim을 사용하기 시작한 이유였다.

4.1 현재 행의 이동 : 0 ^ $ g_ f F t T , ;
- 0 → 행의 시작 부분(칼럼 0)으로 이동
- ^ → 행의 첫 글자로 이동
- $ → 행의 마지막 칼럼으로 이동
- g_ → 행의 마지막 문자로 이동
- fa → 행에서 다음 문자 a로 이동. ,(관련 ;)는 다음(관련 : 이전) 발견된 지점까지 이동.
- t, → ,앞으로 이동.
- 3fa → 행에서 3번째로 발견된 a를 찾음.
- FT → F와 t처럼 비슷하지만 반대관계다.


유용한 tip은 : dt""까지 모두 삭제.

4.2 지역 선택 <action>a<object> 또는 <action>i<object>
이 명령은 비주얼 모드에서 연산자 뒤에만​​ 사용할 수가 있다. 그러나 아주 강력하다. 주요 패턴은 다음과 같다.
<action>a<object> and <action>i<object>

액션은 다양한 액션이 될 수 있다. 예를 들어 d(삭제), y(양키), v(비주얼 모드 선택). 그리고 객체는 w 단어, W WORD(확장된 단어) s 문장, p 단락이 될수 있고 아니면. ", ', ), }, ] 같은 자연적인 문자도 될 수 있다.

커서가 (map (+) ("foo")) 의 첫 번째 o에 있다고 가정한다.
- vi"foo를 선택
- va""foo"를 선택
- vi)"foo"를 선택
- va)("foo")를 선택
- v2i)map (+) ("foo")를 선택
- v2a)(map (+) ("foo"))를 선택


4.3 사각형 블록 선택 <C-v>
사각형 블록은 코드의 많은 행을 주석처리하는데 매우 유용하다. 타이핑해보면: 0<C-v> <C-d>I-- [ESC]

- ^ → 행의 공백없는 첫번째 문자로 이동
- <C-v> → 블록 선택 시작
- <C-d> → 아래로 이동 (jjj 와 % 등도 이동항 수 있다)
- I-- [ESC] → 각 라인의 주석처리를 위해 --를 쓴다.


Windows 환경에서는 클립 보드가 비어 있지 않으면 <C-v> 대신 <C-q>를 사용할 수도 있다.

4.4 보완 : <C-n>과 <C-p>
Insert 모드에서는 단어의 시작 부분에 <C-p>를 입력 해 보자. 그러면 마법과 같은 일이...


4.5 매크로: qa는 뭔가 실행해준다. q, @a , @@
qa는 여러분의 액션을 a Register에 기록한다. 그리고 @a는 a 레지스터에 기록된 매크로를 마치 그것을 입력했는것과 같이 재현해준다. @@는 마지막으로 실행된 매크로를 재생하는 단축키이다.
예
숫자 1만 포함한 한 행에서 아래의 것을 타이핑하자:

- qaYp<C-a>q →
  - qa 기록을 시작한다.
  - Yp 행을 복제한다.
  - <C-a> 숫자를 증가시킨다.
  - q 기록 중지한다.
- @a → 1 아래 2를 쓴다
- @@ → 2 아래 3을 쓴다.
- 지금 100@@는 103까지 일련 번호 증기시킨 숫자 리스트를 생성한다.


4.6 비주얼 선택: v, V, <C-v>
<C-v>를 사용한 예를 보았다. 그래서 v와 V이다. 선택 모드가 되면 다음 작업을 수행할 수가 있다:

- J → 모든 행을 조인한다.
- <(관련, >) → 왼쪽으로(관련, 오른쪽으로) 들여 쓰기.
- = → 자동 들여 쓰기


비주얼로 선택한 모든 행의 끝에 무언가를 추가하기:

- <C-v>
- 원하는 행으로 이동하자 (jjj 혹은 <C-d>/pattern 또는 % 등)
- $ 끝으로 이동
- A 텍스트를 작성하고 ESC 누름.


4.7 분할: :split과 vsplit
중요한 명령은 다음과 같으나 :help split으로 찾아보라.
- :split → 분할(:vsplit은 세로 분할) 창을 만듬.
- <C-w><dir> : hjkl이나 혹은 ← ↓ ↑ → 방향으로 분할을 변경
- <C-w>_ (관련 : <C-w>|) : 분할 크기를 확대(관련, vertical split)

- <C-w>+ (관련 : <C-w>-) : 분할 크기를 증가(관련 : shrink)


5. 결론


이것들은 나가 매일 사용하는 명령의 90%이다. 나는 당신이 하루에 하나 혹은 두개 이상의 새로운 커맨드를 학습하지 않도록 권고한다. 2 ~ 3주 후에는 당신의 손이 vim의 파워를 느끼기 시작할 것이다.

Vim의 학습은 단순한의 암기보다 많은 훈련이 더 중요하다. 운좋게도 vim에는 몇가지 유용한 도구가 훌륭한 문서가 포함되어 있다. 가장 기본적인 커맨드에 익숙해 질때까지 vimtutor를 실행하자. 또한 다음 페이지를 주의깊게 읽어야 한다: :help usr_02.txt

그러면!, 폴더, 레지스터, 플러그인 및 기타 많은 기능들에 대해 배울 것이다. vim 학습은 피아노를 배우는 것처럼 멋진 일이다.
Tags :

나는 왜 Node의 세계에 남아 있는가?

레딧에 화자되고 있는 "Farewell Node.js(잘가 Nodejs)"와 이상욱님의 블로그에에서 번역한 글을 읽다가 Why I’m staying with Node(나는 왜 Node의 세계에 남아 있는가?)"라는 아티클이 눈에 뜨여 반대와 찬성의 글을 같이 곱씹어보면 좋을 것 같아서 Nodejs 옹호론자의 아티클을 번역해 봅니다.

무엇보다 먼저, Go 사용을 추천하면서 써내려간 획기적인 그의 뉴스와 Node.js에 대한 작별 인사를 한 TJ에게 경의를 표한다. 누구나 어떤 문제에 오랫동안 골머리를 앓는 사람들은 때가 되면 다른 것으로 이동해 간다. 그리고 그의 입장에선, 그것은 "일을 위한 올바른 도구"를 사용하는 것이었다.

좋다. 여러분은 Node.js를 좋아하지 않을수도 있다. 저 녀석은 매력적이면서 똑똑하다.

나에 대해서 말하자면, 아직 Node.js를 사용중에 있다. 여전히 우리는 우리의 앞에 거친 미래가 있을지라도, 나는 오래전부터 JavaScript에 배팅을 해왔고, 영어와 같은 것이라고 할까? JavaScript는 모든 곳에 있다.

물론 비유일지도 모르지만, TJ가 지적한 Node.js의 문제점은 우리들이 앉고 있었던 영어 문제와 비슷하다. 에러 처리 방식은 에러를 일으킬 가능성이 높고, 콜백은 동기식 트랜잭션보다 어렵다. 오류에 오류, 또 오류가 발생할 수 있다. 영어에서도 문법 실수는 항상 일어난다. 하지만, 대부분의 경우 서로 서로 모두 이해할 수 있고 실수를 고치는 방법도 알고 있다.

재미삼아 이야기해보면, JavaScript를 영어로한다면 Go는 하와이어가 되는 것이다,. 영어보다 심플하고, 작고, 효과적이고, 실수도 어렵고, 잘 알려지지 않았고, 자기만의 섬에 갖혀 있다고 말할 수 있다. 비슷한 관점에서 Java 독일어라고나 할까? 이제 이쯤에서 그만 하자.

비유는 제끼더라도 서로 흠집을 파고 들면서까지 Go vs Node를 비교하는 것보다는 Node.js를 계속 사용하려는데에는 몇가지 좋은 이유가 있다.

웹 애플리케이션
Node를 사용하면 시스템의 프런트 엔드와 백엔드의 코드를 그대로 공유해서 사용할 수 있다. 내가 만든 Change.orgOpenLikes, 그리고 당신이 지금 이 아티클을 읽고 있는 이 사이트처럼 Node 때문에, 유틸리티, 모델, 테스트 라이브러리, 심지어 라우팅 로직 조차도 공유할 수 있었다. 물론 유지보수 어플리케이션에 바람직하게 요구되는 프로그래밍의 원칙인 DRY 애플리케이션을 더 많이 만들수도 있다.

리쿠르팅
JavaScript의 대중적인 인기 덕분에 대부분의 사람들은 Javascript에 대해 조금이라도 알고 있다. Go를 사용할 수있는 사람을 채용한다면, 어디서 시작해야할 지 알수 없다. 이것은 개인적인 문제이지만, Node를 사용하고 있다면 쉽게 피할 수 있는 문제다. Node와 Go는 대체로 비슷한 역사를 가지고 있지만, JavaScript는 19세며,독립해 자립하고 있다. Node 경험이 전혀 없는 프로그래머도 몇년 동안 Javascript를 사용해서 안다면, 혼란없이 빨리 익힐 수 있다.

이번 주에 다른 팀에서 들어온 2명의 새로 입사한 직원이 4시간도 지나지 않아 코드베이스를 익히고, 첫 번째 커밋을 했다. 2011년이었다면 몇주 걸렸을 일을.(billwscott 트윗)


일을 위한 올바른 도구
뭐든지 상황에 따라 다르다. 높은 동시성이 요구되는 복잡한 지능 알고리즘을 필요하다면, Node 말고 다른것을 사용하는 것이 좋다. 나라면 Node에서 호출하는 방식의 서비스 같은 것을 할 것이다. Go와 Node 동시성과 속도를 비교하는 것은 for 루프를 앞으로 돌리거나 뒤로 돌려 어느 쪽이 더 성능이 좋은지를 비교 같은 것 같다. 이런 종류의 마이크로 벤치마크는 나에겐 설득력이 없다. 프로그래밍 언어, 프레임워크, 라이브러리를 선택할 때 항상 여러분 제품의 ROI를 고랴해야 하고, 사용자와 팀, 그리고 여러분 자신과의 사이에서 얼마나 효과적이었는지를 고려해야 한다.

교훈
여기선 긴 회고를 하고 싶지 않다. 그래서 TJ 조언과 비슷하지만, 자신의 울타리 바깥에는 매력적인 솔루션들이 많이 있다. 여러분 자신이 잘해나갈 방법을 선택하는 것이 중요하고, 결국에는 자신을 포함한 사용자나 기업을 행복하게 만드는 것이다.
Tags :

개발자와 나이

"It’s official : developers get better with age. And scarcer."이라는 아티클이 레딧에서 다시 회자되고 있어 소개합니다.

아티클의 내용은, StackOverflow에서 개발자들의 Q&A 데이터를 분석 한 것으로, 개발자수는 27세를 정점으로 그 후 6,7년마다 절반으로 그 수가 줄어들지만, 높은 평가를 얻게 된다는 것.

Q&A 사이트여서 그런지, “높은 평가”라는 질문에 좋은 답변을 많이 했다는 것으로 40대의 답변자가 20대의 두배 정도 많았다고 합니다.

그리고 분석 데이터에 의하면 답변의 질은 나이와는 큰 차이가 없고, 단지 고연령 개발자는 많은 질문에 대답하고 있기 때문에, 높은 평가를 얻고 있다고 결론을 내렸다네요.

저도 비슷한 생각이 있는게, 기술 커뮤니티나 페북 그룹, 뉴스그룹 등에서 연장자분들이 아니더라도 눈팅이 아닌 댓글을 통해 답변을 성심성의껏 다는분들이 계신데 그분들이 정말 내공자라 생각이 듭니다.

그냥 '왜'라고 묻는 것이 항상 최선의 전략은 아니다

좋은 제품을 만드는데 있어서 본질을 파고드는 데 좋은 사례가 바로 '왜?'라는 질문을 자신과 이해당사자들과의 토론에서 끊임없이 하는 것이다. 하지만 건성의 '왜'로 핵심을 파지않고 그저 내용의 이해만을 도울 수 있는 왜는 지양해야 된다는 좋은 아티클 'ASKING WHY IS NOT ALWAYS THE BEST STRATEGY'이 있어 내용을 요약해 봅니다.

제품을 만들 때 ‘왜’라는 질문을 반복하는 것은 본질적인 문제에 도달할 수 있는 좋은 방법이지만, HubSpot 제품 디자이너 Daniel Ritzenthaler는 맹목적인 ‘왜’를 반복하는 것은 오히려 생산적이지 않다고 한다.

제품에 좋은 가치를 부여하는 생산적인 ‘왜’를 묻는데에는 3가지 레이어를 인식할 필요가 있다.
  • 첫 번째는 편리성 레이어. 여기는 있는 이 기능을 사용하여 실제로 무엇을 하려고 하는지를 묻는 레이어.
  • 두 번째는 유용성 레이어. 여기는 있는 이 기능을 사용하면 어떤 결과를 얻을 수 있는지를 묻는 레이어.
  • 세 번째는 바람직함의 레이어. 이것이 목적을 달성 한 후에, 다른 것들과의 차별점이 무엇인지를 묻는 레이어.
이 3가지의 ‘왜’라는 레이어를 염두해서 제품을 생각한다면 시간과 결과물에서 좋은 가치를 심을 수 있다고 한다.

관점의 변화

  • 문제 해결형 (problem solving) ⇒ 문제 제기형 (problem finding)
  • 프로세스로서의 디자인 (design as process) ⇒ 중재 (수단)으로 디자인 (design as medium)
  • 답을 제공 (provides answers) ⇒ 의문을 제기 (ask questions)
  • 산업에 대한 봉사 (in the service of industry) ⇒ 사회에 대한 봉사 (in the service of society)
  • 현재 세계를 위해 (for how the world is) ⇒ 앞으로 가능한 세계를 위해 (for how the world could be)
  • 과학 소설 (science fiction) ⇒ 사회적 소설 (social fiction)
  • 미래 (futures) ⇒ 현실과 병행하여 존재하는 세계 (parallel worlds)
  • 적응 (applications) ⇒ 시사점 (implications)
  • 생산을 위한 디자인 (design for productions) ⇒ 토론을위한 디자인 (design for debate)
  • 컨셉 디자인 (concept design) ⇒ 개념적인 디자인 (conceptual design)
  • 소비자 (consumer) ⇒ 시민 (citizen)
  • 사용자 (user) ⇒ 사람 (person), (human)
  • 구입하기 (makes us buy) ⇒ 생각하기 (makes us think)

권위와 가치

Square의 CEO인 Jack Dorsey가 재미난 글을 올렸네요. 회사생활을 하면서 우리도 이런 비슷한 유혹을 많이 받게 되죠? 아래는 Jack Dorsey가 Medium에 올린 글입니다.

회사 생활을 하다보면 사람들이 아이디어를 제시할 때 권위있는 사람들을 이름을 빌려서(혹은 유명한 포스트나 뉴스 기사 등도 포함) 자신의 아이디어에 설득력을 보강하려한다는 것을 많이 발견하게 됩니다.

누군가의 이름을 빌려서 아이디어를 팔 때는 아래 두가지의 일이 일어난다네요.
  1. 당신의 권위가 떨어진다.
  2. 그 아이디어의 가치가 떨어진다.
간단하다: 당신이 이야기(의견이나 아이디어)의 논지를 남에게 설득시키기 위해서 타인의 이름과 권위를 이용한다면, 당신이 한 의견의 가치는 떨어진다.(당신 스스로가 이야기를 믿지 않고 있을 수도 있다) 당신이 정말 그 일이 옳다고 믿는다면, 스스로가 만들어서 그것을 증명하는데 초점을 맞추어야 한다. 권위는 가치를 제시할 때 나오는 것이지 타인의 권위를 등에 엎는 것으로 자신의 생각에 대한 가치가 부여되는 것은 아니다.

우리는 "John이 이렇게 하라고 해요. 이것이 우리의 방식이에요."라는 결론에 이르게하는 토론이 아니라, 우리가 당연하게 생각했던 것들을 다시 생각하고 대담하고 말도 안되는 아이디어에 대해 열정적으로 토론하기를 원한다. 후자의 방식이라면 Agile하고 혁신성을 유지할 수 있지만, 전자는 시대에 뒤떨어지게 된다.
Tags :