Coding Story

그런데, 이 퍼블리셔라는 사람들이 만들어 놓은 파일들을 보면,

개발자로서는 참 난감한 경우가 많다.

여러가지가 있지만, 나열해보면

1.웹 표준, 접근성에 맞지 않게 코딩.

2.테이블을 이용한 막코딩

3.js, php 활용을 고려하지 않은 모양만 갖춘 코딩.

등이 있다. 

여기서 1번,2번은 개인적으로는 퍼블리셔라고 불러주고 싶지도 않은, 

기본적 소양도 갖추지 못한 퍼블리셔라고 본다. 그냥 코더라고 부르겠다.

그런데...3번은 보자. 3번 같은 경우도 정말 자주 있는 일이다. 저런 경우에는 결국

개발자가 다 뜯어서 마크업부터 다시한다. 일을 두번하게 되는 샘이다.

왜 이런 일이 발생할까? 

그렇다! 그는 html, css에도 능숙하고, 웹표준, 접근성 마크도 여러번 달아봤지만, javascript와 php의 j, p 자도 몰랐던 것이다. 내가 만든 이 html에 어떤 조작이 가해져서

어떤 효과를 내고, 어떤 데이터를 가져올지 전혀 모르는 상태에서 마크업을 하니, 오히려

넘겨받은 파일이 정상인 것이 기적인 샘이다.

(물론, js도 능숙하게 다루지만 업무적 포지션이 퍼블리셔인, 진정한 퍼블리셔 분들도 많이 계신다.)

다시 말해서, 퍼블리셔가 js나 php, jsp가 어떻게 돌아가는지 전혀 알지 못하면, 이러한 사태가 빈번히 발생 할 수 있다.

퍼블리셔는 js와 서버 언어에 대한 지식을 키우는 데 게을리 하지 않아야 한다는게 프론트 엔드 개발자로서의 입장이다.

일부 퍼블리셔는 말한다.  (그러면서 그들이 할줄 아는 것에 덧붙여 js도 할줄 아는 ui 개발자와 동등한 대우를 받기를 원한다.)

"웹 접근성, 표준 지키고 크로스 브라우징 레이아웃 마크업 하기도 바쁜데 js도 해야하나요? 내가 왜 js를 해야하나요?

그거 개발자가 하는 거잖아요?"

그러면 이렇게 답변해주고 싶다.

"그러면 퍼블리셔는 프론트 엔드 개발자가 아니네요? 똑같은 대우 해달라고 하지마세요."

바쁘다는 핑계로 자기가 왜 js를 해야 하냐고 주장하지만, 필자의 느낌은,

솔직히 말해서, js를 하고 싶지않고, 변화를 강요받고 싶지 않은 퍼블리셔가 많은것 같다.

주변에서 계속해서 js를 권유하기 때문에 js 자체게 반감을 갖고, 비하하는 퍼블리셔도 종종 보인다.

(실제로 주변 지인 퍼블리셔들의 이야기를 들어보면, js부터는 다양한 개발 방법론이 있는 언어 단계로 접어들어,

그 장벽이 결코 낮지 않다고 한다.)

 분명히 위의 말에서, '이것저것 하느라 바쁜데'라는 말은

누가 들어도 공감 할 수 있는 사실이다. 그러나 필자가 요구하는 것은 js의 업무적인 추가를 요구하는 것은 아니다.

기본적으로 js가 어떻게 구동되며, 퍼블리싱 된 제품을 어떻게 이용 하는지를 알고 퍼블리싱하기를 바라는 것이다.

퍼블리셔라는 포지션은 분명 사라질 수 없는 포지션임은 틀림 없으며, 퍼블리셔도 마크업을 전문적으로 하는

프론트 엔드 개발자의 일환임에도 틀림없다.

그러나 js만을 다루며 html, css를 무시하는 사람이 프론트 엔드 개발자가 아닌 js 코더이듯, 

html, css를 다루며 웹표준, 웹접근성 마크 다는 것을 어떤 대단한 기술을 가진 것인 냥 유세를 부리는

퍼블리셔는 프론트 엔드 개발자가 아니다. 그냥 마크업 코더일 뿐이다. 그런 사람들에겐 이렇게 말 해주고 싶다.

"표준이랑 접근성 그거 난 옛날부터 할줄 알아서 다음단계로 넘어온 거거든요?"

자바스크립트는 객체 중심 언어이다.

그래서 자바스크립트는 항상 변수를 만들고, 그 변수에 인스턴스(객체형 혹은 자료형 변수)를 생성하여 담아서 이용하는 것으로 부터 시작된다.

자바스크립트의 데이터 타입의 종류는 요약하면 다음과 같다.

-숫자(number)

 ex ) var no = new Number(); (기본 값은 0)

-문자열(string)

 ex ) var str = new String();

-참거짓(boolean)

 ex ) var isTrue = new Boolean();(기본 값은 false)

-객체(object) 

  ex ) var obj = new Object();

-함수(function)

 ex ) var func = new function(){};

-배열(array)

 ex ) var arr = new Array();

-정규식(regexp)

 ex ) var reg = new RegExp();

그런데, 이 객체들을 생성 할 떄 

우리는 생성 연산자 'new'를 이용하여 생성 한 후, 그 다음 라인에

생성한 객체(혹은 자료)에 대한 정보를 추가로 담는 식으로 활용한다.

여기까지가 자바스크립트에서의 변수의 유형과 생성 방법이다.

그런데, 자바스크립트와 같은 객체 중심, 혹은 지향 언어에서는 객체의 리터럴(literal) 표기법을 지원하게 되는데,

이 리터럴이라는 것의 사전적 의미를 보면 '문자 그대로의' 라는 의미이다.

즉, (위에서 예제를 살펴봤던 순서대로) 자바스크립트에서 리터럴 표기법을 살펴보면 다음과 같다.

var no=3;

var str='';

var isTrue=true;

var obj={nation:'korea',age:15};

var func=function(){
}

var arr=[];

var reg=/[a-z]/g;

사실, 우리가 흔히 써오던 변수를 선언하고, 데이터를 담는  일반적인 방식이다.

그런데, 이렇게 쓰면 무언가 정규적이지 않고, 비 공식적인 것 같으며, 심지어

성능을 저하하는 코딩을 하고있다는 느낌이 들기도 한다.

위의 방식처럼 'new' 연산자를 이용하여 먼저 객체를 만들고, 그 값을 수정 해 나가는 것이

정규적이고, 절차를 지키는 방법이며, 성능 향상에 기여하는 것처럼 보인다. 

하지만 우리가 생각 한 것과 다르게 리터럴 표기법은 비 정규적인 (흔히 말하는 야매)도 아니고,

성능 저하를 불러오지도 않으며, 코드는 더 짧으며, 엔진의 해석 속도 면에서도 오히려 더 빠르다.

몇가지 장점이 있는데, 우선 코드가 더 짧으며, (몇 바이트, 몇 라인이라도 줄지 않겠는가?),

자바스크립트 인터프리터의 해석분량도 줄어들며,(데이터를 생성 함과 동시에 담는다. 위의 생성방식으로는 먼저

생성을 한 후, 데이터를 한땀한땀 담아야 한다.) 더 쉽고,  더 빠르다.(실제로 소위 말하는 모던브라우저들의 엔진에서는

자바스크립트의 리터럴 표기법에 대한 최적화가 되어있다고 한다.)

조금은 복잡한 내용이지만 동적 데이터 접근에 대한 호환성도 제공한다.

(이는 new 연산자를 이용하여 인자를 동적으로 제공 할 시 문제가 생기기도 한다는 이야기가 있다.)

어쨌든 결론은 '생성자 사용을 지양하고 리터럴 표기법을 사용하자'라는 것이다.