주택 가격, 교통 체증 및 스모그에 대해서는 이야기하지 마십시오. . . 지난 6 개월 동안 Node.js를 사용한 경험에 대해 먼저 이야기하겠습니다. . . 모두 직장에서 발생하는 문제와 피의 수업입니다. .
1. 정확한 버전 번호
"당신은 특정 버전 번호에 정확해야합니다! * 사용 *을 직접 롤링하려면 ^ 그리고 ~는 괜찮지 않습니다!" 우리가 아침에 회사에 도착하자마자, 우리의 서버는 피의 눈으로 덮여 있었고 (아마 아침에 잠자리에 들기 위해 아마도 아마도) : "젠장, package.json 코드의 버전은 서버에서 실행중인 버전과 다릅니다. 최신 버전을 설치 한 다음 오류를보고했습니다." 여기에는 수천 단어가 생략됩니다. . .
괜찮은. 나는 먼저 얼굴을 때릴 것이다. 나는 *만 사용했었다 *. . . 대부분의 경우, 죽은 버전 번호를 쓸 필요가 없으며 ^ 및 ~를 사용할 수도 있습니다. 실명 스캔 :
SEMVER
node.js의 버전 관리
2. 테스트
테스트 사례를 작성하십시오. 예를 들어 나를 데려가십시오. 내가 담당하는 작품에는 필터링 부분이 포함되어 있습니다 (일반 Shenma의 필터 텍스트를 사용하여 유용한 텍스트를 추출합니다). 테스트 사례의 경우 필터링 규칙의 각 변경 후 NPM 테스트에서는 절대적으로 해당됩니다. 개인 선호도, Mocha,해야 할, 테이프, 탭, SuperTest 등에 따라 사용할 테스트 모듈을 선택하십시오.
테스트가 성공한 후 로컬로 실행하고 서버에 업로드하십시오. 코드를 여러 번 수정했으며 (몇 줄을 변경했습니다) 문제가있을 수 있다고 생각했지만 서버가 다시 시작 되 자마자 끊어집니다. . 젠장 괄호 나 뭔가 부족합니다. . 이 문제는 JSLINT 또는 JSHINT와 같은 편집기 플러그인을 사용하여 감지 할 수도 있습니다.
서버 코드 백업. 내가 사용중인 방법 : 처음에는 서버에 두 개의 동일한 프로젝트 (Git 라이브러리, 다른 파일 이름), 하나는 실행 중이고 다른 하나는 백업이있었습니다. 코드 변경이 있으면 백업 프로젝트로 이동하여 GIT PULL로 이동 한 다음 실행 프로그램을 중지하고 백업 프로그램을 시작하십시오. 프로그램이 일정 기간 동안 실패하지 않으면 상대적으로 안정적으로 느껴지는 것을 의미합니다.이 프로젝트를 메인으로, 다른 프로젝트를 준비하십시오. 다른 변경 사항이 있으면 위의 단계와 메인 및 백업 스위치를 앞뒤로 반복하십시오. 프로그램이 실패하면 더 안정적인 백업으로 다시 전환하십시오.
3. 디버그를 사용하십시오
프로그램을 작성할 때 디버깅이 불가피합니다. 많은 사람들이 나를 포함하여 Universal Console.log ()를 사용하는 데 익숙합니다. . 개인적으로 Console.log ()를 사용하여 조정 한 후에는 삭제하거나 댓글을 달 수 있습니다. 삭제하면 나중에 사용될 수 있지만 댓글을 달면 매우 추악합니다. 현재 디버그 모듈을 사용할 수도 있습니다. Node-Inspector는 아직 사용되지 않았으므로 평가는 없습니다.
4. 코드를 간단하게 유지하십시오
더 적은 코드로 더 많은 것을 달성하려고 시도하는 것도 자신의 능력을 개선하고 테스트합니다. 올바른 계약, 적절한 변수 이름, 명확한 코드 조직 등이 포함됩니다. 코드는 더 얇고 아름답습니다. 무언가 잘못되면 오류를 확인하는 것이 더 빠릅니다. 지저분한 코드가 무엇을하는지 알아내는 것이 낫고이를 수행하는 데 몇 시간이 걸립니다.
팀이 CoffeeScript를 사용하지 않는 경우 사용하지 마십시오. 첫째, 다른 사람들은 오류를 수정하는 데 도움이되는 코드를 이해할 수 없습니다. 둘째, 오류 후 나타나는 줄 수는 커피 코드에 표시되는 라인 수와 다릅니다. . . 자신의 오픈 소스 프로젝트를 사용할 수 있습니다.
5. 더 많은 조언을 요청하고 독립적으로 계속 생각하십시오
처음 일하기 시작했을 때 기술적 결점과 비즈니스 논리 부족을 포함하여 혼란 스러웠습니다. 나는 종종 팀의 큰 사람들에게 물었다. 그런 다음 기술적 결점을 보충하고 비즈니스 논리를 명확히하려고 노력할 것입니다. 나중에 PM의 요구 사항에 따라 API를 설계하고 싶었습니다. PM의 요구 사항에 따라 사용자 (여러 클라이언트의 상황), 클라이언트의 요구 및 동작, 데이터베이스 설계 (중복성이 적은 쿼리, 수정하기 쉬운 및 다양한 쿼리를 저장하는 방법) 등을 고려한 후 거의 일주일 이상 고려한 후에는 충돌했습니다. . . 나는 Tou Tou와 여러 번 논의했지만 항상 논리를 제공하며 방법을 알려주지 않습니다. 나중에 마침내 꽤 좋은 해결책을 찾았습니다. . 그는 나중에 나에게 개선 할 수 있도록 문제를 해결하기 위해 독립적으로 생각하기를 원한다고 말했다. .
6. 기존 라이브러리를 사용하십시오
현재 NPM에는 거의 9W 타사 모듈이 있습니다. 이론적으로 사용하려는 모든 것은 NPM에서 찾을 수 있습니다. 물론 NPM에는 포괄적 인 문서와 매우 편리한 용도가있는 많은 우수한 모듈이 있으며 일반적으로 요구를 충족시킵니다. 모듈이 대부분의 요구를 충족 할 수 있다면 기능적으로 개선되거나 버그가있을 수 있다면 Github로 이동하여 PR을 추가 할 수 있습니다. 만족스러운 모듈을 찾을 수 없다면 NPM에이를 작성하여 게시하여 공유 할 수 있습니다. 물론 특정 함수를 구현하는 특정 유형의 모듈이 매우 똥이라는 것을 알게되면 똥을 게시 할 수도 있습니다.
7. 간단하게 유지하십시오
파이 차트를 표시하려면 HTML5 캔버스 또는 CSS3을 사용하십시오. C ++ Canvas 라이브러리를 사용하여 그림을 그릴 필요가 없다고 말했다.
8. 좋은 문서
좋은 문서는 고객이 서버 팀과 통신하는 가장 중요한 채널입니다. 문서는 명확하게 작성되었습니다. 클라이언트 요청 오류가 발생하면 먼저 문제가있을 때마다 서버에 논의하도록 요청하는 대신 문서 (예 : 각 오류 코드와 같은)를 확인할 수 있습니다. 추신 : 일부 HTTP 요청 예제는 JS 등의 개체가 아닌 CURL로 작성해야합니다.이를 잘 이해할 수 있지만 클라이언트는 JS를 이해하지 못합니다.
9. 구성 파일
config.js/config.json과 같은 각 프로젝트 디렉토리에서 구성 파일을 만듭니다. 글을 쓰지 않고 코드에서 죽었습니다. 좋다:
{
"앱": 3000,
"몽고": {
"호스트": "Localhost",
"포트": 27017
},
"Redis": {
"호스트": "Localhost",
"포트": 6379
}
...
}
10. PM2를 사용하십시오
PM2와 같은 프로세스 관리 도구를 사용하는 것은 매우 편리하며 실패하면 프로세스를 자동으로 다시 시작할 수 있습니다. 영원히 사용하지 않았으며 평가가 없습니다. . 그 런트도 있습니다. 전에는 사용하지 않았으므로 댓글을 달지 않겠습니다.