반년 동안 node.js를 사용해 본 경험 10가지 요약_node.js

집값, 교통체증, 스모그 얘기는 하지 맙시다. . . 먼저 지난 6개월 동안 Node.js를 사용한 경험에 대해 이야기하겠습니다. . . 모두 직장에서 겪는 문제이자 피를 통해 배운 교훈이다. .

1. 정확한 버전 번호

"특정 버전 번호까지 정확해야 합니다! *를 사용하여 직접 스크롤하면 ^ 및 ~가 작동하지 않습니다!" 아침에 회사에 막 도착했는데 우리 서버장님이 눈이 충혈되어 계셨습니다. 아침 몇 시에 잠들었는지), 나에게 불평했다. "젠장, 전에 작성한 코드 package.json의 버전이 서버에서 실행되는 버전과 다릅니다. 최신 코드를 설치했을 때 또 오류가 발생했습니다." 여기서는 수천 단어를 생략하세요. . .

알겠습니다. 나는 먼저 내 얼굴을 때렸다. 이전에는 *만 사용되었습니다. . . 대부분의 경우 버전 번호를 하드 코딩할 필요가 없습니다. ^ 및 ~를 사용할 수도 있습니다. 블라인드 스캔:

세버
node.js의 버전 관리

2. 테스트

테스트 케이스를 꼭 작성하세요. 예를 들어, 제가 담당하는 부분에는 필터링 부분(일반 Shenma 필터 텍스트를 사용하여 유용한 텍스트 추출)이 포함됩니다. 테스트 사례를 사용하면 필터링 규칙을 변경할 때마다 npm test를 실행하면 모든 것이 잘 될 것입니다. mocha, should, tape, tap, supertest 등 개인 취향에 따라 사용할 테스트 모듈을 선택하세요.

로컬에서 실행해보고 테스트가 성공한 후에만 서버에 업로드해 보세요. 코드를 여러 번(단 몇 줄만) 변경한 후 문제가 있지 않을까 싶었는데, 서버를 다시 시작하자마자 크래시가 발생했습니다. . 젠장, 괄호 같은 게 빠졌네요. . 이러한 종류의 문제는 jslint 또는 jshint와 같은 편집기 플러그인을 사용하여 낮은 수준의 구문 오류를 감지함으로써 해결할 수도 있습니다.

서버 코드 백업. 현재 사용하는 방법: 처음에는 서버에 두 개의 동일한 프로젝트(git 라이브러리, 파일 이름이 다름)가 있고 하나는 실행 중이고 다른 하나는 백업으로 사용됩니다. 코드 변경이 있는 경우 백업 프로젝트로 이동하여 git pull을 한 후 실행 중인 프로그램을 중지하고 백업 프로그램을 시작합니다. 일정 시간이 지나도 프로그램이 중단되지 않으면, 즉 상대적으로 안정된 느낌이 들면 이 프로젝트는 메인 프로젝트로 간주되고 다른 프로젝트는 백업으로 간주됩니다. 다시 변경 사항이 있으면 위 단계를 반복하고 활성과 대기 사이를 앞뒤로 전환하십시오. 프로그램이 중단되면 더 안정적인 장치로 다시 전환하세요.

3. 디버그 사용

저를 포함해 많은 사람들이 다목적 console.log()를 좋아하고 익숙하게 사용하면서 프로그램을 작성할 때 디버깅은 불가피합니다. . 개인적으로 나는 console.log()를 사용한 후에 이를 삭제하거나 주석 처리합니다. 삭제하면 나중에 주석으로 사용할 수 있습니다. 이때 디버그 모듈을 사용할 수도 있습니다. 아직 node-inspector를 사용하지 않았으므로 언급하지 않겠습니다.

4. 코드를 간소화하세요

더 적은 코드로 더 많은 일을 달성하려고 노력하는 것도 자신의 능력을 향상하고 테스트하는 것입니다. 올바른 들여쓰기, 적절한 변수 이름, 명확한 코드 구성 구조 등을 포함합니다. . 코드는 간결하고 아름답습니다. 문제가 발생하면 돌아가서 오류를 확인하는 것이 먼저 엉망인 코드가 무엇인지 알아내려고 시간을 보내는 것보다 낫습니다.

팀에서 CoffeeScript를 사용하지 않는다면 사용하지 마세요. 첫째, 다른 사람들은 귀하의 코드를 읽을 수 없으며 오류 수정에 도움을 줄 수 없습니다. 둘째, 오류가 발생한 후 오류를 표시하는 줄 수가 커피 코드의 줄 수와 다릅니다. . . 자신만의 오픈소스 프로젝트에 사용할 수 있습니다.

5. 조언을 구하고 독립적인 사고를 유지하세요

처음 일을 시작했을 때는 기술적 결함, 비즈니스 로직 결함 등 모든 것이 혼란스러워서 팀 내 전문가에게 조언을 구하는 경우가 많았습니다. 그런 다음 기술적인 단점을 보완하고 비즈니스 로직을 명확히 하도록 노력하겠습니다. 나중에는 PM의 요구사항에 따라 API를 설계해야 했고, 사용자의 요구(멀티 클라이언트 상황), 클라이언트의 요구와 행동, 데이터베이스 설계(저장 방법)를 고려해야 했습니다. 중복되는 데이터를 줄이고, 쿼리 수를 줄이고, 확장하기 쉽게), 수정하기 쉬움, 차등 쿼리) 등등, 일주일 넘게 고민하다가 거의 무너졌습니다. . . 상사와 여러 번 논의했지만 항상 논리는 알려주지만 방법은 알려주지 않습니다. 나중에 마침내 꽤 좋은 해결책을 찾았습니다. . 나중에 그는 내가 독립적으로 생각하고 문제를 해결하여 발전할 수 있기를 원한다고 말했습니다. .

6. 기존 라이브러리 사용

현재 npm에는 거의 9W의 타사 모듈이 있습니다. 이론적으로 사용하려는 모든 모듈은 npm에서 찾을 수 있습니다. 물론 npm에는 포괄적이고 사용하기 쉬운 훌륭한 모듈이 많이 있습니다. . 일반적으로 만족스럽습니다. 모듈이 대부분의 요구 사항을 충족하거나 기능적 개선이 있거나 버그가 있는 경우 github에 PR을 제출할 수 있습니다. 요구 사항을 충족하는 모듈을 찾을 수 없으면 직접 만들어서 게시할 수 있습니다. npm.모든 사람과 공유하세요. 물론 특정 기능을 구현하는 특정 유형의 모듈이 매우 형편없다고 판단되면 형편없지 않은 모듈을 게시할 수도 있습니다.

7. 단순하게

파이 차트를 표시하려면 HTML5 캔버스나 CSS3를 사용하면 됩니다. "종속 라이브러리를 다운로드하는 데만 400MB가 소요됩니다."라고 Toutou는 말했습니다.

8. 좋은 문서화

좋은 문서화는 클라이언트 팀과 서버 팀 간의 의사소통을 위한 가장 중요한 채널입니다. 문서는 명확하게 작성되어 있습니다. 클라이언트 요청이 잘못되면 문제가 발생할 때마다 서버에 가서 논의하는 대신 문서를 먼저 확인할 수 있습니다(예: 각 오류 코드가 나타내는 내용). 추신: js에서 객체를 사용하는 대신 컬을 사용하여 일부 http 요청 예제를 작성해 보십시오. 어쩌면 당신은 이해할 수도 있지만 클라이언트의 사람들은 js를 이해하지 못할 수도 있습니다.

9. 구성 파일

각 프로젝트 디렉터리에 config.js/config.json과 같은 구성 파일을 만듭니다. 코드에 하드 코딩하는 대신. 예:

{
"앱": 3000,
"몽고": {
"호스트": "localhost",
"포트": 27017
},
"redis": {
"호스트": "localhost",
"포트": 6379
}
...
}
10. pm2를 사용하세요

pm2와 같은 프로세스 관리 도구를 사용하면 매우 편리합니다. 최악의 경우 프로세스가 종료되면 자동으로 다시 시작될 수 있습니다. 영원히 사용되지 않습니다. 평가가 없습니다. . 또한, 나는 그런트 센마를 사용하지 않았으므로 이에 대한 언급은 하지 않겠습니다.