Refactoring node.js 의 두 번째 섹션에 오신 것을 환영합니다.이 시리즈에서는 보다 효과적이고 깨끗한 Node를 작성하는 데 도움이 될 수 있는 팁과 도구를 공유합니다.js 코드.

컨텐트

1. Fail early with strict mode

2. Use a linting tool

3. Write JSDoc documentation

4. Use async FS methods with fs.promise

5. Gotta catch 'em all: Using a global error handler

1. 엄격한 모드로 미리 실패

Github에서 코드mongoose를 읽다가 strict mode를 발견했습니다.나는 왜 도서관 전체의 모든 문서가 'use strict'로 시작하는지 정말 궁금하다.
ECMAScript 5는 Javascript에 엄격한 모드를 도입했습니다.Javascript가 허용하지 않기 때문에 엄격한 모드를 적용할 때, 더욱 깨끗하고 안전한 코드를 작성하기 쉽다.

우리는 성명되지 않은 변수와 같은 일을 피할 수 없다.

'use strict' 

undeclaredVar = 10; // Throws an error.

Javascript 키워드와 일치하는 변수를 사용할 수 없습니다. 예를 들어 let:

'use strict' 

var let = 10; // Throws an error.

함수의 모든 매개변수에는 고유한 이름이 있어야 합니다.

'use strict' 

// Throws an error.
function sum (a, a) {

}

우리는 어떻게 코드에서 엄격한 모드를 사용합니까?

모든 자바스크립트 파일에 간단하게 쓰기 use strict 를 통해 엄격한 모드를 '활성화' 할 수 있습니다

'use strict' 

// JS Code.

또는 원하는 경우 특정 기능에서 사용할 수 있습니다.

function strictFunction() {
    'use strict' 
    // Function code.
}

function notStrictFunction() {
    // Function code.
}

흥미로운 사실: 자바스크립트 모듈은 기본적으로 엄격하기 때문에 우리는 엄격한 모드를 현저하게 적용할 필요가 없다.

module.exports.noNeedForUseStrict = () => {
    // Strict mode by default.
}

왜 엄격한 모드를 사용합니까?

내가 이전에 언급한 (그리고 더 많은) 문제에서 벗어날 수 없기 때문에, 더욱 안전하고 실패할 확률이 낮은 코드를 작성하는 것이 더욱 쉽다.우리가 안전하지 않은 코드를 작성할 때, 우리는 즉시 경고를 받을 것이다. 조기 실패는 작은 오류를 범하는 것을 방지할 수 있고, 이것은 우리가 더욱 좋은 실천을 배우고 응용하는 데 도움이 된다.
엄격한 모델에 대한 더 많은 정보: MDN - Strict mode.

2. 보푸라기 도구 사용

내가 이전에 자바스크립트를 작성할 때 가장 괴로웠던 문제는 문자열의 단인용 부호와 쌍인용 부호 사이를 항상 바꾸는 것이다.그러나 나중에 나는 어느 곳에서 ESLint에 관한 내용을 읽었다. 약간의 설정을 통해 나는 나의 모든 문자열에 단인용 부호를 사용할 수 있었다.
ESLint 등의 보풀 도구를 사용하면 다음과 같은 이점을 얻을 수 있습니다.

당신과 당신의 팀을 위해 스타일 규칙을 설정하여 코드를 표준화하고 팀의 모든 사람이 읽을 수 있도록 합니다.

사용되지 않은 변수 등 오류 발견

미리 정의된 스타일 가이드를 쉽게 따라 코드가 당신과 당신의 팀보다 읽기 쉽도록 합니다.예: Google JavaScript style guide.

ESLint 설치

당신의 프로젝트 수행npm install eslint --save-dev

CLI는 기본 구성을 설정하는 데 도움이 됩니다

.
파일.eslint.js을 편집하여 기본 구성을 사용자 정의할 수도 있습니다.

ESLint 실행

스타일 규칙을 설정한 후 남은 작업은 ESLint를 실행하고 발견된 문제를 수정하는 것입니다.
전체 프로젝트에서 ESLint 실행: eslint ./이 명령은 코드를 스캔해서 설정한 규칙이 어느 곳에서 지켜지지 않았는지 알려 줍니다.또한 오류 코드, 오류 행, 문제에 대한 빠른 설명을 제공합니다.

const myConst = 10;
myConst = 11;

// ESLint result:
// 2:1 error  'myConst' is constant                         no-const-assign

If the description is not good enough, you can always use the error code to check an in-depth explanation of the issue using the search field in ESLint site.

하지만 잠깐만, 더 있어!

--fix 옵션을 사용하여 자동 복구를 적용할 수 있습니다.이것은 모든 문제를 해결할 수 없다. 왜냐하면 그 중 일부 문제는 인공적인 개입이 필요할 수 있지만, 많은 문제를 해결할 수 있기 때문에 재구성 과정이 더욱 쉽다.
나도 썼어.

3. JSDoc 문서 작성

JSDoc는 소스가 시작된 Javascript API 문서 생성기입니다.그것은 개발자가 주석을 통해 그들의 코드를 기록하도록 허용한다.
다음은 JSDoc로 기록된 함수의 모양입니다.

/**
 * Retrieves a user by email.
 * @async
 * @param {String} email - User email
 * @returns {User} User object
 * @throws {NotFoundError} When the user is not found.
 */
const getByEmail = async (email) => {
    // ...
}

JSDoc에게 좋은 점이 있나요?

당신은 @param와 같은 탭 목록을 사용하여 가능한 한 코드를 완전하게 기록할 수 있습니다.

코드를 기록한 후에 간단한 명령을 사용하여 문서를 HTML 사이트로 내보낼 수 있습니다. jsdoc r

VScode

에 지원 내장

내보내기 사이트의 레이아웃은 맞춤형으로 설정할 수 있고 Github에 사용할 수 있는 템플릿이 있습니다.

내보내지 않아도 문서를 읽는 모든 사람에게 도움이 됩니다(특히 VScode나 JSDoc를 지원하는 IDE를 사용한다면).

JSDoc에 대해 더 많은 정보를 알고 싶다면, 나는 이 주제에 대한 완전한 글을 썼다.

4. FS에 비동기식 FS 메서드를 사용합니다.언약

지난번에 나는 util.promisify와 그것을 어떻게 사용해서 fs 리셋 모듈을 약속으로 바꾸는지 썼다.근데 나중에 댓글에.
그는 다음과 같이 지적했다.

Hugo Di Francesco
•
노드 10 + fs 다음에 예상 버전의 fs가 있습니다.승낙

const fs = require ('fs').promises

그 이후로우리는 jsv10fs과 다음과 같은 약속을 사용할 수 있다.

const fs = require('fs').promises;

const readFile = async (path) => {
    // Check if the path exists.
    const stats = await fs.stat(path);

    // Check if the path belongs to a file.
    if (!stats.isFile())
        throw new Error('The path does not belong to a file');

    // Read file.
    return await fs.readFile(path);
}

util.promisify 운영 시 필요 없음fs!

5. 그들 모두를 잡아야 한다: 전역 오류 처리 프로그램 사용하기

나의 지난 글에서 나는 우리의 잘못을 더욱 쉽게 식별하고 처리할 수 있도록 하는 글을 썼다. 너희들 중 일부는 나에게 오류 처리에 관한 글을 더 많이 쓰라고 요구했기 때문에 우리는 전체적인 오류 처리에 대해 이야기하자.

전역 오류 처리란?

전역 오류 처리는 한 곳에서 모든 오류를 포착할 수 있도록 합니다.이것은 오류를 발견하고 어떻게 처리해야 할지 결정하는 마지막 장벽이다.
글로벌 오류 처리 프로그램을 사용하면 다음과 같은 이점이 있습니다.

우리는 항상 적용되는 오류를 처리하기 위해 표준 규칙을 정의할 수 있다.

사용자나 클라이언트는 전혀 처리되지 않은 오류를 받지 않습니다.

모든 오류는 어느 곳에 기록할 수 있고 심지어 오류가 발생했을 때 팀에 통지할 수 있다.

표 이름과 같은 개인 정보를 고객에게 보내지 않고 소프트웨어 보안을 보장합니다.

개발 환경은 생산 환경에서 발생하는 오류에 대한 정보를 더 필요로 한다.Google은 사용자나 고객에게 모든 정보를 공개하지 않고 개발자가 잘못된 세부 사항을 알 수 있도록 소프트웨어를 확보할 수 있습니다.

고객 또는 사용자가 적절한 조치를 취하려면 오류에 대한 명확한 정보가 필요합니다.좋은 전역 오류 처리 프로그램이 이 점을 확보할 것이다.

실제로 우리는 누구에게도 드러날 수 있는 잘못을 어떻게 처리해야 할지 결정할 수 있다.

우리는 그것을 어떻게 실시합니까?

전역 오류 처리 프로그램의 실현은 우리가 작성하고 있는 소프트웨어의 유형, 특히 노드에 달려 있다.js는 REST API, CLI, 작업 등을 구축하는 데 사용할 수 있습니다.
만약 프레임워크를 사용하고 있다면, 전역 오류 처리 프로그램의 정의를 고려했음을 발견할 수 있기 때문에, 문서를 검사하도록 권장합니다.
Express를 살펴보겠습니다.예컨대 js.

Express의 오류 처리입니다.js

급행 열차.js는 Node에 사용되는 웹 프레임워크입니다.js, 그것은 자신만의 error handling strategy 가 있습니다. 당신은 그것을 이용할 수 있습니다.
express를 사용하여 모든 오류를 처리하기 위해서, 우리는 중간부품을 사용해야 한다.간단한 중간부품은 다음과 같습니다.

const express = require('express');
const app = express();

app.get('/', (req, res) => {
    res.send('Hello world!');
});

// Define the error handler after other middleware and endpoints.
app.use(errorHandler)

app.listen(port);

/**
 * Error handling middleware.
 */
function errorHandler(err, req, res, next) {
    logError(err);

    if (err.statusCode) {
        // All errors that have a status code are safe.
        res.status(err.statusCode).send({ error: err.message });
    }
    else {
        res.status(500).send({ error: 'Something went wrong' });
    }
}

보시다시피 저희는 발생할 수 있는 모든 오류를 포획하고 다음과 같은 간단한 규칙을 정의합니다.

모든 오류가 어딘가에 기록되어 있다.

만약에 저희 오류가 하나 있다면statusCode 클라이언트에게 안전하게 되돌려주고 오류에 정의된 같은 상태 코드와 메시지를 사용할 수 있다고 가정합니다.

만약 우리의 오류가 statusCode가 없다면, 우리는 상태 코드가 500인 일반적인 메시지 (내부 서버 오류) 를 되돌려줄 것입니다.

비록 이 매우 간단한 예에서, 우리는 처리되지 않은 오류가 클라이언트에게 되돌아오지 않았음을 확보했고, 모든 오류는 기록되어 앞으로 어떤 문제를 복구해야 하는지, 클라이언트가 해당하는 행동을 취할 충분한 정보를 받았는지 평가할 수 있도록 한다.우리의 소프트웨어는 안전해서 고객이 매우 만족한다.

오류 처리 도구

이전 예시에서, 우리는 사용자 정의 전역 오류 처리 프로그램을 작성하여, 오류를 어느 곳에 기록했다.이것은 프로젝트의 초기 단계에서 오류를 처리하기에 충분할 수도 있지만, 결국 우리는 더 많은 것을 필요로 할 수도 있다.예를 들어, 프로그램이 던진 오류에 대한 알림과 보고를 받는 것이 좋습니다. 그러면 우리는 신속하게 행동을 취해 그것들을 복구할 수 있습니다.

Short story: When @maurogarcia_19 and I launched , our latest project, we had an awful bug that only presented itself on non-English browsers. The error was being logged, but we find out about it from our users first. If we had received an automatic notification we could've fixed the error faster, reducing the number of users affected. Lesson learned!

오류 감시와 보고에 사용되는 도구가 많다.나는 지금 시도하고 있다Bugsnag.지금까지 내가 좋아하는 것은:

JavaScript

와 쉽게 통합

소기업에 적용되는 무료 계획이 있다

슬랙과 통합할 수 있기 때문에 오류가 발생할 때마다 메시지 한 개와 실행할 작업 그룹을 받을 수 있습니다.

당신은 다른 공구를 시험해 본 적이 있습니까?알려줘!

사상💬

이 건의들은 쓸모가 있습니까?
다른 노드를 써달라고요?이 시리즈의 다음 글은 js와 관련된 주제입니까?
효과적/깨끗한 노드를 쓰는 기교는 무엇입니까?js 코드?
나는 너의 피드백을 듣고 싶다!