하나. breakpoint설정
두울. debugger statement활용
세엣. pause on exceptions버튼 활용(일시정지 간판처럼 생긴거)
pause on exceptions버튼은 오류 직전에 끊어주니까 특히 유용할 것 같다. 단, 이것들 모두 개발자도구가 켜져있을 때 작동한다.
문득 드는 생각이 개발 과정에서 중간중간 로그를 찍어서 변수에 담긴 값 등을 확인하는데, 이것도 좀 체계적으로 할 수 있겠다. chalk 패키지와 util 패키지를 활용해서 나만의 패키지를 만들어 쓴다던가...
ex 1)
for (;;) {
if (condition) {
do something ...
}
}
위 처럼 하기보단, 아래가 좋다.
for (;;) {
if (!condition) continue;
do something ...
}
ex 2)
funtion do(nbr) {
if (nbr < 0) {
alert('Negative number is not allowed.');
} else {
let result;
for (;;) {
do iterations for reslult...
}
return result;
}
}
위 처럼 하기보단, 아래가 좋다.
funtion do(nbr) {
if (nbr < 0) {
alert('Negative number is not allowed.');
return;
}
let result;
for (;;) {
do iterations ...
}
return something;
}
핵심 함수를 보조하는, 이른바 helper function의 경우 어디에 위치하는 것이 좋을까? 핵심 함수의 위에 선언 할 수도 있고, 아래에 할 수도 있고, 섞어 쓰기도 한다.
하지만 대부분의 경우 아래에 쓰는 것이 좋다. 우리는 코드를 읽을 때 먼저 핵심 함수가 무슨 일을 하는지 알아야 하기 때문이다. 핵심 함수가 어떻게 동작하는지 이해하는 것도 helper 함수의 적절한 이름만으로 충분하다. 뒤따라 오는 helper 함수들의 상세 내용은 굳이 읽지 않고 넘어갈 수 있다.
Comment this:
- Overall architecture, high-level view.
- Function usage.
- Important solutions, especially when not immediately obvious.
나도 나름 코멘트를 써주려고 하는데, 위 예시에서 주로 3번째 경우에 붙여줬던 것 같다. 다만 중요도를 따지진 않고 크든 작든 솔루션 설계에 당위성이 분명하지 않을 때 주로 썼다.
앞으로는,
1. 독립된 js파일을 작성 할 때 전체 프로그램 내에서의 역할, 기능의 논리구조를 코멘트로 먼저 정의한다.
2. 핵심 함수들의 용법을 코멘트로 남긴다.
ex)
/**
* Returns x raised to the n-th power.
*
* @param {number} x The number to raise.
* @param {number} n The power, must be a natural number.
* @return {number} x raised to the n-th power.
*/
js는 변화하고 있다. js를 해석하는 엔진(브라우저, node)도 마찬가지로 버전이 있다. 당연히 최신 버전의 js기능과 문법을 이해하지 못하는 엔진도 있기마련이다. 이런 접근성의 부족을 해결하기 위해 transpilers와 pollyfills가 필요하다. 각각 최신 문법을 위해, 그리고 최신 메소드를 위해 존재한다.
transpilers에는 유명한 Babel이 있고, pollyfills에는 corejs, pollyfill.io같은 라이브러리가 있다. 번외로 webpack같은 project build system으로 바벨 등의 번거로운 전처리를 자동화 할 수 있다.
내 생각에 이건 개발 보다는 QA 영역 같다. 언제 한번 훑어보긴 해야겠지만, 바벨이니 웹팩이니 하는 것들을 자세히 파볼 생각은 없다. 매우 중요한 주제임은 맞지만 '지금, 내가' 공부 할 것은 아닌 듯 하다.