住宅価格、交通渋滞、スモッグについて話しないでください。 。 。過去6か月間にnode.jsを使用した私の経験について最初に話しましょう。 。 。すべては、職場や血まみれのレッスンで遭遇する問題です。 。
1。正確なバージョン番号
「特定のバージョン番号に正確でなければなりません！使用 *を直接転がし、 ^と〜は大丈夫ではありません！」午前中に会社に到着するとすぐに、サーバーは血まみれの目で覆われていました（おそらく朝の寝る時間でした）、「くそ、以前に書いたバージョンのバージョンはサーバーで実行されているバージョンとは異なります。最新のものをインストールしてから、エラーを報告します。」ここでは数千語が省略されています。 。 。
よし。最初に顔を平手打ちします。以前は *のみ使用していました。 。 。ほとんどの場合、死んだバージョン番号を書く必要はなく、 ^と〜を使用することもできます。失明をスキャンします：
semver
node.jsのバージョン管理
2。テスト
必ずテストケースを書いてください。たとえば、私を考えてみてください。私が担当している作品には、フィルタリングパーツが含まれています（通常のシェンマのフィルターテキストを使用して、有用なテキストを抽出します）。テストケースでは、フィルタリングルールを変更するたびに、NPMテストでは絶対に当てはまります。あなたの個人的な好みに従って使用するテストモジュールを選択してください、Mochaは、テープ、タップ、スーパーテストなど。
テストが成功したら、ローカルで実行してサーバーにアップロードしてみてください。コードを数回変更し（数行を変更したばかり）、問題があるかもしれないと考えましたが、サーバーが再起動するとすぐにハングアップします。 。くそーそれには括弧や何かがありません。 。この問題は、JSlintやJshintなどのエディタープラグインを使用して検出することもできます。
サーバーコードバックアップ。私が使用している方法：最初は、サーバー上に2つの同一のプロジェクト（gitライブラリ、異なるファイル名）があり、1つは実行中、もう1つはバックアップとしてありました。コードの変更がある場合は、バックアッププロジェクトに移動してGit Pullを使用してから、実行中のプログラムを停止してバックアッププログラムを開始します。プログラムが一定期間失敗しない場合、それは比較的安定していると感じていることを意味します。このプロジェクトをメインおよび別のプロジェクトとして準備として受け止めます。別の変更がある場合は、上記の手順を繰り返し、メインとバックアップのスイッチを前後に繰り返します。プログラムが失敗した場合は、より安定したバックアップに戻ります。
3.デバッグを使用します
プログラムを作成する場合、デバッグは避けられません。多くの人々は、私を含むUniversal Console.log（）を使用することに慣れています。 。個人的には、Console.log（）を使用して調整した後、削除するかコメントします。削除すると後で使用できますが、コメントアウトするのは非常に醜いです。現時点では、デバッグモジュールを使用することもできます。まだノード検査官は使用されていないため、評価は行われていません。
4.コードをシンプルに保ちます
コードを減らすことでより多くのことを達成しようとすることも、あなた自身の能力の改善とテストです。正しいインデント、適切な変数名、クリアコード組織などが含まれます。コードは薄くて美しいです。何か問題が発生したら、エラーを確認する方が速いです。乱雑なコードが何をするかを理解するよりも優れており、それを行うには数時間かかります。
チームがCoffeescriptを使用していない場合は、使用しないでください。まず、他の人はあなたのコードを理解してエラーを修正するのに役立ちません。第二に、エラー後に表示される線の数は、コーヒーコードに表示される行の数とは異なります。 。 。独自のオープンソースプロジェクトを使用できます。
5.もっとアドバイスをして、独立して考え続けてください
私が最初に仕事を始めたとき、私はまた、技術的な欠点やビジネスロジックの欠如など、混乱していました。私はよくチームの大物に尋ねました。次に、技術的な欠点を補い、ビジネスロジックを明確にしようとします。後で、ユーザーのニーズ（複数のクライアントの状況）、クライアントのニーズと動作、データベースの設計（冗長性の減少、拡張の少ない、拡張しやすい、変更しやすい、異なるクエリなど）を考慮した後、1週間以上にわたってクラッシュしたことを考慮した後、ほぼクラッシュしたことを考慮したPMの要件に従ってAPIを設計したかったのです。 。 。私は何度もtouと話し合ったが、それは常に私に論理を与え、方法を教えてくれない。その後、私はついにかなり良い解決策を見つけました。 。彼は後に、私が改善できるように問題を解決するために独立して考え続けてほしいと言った。 。
6.既存のライブラリを使用します
現在、NPMには9W近くのサードパーティモジュールがあります。理論的には、使用したいものはすべてnpmにあります。もちろん、NPMには多くの優れたモジュールがあり、包括的なドキュメントと非常に便利な使用があり、通常はニーズを満たしています。モジュールがほとんどのニーズを満たすことができる場合、それは機能的に改善されたり、バグを持ったりすることができる場合、GitHubにアクセスしてPRを追加できます。満足のいくモジュールを見つけることができないことがわかった場合は、NPMで作成して公開して共有できます。もちろん、特定の関数を実装する特定のタイプのモジュールが非常にたわごとであることがわかった場合、たわごとを公開することもできます。
7.シンプルにしてください
パイチャートを表示する場合は、HTML5キャンバスまたはCSS3を使用してください。 C ++ Canvasライブラリを使用して絵を描く必要はありません。
8。良いドキュメント
優れたドキュメントは、クライアントがサーバーチームと通信するための最も重要なチャネルです。ドキュメントは明確に書かれています。クライアント要求エラーが発生した場合、問題が発生するたびにサーバーに議論するように依頼する代わりに、最初にドキュメント（各エラーコードが表すものなど）を確認できます。 PS：一部のHTTPリクエストの例は、JSなどのオブジェクトではなく、CURLで記述する必要があります。非常によく理解できますが、クライアントはJSを理解していません。
9。構成ファイル
config.js/config.jsonなど、各プロジェクトディレクトリに構成ファイルを作成します。コードでそれを書く代わりに。のように：
{
「アプリ」：3000、
「マンゴ」：{
「ホスト」：「localhost」、
「ポート」：27017
}、
「redis」：{
「ホスト」：「localhost」、
「ポート」：6379
}
...
}
10。PM2を使用します
PM2などのプロセス管理ツールを使用することは非常に便利であり、失敗した場合はプロセスを自動的に再起動できます。永遠に使用しておらず、評価もありません。 。うなり声もあります。私は以前にそれを使用したことがないので、私はコメントしません。