코딩 standard: 절대 하지 말아야 하는 practice 들

[ 이글은 2017년 05월 08일에 최종 수정되었습니다. ]
§

어느 분이 자신의 portfolio 페이지를 살펴보고 feedback 을 달라고 하셔서 이분이 작업한 portfolio 페이지를 살펴봤습니다.

여러 버전의 jQuery 사용

이렇게 여러개의 jQuery 버전을 불러오는건 좋은 코딩 standard 가 아닌 이유는:

  1. jQuery 1개도 무거워서 가능하면 jQuery 를 쓰지 않는게 요즘 추세인데, 이걸 3개씩이나 불러오면 문서가 몹시 무거워집니다.

3개씩이나 포함해야 했던 이유를, “Jquery가 3개나 되는 이유가 한 jquery로 통일했더니 fancybox가 에러가 나더라구요… 그래서 3개로 나눠줬네요.”

라고 말씀하셨는데, 물론 문제해결을 위해서 이렇게 하는 경우가 종종 있지만, 좋은 해결책이 아닙니다.
그 이유는:

  1. 페이지도 무거워져서 느려지지만, 다른 자스 (javascript) 들과 충돌이 발생하는 더 큰 문제가 발생한다.

당장 발생하는 문제를 해결하기 위해 임시방편으로 여러 jQuery 를 불러다 쓰면 차후 해결이 안되는, 엄청난 재앙이 발생하는 것 입니다. 목이 마르다고 바닷물을 퍼마시는 것 과 같은 행동인 거죠.

물론 ‘포트폴리오에 더 손댈거 아닌데 상관없잖아?’ 라고 생각할 수 있습니다. 하지만 prospective employer (잠재 고용주?) 는 채용하고자 하는 잠재 고용인의 코딩 스킬을 살펴 보게 되는데, 자신의 포트폴리오 구축에도 best practice (가장 이상적인 코딩) 를 사용하지 않는 사람을 고용하고 싶은 고용주는 존재하지 않습니다.

여러 jQuery 를 불러오는 행위와 동급으로 좋지않은 practice 는 최신버전의 jQuery 를 사용하지 않는 것 입니다.

왜 최신 jQuery 버전을 사용해야 하는가? 오래된, 예전 jQuery 버전을 사용하는 행위는 보안상 큰 위험을 초래하기 때문입니다.

https://www.sitepoint.com/keep-javascript-dependencies-up-to-date/
http://www.ccs.neu.edu/home/arshad/publications/ndss2017jslibs.pdf

이것 역시, ‘포트폴리오 페이지에 여러 form 이 들어가는 것도 아니고, 이게 무슨 보안상 문제가 발생해?’ 라고 생각할 수 있습니다.

물론 포트폴리오 페이지가 어떤 application 도 아니고, 이 포트폴리오 페이지에 국한해서는 아무런 문제가 발생하지 않을 겁니다.

하지만 prospective employer (잠재적 고용주? 하.. 참 한글로 뭐라고 해야되요?) 는 포트폴리오 페이지의 보안을 보는게 아닙니다. 내가 고용하고자 하는 개발자가 코딩시 이렇게 보안에 관심이 없다면 이런 사람을 어떻게 믿고 쓰나? 하는 생각이 들게 됩니다.

마지막으로 excessive use of jQuery plugin (과다한 플러그인 사용)

모달창 하나를 띄우는게 힘들어서 그 무거운 fancybox 를 사용하다니요? ㅠㅠㅠㅠ
물론 저도 colorbox 같은 모달 플러그인을 오래전 사용했었습니다. IE8 시절에는 크로스 브라우징이 너무나 힘들었거든요.

하지만 지난 5년간 자스 (javascript) 는 큰 발전이 있었고, 브라우져 환경 역시 IE9, 10, 11, Edge 가 출시되고 IE9 이하 브라우저는 이제 한국에서도 전혀 사용되지 않을 정도로 천지개벽(?) 했습니다.

ES6 와 ES5 를 비교해보면 얼마나 자스 (javascript) 스크립팅이 간소화 되었고 깔끔하게 변했는지를 실감할 수 있습니다.

http://es6-features.org/

거의 혁명적인 변화가 있었다고 해도 과언이 아닙니다.

제가 위에서 언급한 모달창 플러그인을 그냥 쌩 자스(javascript) 로 짜보겠습니다. ES6 스타일로요. ㅎㅎㅎ

소스 퍼가시고 싶은 분들은 여기서 퍼가시면 됩니다.

https://hackya.com/tutorial/javascript/simple_modal_example.html

let modal = document.querySelectorAll('.modal')[0];
let btn = document.querySelector("#button");
let span = document.querySelectorAll(".close")[0];

btn.addEventListener("click", function() {    
    modal.classList.add("foo");
});

span.addEventListener("click", function() {       
    modal.classList.remove("foo");
});

window.addEventListener("click", function(event) {       
    if (event.target == modal) {
        modal.classList.remove("foo");
    }
});


“let modal =” 이건 자스 (javascript) 문법을 전혀 몰라도 그냥 영어 문법만 이해해도 쉽게 이해가 되는 부분 입니다.

“Let there be light.” (창세기 1:3)

“빛이 생겨라” – 이게 뭐죠? 이 let 을 명령어로 쓰고 있는거죠. that’s it. 그렇게만 이해하면 되는 겁니다.

“document.querySelector(“#button”);” – (document) 문서에, (#button) 버튼이란 이름 (ID) 의 요소 (element) 를 (select) 찝어라.

btn.addEventListener(“click”, function() – 이부분은 오히려 예전 ES5 스타일이 직감적으로 이해하기 더 쉽습니다.

예전 식으로 이 문법을 쓰자면,

btn.onclick = function() 이런식이 되는데,

버튼(btn) 을 클릭하는 경우

modal.classList.add(“foo”); – “foo” 라는 이름을 붙여줘라.

이렇게 이해가 되죠?

제가 드린 설명보다 좀더 자세하게 학구적인 이해를 하고 싶다면, 아래 문서를 참조하시면 됩니다.

https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
https://developer.mozilla.org/en-US/docs/Web/API/Element/classList

암튼 이게 이 모달창 로직의 전부 입니다.

이렇게 모달창의 자스 (javascript) 로직은 오늘 자스 (javascript) 를 처음 접한 사람도 어렵지 않게 이해할 수 있습니다. 물론 영어문법을 이해한다면, 영어 독해력이 좋다면, 더욱더 쉽게 배울 수 있죠.

사실 이 기본적인 예제에서 어려운 부분은 자스 (javascript) 가 아니라 css 라는게 함정.

[저는 20년 가까이 css 를 사용해와서 생전 css 가 어렵게 느껴진적이 없는데, 오랜세월이 흐르며 이제는 css 도 매우 복잡한 형태로 바뀐 관계로, css 도 처음 배우려면 매우 어려운 것 같습니다.]

사실 모달창은 자스 (javascript) 도 필요 없습니다.

https://hackya.com/kr/css-만으로-모달창-띄우기/

css 잘 하시는 분들은 모달창 정도는 어렵지 않게 css 로 만들 수 있으니까요.

제가 하고 싶은 얘기는,

“이런 매우 기본적인 로직조차 직접 짜지 못한다면/않는다면, 이런 개발자를 어느 고용주가 원하겠습니까?”

‘노력을 많이 했는데도 어렵다.’ – 라는 생각이 드시는 분들은 천성적으로 front-end 개발직에 맞지 않는 aptitude (적성: 와 이글 하나 쓰면서 구글 번역기 무지하게 돌리네요. 구글 번역기 없었으면 어쩔뻔. ㅋㅋㅋ) 를 갖고 계신 것 입니다.

그런분들은 이쪽일을 하시지 않는게 본인의 행복을 위해 좋은 선택일 수 있습니다. 내가 front-end 보다는 back-end 개발에 맞는 적성을 갖고 있을지도 모르는 일 이거든요.

마지막으로 코딩 standard 와 전혀 상관 없는 내용이지만, 어떤 분들은 색감이나 공간에 대한 눈을 갖고 계시지 못합니다.

그냥 본능적으로 어떤 색상과 어떤 색상은 어울리지 않는다는 걸 아는 사람들이 있는가 하면, 이런 color scheme 을 확인해가며 색상을 맞춰야 하는 사람들도 있습니다.

또 본능적으로 여백에 대한 감을 갖고 있는 분들도 있고, 반대로 margin 이나 padding 을 얼만큼 줘야 어울리는 디자인이 나오는지를 몰라서 이걸 수학공식으로 짜는 front-end 개발자도 존재합니다.

물론 이런 색상이나 공간에 대한 감이 없다고 좋은 front-end 개발자가 될수 없는 것 은 아닙니다. 단지 본인이 이런 디자이너의 눈을 타고나지 못했다면, 그 부족한 부분을 보완해줄 여러 기법들을 터득하는 것 이 몹시 중요/필수적 입니다.

p.s. 아, jQuery 로는 어떻게 하냐구요?

$('#button').click(function() {
         $('.modal').addClass('foo');
         return false;
     });
     $('.close, body').click(function() {
         $('.modal').removeClass('foo');
     });

이렇게 하면 될거에요. jQuery 는 설명할 건덕지도 없어서, 그냥 코드만 알려드립니다. 혹시 안되면 알려주세요. ^^;;

**.click 은 .on( “click”, handler ) 을 약자로 줄여서 쓴겁니다. 원래는 .on 주고 “click, handler 명시하는게 정석/올바른 코딩 입니다. 왜 정석대로 하지 않냐구요? 귀찮아서.. -..-;;

Tags: , ,

카테고리: , ,

Ω
  • bastcode

    ㅎㅎㅎ 오늘 제가 하고 싶었던 말을 콕 찝어서 말씀해주셨네요 ㅋㅋㅋ
    맞습니다.
    jQuery를 어떻게 사용하고 있는지를 보는 순간 여러가지를 판단 할 수 있습니다.
    사용 버전 부터, 어디에 올려놓고 불러오고있는지, 또 몇개나 따로 불러서 쓰는지 등.

    헬조선식 방식으로 jQuery 범벅을 해둔 사이트 보면, 전 제일 먼저 하는게 jQuery 정리입니다.
    일단 최신 버전등 넣어놓고 어디서 에러나는지 체크하고, 사이드 임펙트 체크하는게 첫 번째입니다.

    이거 안하면요. 결과적으로 계속 늘어납니다. 빼거나 버전 변경해서 이게 안되요. 저게 안되요. 소리 듣기 싫거든요 ㅋㅋㅋ
    [그래서 전 소위 퍼블리셔 라는 인간들하고 많이 싸웠죠. 잘 알지도 못하면서 낮은 버전에서 굴러가는 js 코드를 어디서 퍼와서는 떡하니 넣어두는…. 아옥… ]

    근데 짦은 작업 시간(플젝 기간). 적은 페이. 야근 강요. 등등에 지친 자들이
    터질거 같은거 뻔히 알고 안 건드는건 과연 현명 한걸까. 무지한걸까? 하는 생각도 듭니다.

    물론 애초에 이런 시스템으로 만든 헬조선이 제일 큰 문제겠지만 말이죠 ㅋㅋㅋ

    • http://hackya.com Matthew

      ‘시간이 부족해서 jQuery 플러그인을 불러다 일단 UI 쳐내야겠다.’ 라고 결정하는 경우가 많습니다.

      그런데 그렇게 jQuery 플러그인 불러와도 document 읽어봐야죠, 플러그인 사용법 살펴봐야죠, 또 customizing 도 해주고 기능도 살짝 바꿔줘야 하고, 그러나다 결국 내가 가져온 플러그인이 이 역활에 적합하지 않다는 결론을 내려지게 되서 그거 버리고 또 다른 플러그인 불러오게 되는 경우도 많고…

      결과적으로 더 많은 시간낭비를 하게 되는 경우도 적지 않았습니다.

      여기다 더 대박인건, 그렇게 구축해놓고 몇달후에 jQuery 버전 업. 그런데 새로운 버전에서는 이 플러그인이 먹통.

      장기적으로 보면 절대 시간절약도 되지 않는데다가 무겁기는 또 장난아니게 무겁고.

      단기적으로 이득이라고 생각하기 쉽지만, jQuery 플러그인이나 덕지 덕지 가져다 붙인다고 코딩실력 느는거 아니거든요.

      물론 jQuery 자체는 유용한 물건입니다. 단, 플러그인에 전적으로 의존하는 개발은, 그게 front-end 가 되었건, 워드프레스가 되었건 항상 문제인거죠.

      조금이라도 생각이 있는 개발자라면 이 부분이 크게 느껴질텐데/중요하게 생각될텐데, (자기 자신의 발전을 위해서도) 그렇지 않은 개발자들도 많은 것 같습니다.

  • 겨울바람

    jQuery 코드로 대충 덕지덕지 때려박아 놓고는 자기는 코딩할줄 안다고 해서 for 반복문으로 구구단 짜보라 하니까 for가 뭐냐고 되묻는 퍼블리셔도 봤습니다. 확실히 jQuery가 UI 동작 제어에 대해서 문턱을 많이 낮추기는 했지만, 그만큼 최소한의 이해 없이 복붙으로 하루하루 지내는 사람들도 많이 만든건 아닌가 싶습니다.

    jQuery 사용하는 트렌드는 아마 5년 내에 없어지지는 않을거 같지만, 그것만 쓸줄 아는 사람들은 거기에만 머무르면서 점점 아사하지 않을까 개인적으로 생각하고 있습니다. 에이전시를 제외하고는 이제 jQuery는 한국에서도 점점 안쓰는 추세로 가고 있습니다.

    • http://hackya.com Matthew

      네, UI 코딩하는데 for 도 모르면 슬라이더나 페이징을 어떻게 짜죠?

      이런 for 문 하나 던져줬을때 여기서 variable 을 유추해서 슬라이더 버튼을 짜고 있으면 최소한의 코딩실력은 갖고 있는거고, if 문의 nesting 을 피하기 위해 아예 i=0 으로 잡지 않으면 엄청난 고수 인거고. .. ㅋㅋㅋㅋ (최소한 제 기준에서는 고수 입니다.)

      그런데 이건 jQuery 가 출현하기전의 오래전 자스 (javascript) 스크립팅 기준이구요, 요즘 세대는 이런 low level 스크립팅을 못하는 경우가 태반입니다.

      jQuery 안쓰고, vue.js, angular, react 를 써도 이런 low level 스크립팅을 할 줄 몰라도 얼마든지 UI 짜낼수 있으니까요.

      여기에 대한 논란도 만만치 않습니다. angular 나 react 을 써도 최소 이런 기본적인 자스 (javascript) operator 들을 이해해야 되는거 아니냐?

      Yes. – angular 나 react, 또는 jQuery 가 제공하는 abstraction 에 대한 이해는 해야된다.

      No. – 결과물이 중요한거고 abstraction 만 받아서 쓰면 되는거지 abstraction 까지 까보고 이해해야 할 필요가 없다.

      솔직히 저는 어느쪽이 옳은 주장인지 판단하기 어렵습니다. 단 제가 탓하는건 슬라이더나 페이징 같은 매우 복잡한 스크립팅은 jQuery 같은 library 나 Angular 로 짜더라도, 코딩 몇줄도 필요없는 아주 간단한 UI 까지 jQuery 플러그인 까지 가져다 쓰는건 잘못 되었다는거죠.