-. 유지보수에 '대부분의' 시간과 비용을 쓰는, '거의 모든' 개발자를 위한 책
\"우리는 자신만을 위해서가 아니라 다음에 그 코드를 보게 될 사람도 고려하여 코드를 작성해야 한다.\"
저자 니콜라스 자카스가 전하는 핵심 메시지다. 이 책을 읽고 자신만의 코딩이 아닌, 협업 개발환경에 적합한 코딩 기법을 익힌다면 그동안 많은 개발자를 괴롭혀온 유지보수의 악몽에서 벗어날 수 있다.

-. 코드의 좋은 예 vs 나쁜 예도 비교해주는 친절한 가이드
좋은 예와 나쁜 예의 차이점을 한눈에 알아볼 수 있다.
------
/*
* 각 줄은 단 한 개의 문장만 있어야 하며
* 모든 간단한 문장은 세미콜론으로 마쳐야 합니다.
*/

// 좋은 예
count++;
a \u003d b;

// 나쁜 예: 한 줄에 여러 문장이 있음
count++; a \u003d b
------

어떤 독자를 위한 책인가?
-. 자바스크립트 입문자
-. 팀 프로젝트나 협업을 자주 하는 자바스크립트 개발자

옮긴이의 말
학부 시절에 했던 과제나 학기 프로젝트는 코드가 제대로 동작만 하면 좋은 점수를 얻을 수 있었습니다. 또 차후에 그 코드를 개선하고 관리할 필요도 없었습니다. 그러나 현업에서는 짧게는 몇 달 길게는 몇 년 동안 사용될 코드를 작성하는 것이라 그 품질도 생각해야만 합니다. 그런데 대부분의 개발 업무는 아무것도 없는 상태에서 처음부터 개발하는 일은 거의 드물고 주로 다른 사람이 작성한 코드를 기반으로 이루어집니다. 이 과정에서 자연스레 다른 사람이 작성한 코드를 보며 감탄할 때도 있지만, 도대체 작성한 사람이 누군지 얼굴 한번 보고 싶을 때도 있습니다. 이 책은 바로 이러한 불미스러운(?) 일을 방지하기 위한 책입니다. '다른 사람이 좋지 않은 감정으로 나를 보고 싶어하는 일이 없게 자바스크립트를 개발하는 방법.' 쉽게 말해, 이것이 이 책에 담긴 핵심입니다.
특히 자바스크립트는 언어의 특성상 제대로 관리하지 않으면 복잡도가 감당할 수 없을 정도로 높아질 수 있습니다. 전역 변수/함수를 사용할 수 있고 모든 객체를 원하는 대로 바꿔버릴 수도 있으며 eval()을 사용해 자바스크립트 형태의 문자열을 실행할 수도 있습니다. 물론 이를 적절하게 잘 이용하면 상당히 유용하지만 단순히 편하다는 이유로 혹은 동작한다는 이유로 작성하면 나중에 본인도 왜 이렇게 짰는지 잊어버리고 헤매게 됩니다. 그 코드로 개발해야 하는 담당자는 어서 빨리 퇴근하고 싶다는 생각만 들 뿐이죠. 즉 생산성을 떨어뜨리는 장본인이 되는 것입니다. 이 책에서 스타일 가이드라인과 JSLint를 강조하는 이유입니다.
이 책에서 다루는 내용 대부분은 흔히 있으면 좋지만 없어도 그만인 것으로 생각하기 쉽습니다. 그러나 실제로는 'Part 2 프로그래밍 프랙티스'를 제외하고는 자바스크립트뿐만 아니라 다른 프로그래밍 언어로 개발할 때에도 반드시 필요한 것입니다. 특히 'Part 3 자동화'에서 다루는 내용은 빌드 및 테스트를 자동으로 해주는 CI로 연결되는데 CI는 선택이 아니라 필수라 말하고 싶습니다. 예를 들면 우리는 몸 상태를 알아보기 위해 건강검진을 받거나 인바디 검사를 받습니다. 이런 검사를 우리 몸에 변화가 있을 때마다 우리도 모르는 사이에 자동으로 해준다면 정말 편할 겁니다. 게다가 지속적으로 몸의 상태를 알 수 있으니 건강 관리도 더 열심히 하게 될 것입니다. 이와 마찬가지로 CI는 코드에 변화가 있을 때마다 또는 주기적으로 검사를 수행해서 코드의 품질을 확인하고 자동으로 테스트를 수행합니다. 그리고 그 결과를 우리에게 알려줌으로써 코드 품질을 지속적으로 관리할 수 있도록 환기시켜 주는 역할을 합니다.
설명이 길었습니다만 제가 이 책을 처음 읽었을 때 느꼈던 많은 것을 독자 여러분도 느끼며 그것이 꼭 도움이 되길 바랄 뿐입니다. 마지막으로, 부족한 제 번역을 교정해주시느라 고생하셨을 조희진 에디터님과 박민아 에디터님께 정말 감사하다는 말씀 드리고 싶습니다.
옮긴이_김광호

지은이의 말
웹 개발의 전문화는 어렵고 복잡한 과정을 거쳐 이루어져 왔습니다. 야후 같은 대기업에서도 웹을 전문화시키는 과정에서 많은 시행착오를 겪어왔습니다. 물론 소규모의 기업에서 모든 웹 서비스를 혼자 담당하는 사람이라면 무엇이든 원하는 대로 할 수 있을 겁니다. 하지만 대부분의 프로그래머가 기업이라는 환경에서 일하게 되면서 지금껏 소규모 전투에서 혼자 싸워왔던 군인들이 이제는 팀으로 싸우는 방법을 익혀야 하는 것과 마찬가지가 되었습니다.
저는 1990년대 후반부터 자바스크립트를 공부했습니다. 당시 자바스크립트는 새롭게 등장한 언어라서 공부할 자료가 거의 없었습니다. 저 역시 복잡한 IE와 넷스케이프 내비게이터를 탐구하며 독학으로 자바스크립트를 익혀야 했습니다. 이리저리 실험해보고 가설을 세우고 다시 실험해보며 동작 원리를 알아낼 때까지 모든 과정을 반복했습니다. 운이 좋았던 것인지 이러한 호기심과 노력이 첫 직장에서 큰 도움이 되었습니다. 본격적인 제 커리어의 첫 5년은 자바스크립트 개발자로 시작했습니다. 당시 자바스크립트와 웹 개발 지식은 누구보다 깊이 있다고 자부할 수 있었습니다. 간단한 문제든, 어려운 문제든 대부분 제가 해결할 수 있었습니다. 하지만 제 생각을 함께 토론하거나, 모르는 문제에 관한 조언을 구할 사람이 없다는 점은 힘들었습니다. 게다가 문제를 해결할 수 있는 사람이 회사에서는 저 혼자였기에 더욱더 제 모든 역량을 쏟아부어야만 했습니다.
5년 동안 저는 끊임없는 노력을 통해 기술과 업무 모두 자신할 수 있을 정도로 수준을 향상시켰습니다. 하지만 당시, 저는 다른 사람이 제 코드를 어떻게 볼지는 고민하지 않았습니다. 제가 작성한 코드를 리뷰해주거나 수정해줄 만큼 기술에 대해 잘 아는 사람이 없었기 때문이죠. 순수한 의미에서, 저는 해커였습니다. 원하는 방식대로 코드를 작성했고 잘 바꾸려고 하지도 않았습니다.
6년 차가 되던 해에는 이직을 했습니다. 그런데 새로운 팀에서는 모든 사람이 프로젝트의 전 부분에 대해 코드를 작성해야 했습니다. 저도 자바스크립트와 웹 개발에만 전념할 수는 없었습니다. 저는 서버 사이드 코드를 작성하고 SQL 쿼리를 만드는 데 많은 시간을 보냈습니다. 마찬가지로 백엔드(backend) 개발을 주로 해오던 개발자들도 웹 코드를 작성해야 했습니다. 그 때야 비로소 제가 작성한 코드가 다른 팀원들의 방식과 많이 다르다는 것을 알게 됐고, 문제가 있다는 것을 느꼈습니다.
저는 팀에 더 도움이 되도록 동료들과 같은 방식으로 코드를 작성하기 시작했습니다. 서버 사이드 코드와 SQL은 생소한 부분이라 이 부분에 대해 잘 아는 동료가 작성한 코드의 패턴을 따라 했습니다. 또한 동료에게는 HTML, CSS, 자바스크립트 코딩 패턴을 적용해볼 것을 권하고 이를 표준으로 규정하기 위해 빌드 프로세스에 린트를 추가했습니다. 그 결과 우리 팀은 마치 윤활유가 잘 칠해진 기계처럼 유기적으로 일할 수 있었습니다.
그 후 2006년도에 야후에 입사했을 때, 제게는 업무 처리에 관한 나름의 굳은 신념이 있었습니다. 하지만 그곳에서 접한 건 전혀 다른 세상이었습니다. 제 첫 번째 팀이었던 My Yahoo! 팀은 지금까지 경험한 팀 중에서는 가장 큰 규모였습니다. 간략한 가이드라인이 세워져 있었지만 배울 게 너무나 많았습니다. 새로운 기술, 프로세스, 툴이 매일 쏟아졌습니다. 새로운 환경에 대해 배우기 위해 열심히 노력하며 많은 시간을 투자했고, 동료로부터 최대한 다양한 지식을 얻으려 노력했습니다.
몇 개월 후, 저는 한 가지 문제점을 찾아냈습니다. 이미 익숙해진 프로세스 중에도 항상 옳지만은 않은 부분들이 있었습니다. 게다가 통일된 방법이 없어 많은 사람들이 각자의 방법대로 처리하다가 버그로 이어지기도 했습니다. 이런 상황을 인지하고 있던 매니저는 어느 날 저를 불러 개발 환경을 정리해달라는 말과 함께 지금까지도 저에게 힘이 되는 한마디를 건넸습니다. \"당신이 작성한 코드는 잘 동작하는 데다 버그도 적습니다. 다른 사람들이 모두 당신처럼 코드를 작성하게 하고 싶군요.\" 이에 저는 바로 My Yahoo! 프런트엔드 개발팀에 몇 가지 구조를 도입하는 작업을 시작했습니다.
My Yahoo! 팀에서 성공적인 성과를 보여준 덕분에 2008년 Yahoo! 홈페이지 개편 작업에서는 프런트엔드 관련 리더로 뽑힐 수 있었습니다. 이 프로젝트에서는 20명 이상의 프런트엔드 엔지니어가 같은 코드에서 작업하게 되어, 저의 조직력과 코드 품질 관리 능력을 시험해 볼 좋은 기회였습니다. 몇 달 동안 같이 배우고 협력한 결과, 우리 팀은 많은 사람들이 놀랄 정도로 생산성이 높고 품질이 좋은 코드를 만들어 낼 수 있었습니다. 코드를 작성한 사람과 상관없이 코드에 일관성이 있을 뿐만 아니라, 다른 사람이 작성한 코드를 수정하거나 새로운 기능을 추가하는 데 걸리는 시간도 빨랐습니다. 그 시절 엔지니어링 팀에서 2~3년 동안 우리 팀이 일궈낸 것들은 여전히 제 커리어에서 가장 빛나는 부분 중 하나입니다.
이 책은 제가 야후에 근무한 동안 쌓아온 팁과 기술을 담고 있습니다. 나아가 제 방식대로만 하는 해커 같던 제가 팀을 위해 어느 정도 자신을 포기할 줄 아는 소프트웨어 엔지니어로 어떻게 변했는지를 말하려 합니다. 다시 말해 이 책은 '개인이 아닌, 팀의 일원으로 자바스크립트 코드를 작성하는 방법'에 대한 것입니다.
그러나 '불편한 진실'은 우리가 코드를 유지보수하는 데 대부분의 시간을 보낸다는 사실을 개발자들도 이해하지 못한다는 것입니다. 사실, 우리가 텍스트 에디터를 열고 처음부터 코드를 작성하는 일은 굉장히 드문 경우입니다. 대부분 이미 있는 코드에 새로운 코드를 추가하거나 수정합니다. 그런데 애초에 코드를 유지보수성이 좋게 작성하면 다음에 작성자 본인이나 다른 사람이 그 코드에 작업하더라도 쉽게 수정할 부분을 찾을 수 있습니다. 이러한 이유로 저는 야후에서 동료에게 \"우리는 자신을 위해 코드를 작성하는 것이 아니라 다음에 이 코드를 보게 될 사람을 위해 작성하는 것이다.\"라는 말을 자주 했습니다.
이 책은 자바스크립트 코딩 컨벤션과 이에 대한 논의로 구성되어 있습니다. 가장 유명한 코딩 컨벤션 문서인 '자바 프로그래밍 언어 코드 컨벤션'에서는 다음과 같은 이유로 코딩 컨벤션의 중요성을 언급하고 있습니다.

- 소프트웨어를 사용하면서 드는 비용의 80%는 유지보수에 사용된다.
- 소프트웨어 생명주기 동안 최초 개발자가 끝까지 유지보수를 하는 경우는 거의 없다.
- 코딩 컨벤션은 소프트웨어의 가독성을 향상시켜, 개발자가 새로운 코드를 더 빠르고, 더 완전하게 이해할 수 있게 한다.
- 소스 코드를 제품화 시키려면, 다른 제품들처럼 깔끔하고 잘 패키지화되는 것을 보장할 수 있어야 한다.
이러한 설명은 여전히 맞는 말입니다. 따라서 이 책에서 다루는 컨벤션은 여러분이 자바스크립트 코드를 작성하는 데 최대한 도움이 되도록 구성했습니다.
이 책을 읽는 분은 여기에서 다루는 내용에 대해 열린 마인드일 것이라 생각합니다. 대부분의 테크닉은 다수의 개발자가 같은 코드에서 개발하는 환경에 초점이 맞춰져 있습니다. 팀의 일원이 된다는 의미는 어떤 일에 결정을 내릴 때 자신이 아닌 팀의 입장에서 최선의 결정을 내리는 것이라 생각합니다. 이 말은 경우에 따라 자신의 취향과 생각, 나아가서는 자존심도 포기해야 한다는 것도 의미합니다. 하지만 그 결과로 무엇이든 할 수 있는 능력 있는 팀을 만들 수 있습니다. 이 책이 그러한 훌륭한 팀을 만드는 데 큰 도움이 되길 바랍니다.
지은이_니콜라스 자카스

 

지은이의 말
웹 개발의 전문화는 어렵고 복잡한 과정을 거쳐 이루어져 왔습니다. 야후 같은 대기업에서도 웹을 전문화시키는 과정에서 많은 시행착오를 겪어왔습니다. 물론 소규모의 기업에서 모든 웹 서비스를 혼자 담당하는 사람이라면 무엇이든 원하는 대로 할 수 있을 겁니다. 하지만 대부분의 프로그래머가 기업이라는 환경에서 일하게 되면서 지금껏 소규모 전투에서 혼자 싸워왔던 군인들이 이제는 팀으로 싸우는 방법을 익혀야 하는 것과 마찬가지가 되었습니다.
저는 1990년대 후반부터 자바스크립트를 공부했습니다. 당시 자바스크립트는 새롭게 등장한 언어라서 공부할 자료가 거의 없었습니다. 저 역시 복잡한 IE와 넷스케이프 내비게이터를 탐구하며 독학으로 자바스크립트를 익혀야 했습니다. 이리저리 실험해보고 가설을 세우고 다시 실험해보며 동작 원리를 알아낼 때까지 모든 과정을 반복했습니다. 운이 좋았던 것인지 이러한 호기심과 노력이 첫 직장에서 큰 도움이 되었습니다. 본격적인 제 커리어의 첫 5년은 자바스크립트 개발자로 시작했습니다. 당시 자바스크립트와 웹 개발 지식은 누구보다 깊이 있다고 자부할 수 있었습니다. 간단한 문제든, 어려운 문제든 대부분 제가 해결할 수 있었습니다. 하지만 제 생각을 함께 토론하거나, 모르는 문제에 관한 조언을 구할 사람이 없다는 점은 힘들었습니다. 게다가 문제를 해결할 수 있는 사람이 회사에서는 저 혼자였기에 더욱더 제 모든 역량을 쏟아부어야만 했습니다.
5년 동안 저는 끊임없는 노력을 통해 기술과 업무 모두 자신할 수 있을 정도로 수준을 향상시켰습니다. 하지만 당시, 저는 다른 사람이 제 코드를 어떻게 볼지는 고민하지 않았습니다. 제가 작성한 코드를 리뷰해주거나 수정해줄 만큼 기술에 대해 잘 아는 사람이 없었기 때문이죠. 순수한 의미에서, 저는 해커였습니다. 원하는 방식대로 코드를 작성했고 잘 바꾸려고 하지도 않았습니다.
6년 차가 되던 해에는 이직을 했습니다. 그런데 새로운 팀에서는 모든 사람이 프로젝트의 전 부분에 대해 코드를 작성해야 했습니다. 저도 자바스크립트와 웹 개발에만 전념할 수는 없었습니다. 저는 서버 사이드 코드를 작성하고 SQL 쿼리를 만드는 데 많은 시간을 보냈습니다. 마찬가지로 백엔드(backend) 개발을 주로 해오던 개발자들도 웹 코드를 작성해야 했습니다.
그 때야 비로소 제가 작성한 코드가 다른 팀원들의 방식과 많이 다르다는 것을 알게 됐고, 문제가 있다는 것을 느꼈습니다.
저는 팀에 더 도움이 되도록 동료들과 같은 방식으로 코드를 작성하기 시작했습니다. 서버 사이드 코드와 SQL은 생소한 부분이라 이 부분에 대해 잘 아는 동료가 작성한 코드의 패턴을 따라 했습니다. 또한 동료에게는 HTML, CSS, 자바스크립트 코딩 패턴을 적용해볼 것을 권하고 이를 표준으로 규정하기 위해 빌드 프로세스에 린트를 추가했습니다. 그 결과 우리 팀은 마치 윤활유가 잘 칠해진 기계처럼 유기적으로 일할 수 있었습니다.
그 후 2006년도에 야후에 입사했을 때, 제게는 업무 처리에 관한 나름의 굳은 신념이 있었습니다. 하지만 그곳에서 접한 건 전혀 다른 세상이었습니다. 제 첫 번째 팀이었던 My Yahoo! 팀은 지금까지 경험한 팀 중에서는 가장 큰 규모였습니다. 간략한 가이드라인이 세워져 있었지만 배울 게 너무나 많았습니다. 새로운 기술, 프로세스, 툴이 매일 쏟아졌습니다. 새로운 환경에 대해 배우기 위해 열심히 노력하며 많은 시간을 투자했고, 동료로부터 최대한 다양한 지식을 얻으려 노력했습니다.
몇 개월 후, 저는 한 가지 문제점을 찾아냈습니다. 이미 익숙해진 프로세스 중에도 항상 옳지만은 않은 부분들이 있었습니다. 게다가 통일된 방법이 없어 많은 사람들이 각자의 방법대로 처리하다가 버그로 이어지기도 했습니다. 이런 상황을 인지하고 있던 매니저는 어느 날 저를 불러 개발 환경을 정리해달라는 말과 함께 지금까지도 저에게 힘이 되는 한마디를 건넸습니다. “당신이 작성한 코드는 잘 동작하는 데다 버그도 적습니다. 다른 사람들이 모두 당신처럼 코드를 작성하게 하고 싶군요.” 이에 저는 바로 My Yahoo! 프런트엔드 개발팀에 몇 가지 구조를 도입하는 작업을 시작했습니다.
My Yahoo! 팀에서 성공적인 성과를 보여준 덕분에 2008년 Yahoo! 홈페이지 개편 작업에서는 프런트엔드 관련 리더로 뽑힐 수 있었습니다. 이 프로젝트에서는 20명 이상의 프런트엔드 엔지니어가 같은 코드에서 작업하게 되어, 저의 조직력과 코드 품질 관리 능력을 시험해 볼 좋은 기회였습니다. 몇 달 동안 같이 배우고 협력한 결과, 우리 팀은 많은 사람들이 놀랄 정도로 생산성이 높고 품질이 좋은 코드를 만들어 낼 수 있었습니다. 코드를 작성한 사람과 상관없이 코드에 일관성이 있을 뿐만 아니라, 다른 사람이 작성한 코드를 수정하거나 새로운 기능을 추가하는 데 걸리는 시간도 빨랐습니다. 그 시절 엔지니어링 팀에서 2~3년 동안 우리 팀이 일궈낸 것들은 여전히 제 커리어에서 가장 빛나는 부분 중 하나입니다.
이 책은 제가 야후에 근무한 동안 쌓아온 팁과 기술을 담고 있습니다. 나아가 제 방식대로만 하는 해커 같던 제가 팀을 위해 어느 정도 자신을 포기할 줄 아는 소프트웨어 엔지니어로 어떻게 변했는지를 말하려 합니다. 다시 말해 이 책은 ‘개인이 아닌, 팀의 일원으로 자바스크립트 코드를 작성하는 방법’에 대한 것입니다.
그러나 ‘불편한 진실’은 우리가 코드를 유지보수하는 데 대부분의 시간을 보낸다는 사실을 개발자들도 이해하지 못한다는 것입니다. 사실, 우리가 텍스트 에디터를 열고 처음부터 코드를 작성하는 일은 굉장히 드문 경우입니다. 대부분 이미 있는 코드에 새로운 코드를 추가하거나 수정합니다. 그런데 애초에 코드를 유지보수성이 좋게 작성하면 다음에 작성자 본인이나 다른 사람이 그 코드에 작업하더라도 쉽게 수정할 부분을 찾을 수 있습니다. 이러한 이유로 저는 야후에서 동료에게 “우리는 자신을 위해 코드를 작성하는 것이 아니라 다음에 이 코드를 보게 될 사람을 위해 작성하는 것이다.”라는 말을 자주 했습니다.
이 책은 자바스크립트 코딩 컨벤션과 이에 대한 논의로 구성되어 있습니다. 가장 유명한 코딩 컨벤션 문서인 ‘자바 프로그래밍 언어 코드 컨벤션’에서는 다음과 같은 이유로 코딩 컨벤션의 중요성을 언급하고 있습니다.

- 소프트웨어를 사용하면서 드는 비용의 80%는 유지보수에 사용된다.
- 소프트웨어 생명주기 동안 최초 개발자가 끝까지 유지보수를 하는 경우는 거의 없다.
- 코딩 컨벤션은 소프트웨어의 가독성을 향상시켜, 개발자가 새로운 코드를 더 빠르고, 더 완전하게 이해할 수 있게 한다.
- 소스 코드를 제품화 시키려면, 다른 제품들처럼 깔끔하고 잘 패키지화되는 것을 보장할 수 있어야 한다.
이러한 설명은 여전히 맞는 말입니다. 따라서 이 책에서 다루는 컨벤션은 여러분이 자바스크립트 코드를 작성하는 데 최대한 도움이 되도록 구성했습니다.
이 책을 읽는 분은 여기에서 다루는 내용에 대해 열린 마인드일 것이라 생각합니다. 대부분의 테크닉은 다수의 개발자가 같은 코드에서 개발하는 환경에 초점이 맞춰져 있습니다. 팀의 일원이 된다는 의미는 어떤 일에 결정을 내릴 때 자신이 아닌 팀의 입장에서 최선의 결정을 내리는 것이라 생각합니다. 이 말은 경우에 따라 자신의 취향과 생각, 나아가서는 자존심도 포기해야 한다는 것도 의미합니다. 하지만 그 결과로 무엇이든 할 수 있는 능력 있는 팀을 만들 수 있습니다. 이 책이 그러한 훌륭한 팀을 만드는 데 큰 도움이 되길 바랍니다.

옮긴이의 말
학부 시절에 했던 과제나 학기 프로젝트는 코드가 제대로 동작만 하면 좋은 점수를 얻을 수 있었습니다. 또 차후에 그 코드를 개선하고 관리할 필요도 없었습니다. 그러나 현업에서는 짧게는 몇 달 길게는 몇 년 동안 사용될 코드를 작성하는 것이라 그 품질도 생각해야만 합니다. 그런데 대부분의 개발 업무는 아무것도 없는 상태에서 처음부터 개발하는 일은 거의 드물고 주로 다른 사람이 작성한 코드를 기반으로 이루어집니다. 이 과정에서 자연스레 다른 사람이 작성한 코드를 보며 감탄할 때도 있지만, 도대체 작성한 사람이 누군지 얼굴 한번 보고 싶을 때도 있습니다. 이 책은 바로 이러한 불미스러운(?) 일을 방지하기 위한 책입니다.
‘다른 사람이 좋지 않은 감정으로 나를 보고 싶어하는 일이 없게 자바스크립트를 개발하는 방법.’ 쉽게 말해, 이것이 이 책에 담긴 핵심입니다.

특히 자바스크립트는 언어의 특성상 제대로 관리하지 않으면 복잡도가 감당할 수 없을 정도로 높아질 수 있습니다. 전역 변수/함수를 사용할 수 있고 모든 객체를 원하는 대로 바꿔버릴 수도 있으며 eval()을 사용해 자바스크립트 형태의 문자열을 실행할 수도 있습니다. 물론 이를 적절하게 잘 이용하면 상당히 유용하지만 단순히 편하다는 이유로 혹은 동작한다는 이유로 작성하면 나중에 본인도 왜 이렇게 짰는지 잊어버리고 헤매게 됩니다. 그 코드로 개발해야 하는 담당자는 어서 빨리 퇴근하고 싶다는 생각만 들 뿐이죠. 즉 생산성을 떨어뜨리는 장본인이 되는 것입니다. 이 책에서 스타일 가이드라인과 JSLint를 강조하는 이유입니다.
이 책에서 다루는 내용 대부분은 흔히 있으면 좋지만 없어도 그만인 것으로 생각하기 쉽습니다. 그러나 실제로는 ‘Part 2 프로그래밍 프랙티스’를 제외하고는 자바스크립트뿐만 아니라 다른 프로그래밍 언어로 개발할 때에도 반드시 필요한 것입니다. 특히 ‘Part 3 자동화’에서 다루는 내용은 빌드 및 테스트를 자동으로 해주는 CI로 연결되는데 CI는 선택이 아니라 필수라 말하고 싶습니다. 예를 들면 우리는 몸 상태를 알아보기 위해 건강검진을 받거나 인바디 검사를 받습니다. 이런 검사를 우리 몸에 변화가 있을 때마다 우리도 모르는 사이에 자동으로 해준다면 정말 편할 겁니다. 게다가 지속적으로 몸의 상태를 알 수 있으니 건강 관리도 더 열심히 하게 될 것입니다. 이와 마찬가지로 CI는 코드에 변화가 있을 때마다 또는 주기적으로 검사를 수행해서 코드의 품질을 확인하고 자동으로 테스트를 수행합니다. 그리고 그 결과를 우리에게 알려줌으로써 코드 품질을 지속적으로 관리할 수 있도록 환기시켜 주는 역할을 합니다.
설명이 길었습니다만 제가 이 책을 처음 읽었을 때 느꼈던 많은 것을 독자 여러분도 느끼며 그것이 꼭 도움이 되길 바랄 뿐입니다. 마지막으로, 부족한 제 번역을 교정해주시느라 고생하셨을 조희진 에디터님과 박민아 에디터님께 정말 감사하다는 말씀 드리고 싶습니다.
옮긴이_김광호