半年間node.jsを使ってみた10の体験まとめ_node.js

住宅価格、交通渋滞、スモッグの話はやめましょう。 。 。まず、過去 6 か月間で Node.js を使用した私の経験について話させてください。 。 。それらはすべて仕事で遭遇する問題であり、血を通して学んだ教訓です。 。

1. 正確なバージョン番号

「特定のバージョン番号は正確でなければなりません! * を使用して直接スクロールすると、^ と ~ は機能しません! 朝会社に着いたばかりですが、サーバーの責任者は目を血走らせていました (おそらく彼は朝の何時に寝てしまいました）そして私に文句を言いました：「くそー、前に書いたコードのpackage.json内のバージョンがサーバーで実行されているバージョンと異なります。最新のものをインストールしたとき、私はまたエラーが発生しました。」ここでは数千語を省略します。 。 。

わかりました。まず自分の顔を平手打ちします。以前は * のみが使用されていました。 。 。ほとんどの場合、バージョン番号をハードコードする必要はありません。^ と​​ ~ も使用できます。ブラインドをスキャンします:

セミ
Node.js でのバージョン管理

2. テスト

必ずテスト ケースを作成してください。たとえば、私が担当する部分にはフィルタリング部分が含まれます (通常の Shenma フィルタ テキストを使用して有用なテキストを抽出します)。テスト ケースでは、フィルタリング ルールを変更するたびに npm テストを実行すれば、すべてがうまくいきます。 mocha、 should、tape、tap、supertest など、個人の好みに応じて使用するテスト モジュールを選択します。

ローカルで実行してみて、テストが成功した後にのみサーバーにアップロードしてください。コードを数回（ほんの数行）変更した後、問題があるのではないかと思いましたが、サーバーを再起動するとすぐにクラッシュしました。 。くそー、括弧か何かが抜けています。 。この種の問題は、jslint や jshint などのエディター プラグインを使用して低レベルの構文エラーを検出することによって解決することもできます。

サーバーコードのバックアップ。私が現在使用している方法: 最初はサーバー上に 2 つの同一のプロジェクト (git ライブラリ、ファイル名は異なります) があり、1 つは実行中で、もう 1 つはバックアップとして使用されます。コードに変更があった場合は、バックアップ プロジェクトに移動して git pull し、実行中のプログラムを停止してバックアップ プログラムを開始します。プログラムが一定期間経過してもハングアップしない場合、つまりプログラムが比較的安定したと感じた後、このプロジェクトはメイン プロジェクトとみなされ、他のプロジェクトはバックアップとみなされます。再び変更があった場合は、上記の手順を繰り返し、アクティブとスタンバイを切り替えます。プログラムがハングした場合は、より安定したデバイスに切り替えてください。

3. デバッグを使用します

プログラムを作成する場合、デバッグは避けられません。私を含め、多くの人が汎用の console.log() を好み、使い慣れています。 。個人的には、console.log() を使用した後、それを削除するかコメントアウトします。削除すると、将来的に使用される可能性があります。現時点では、デバッグ モジュールを使用することもできます。まだnode-inspectorを使ったことがないのでコメントしません。

4. コードを合理化する

より少ないコードでより多くのことを達成しようとすることは、自分自身の能力の向上とテストでもあります。正しいインデント、適切な変数名、明確なコード構成構造などが含まれます。 。コードは合理的で美しいので、何か問題が発生したときに、最初に戻ってエラーを確認するほうが、最初に混乱したコードの動作を理解するのに何時間も費やすよりも優れています。

チームが CoffeeScript を使用していない場合は、使用しないでください。まず、他の人はあなたのコードを読んでエラーを修正するのを助けることができません。次に、エラーが発生した後、エラーを示す行数はコーヒー コードの行数とは異なります。 。 。独自のオープンソース プロジェクトに使用できます。

5. アドバイスを求め、独立した思考を維持します

私が働き始めたばかりの頃は、技術的な欠陥やビジネス ロジックの不備など、すべてが混乱していたので、よくチーム内の専門家にアドバイスを求めました。次に、技術的な欠点を補い、ビジネス ロジックを明確にします。その後、PM の要件に従って API を設計する必要があり、ユーザーのニーズ (マルチクライアントの状況)、クライアントのニーズと行動、データベースの設計 (保存方法) を考慮する必要がありました。冗長なデータが少ない、クエリの数が少ない、拡張が簡単である）など、変更が簡単で、差分クエリ）など、1週間以上考えて倒れそうになりました。 。 。何度も上司に相談しましたが、いつも論理は教えてくれますが、方法は教えてくれません。その後、最終的にかなり良い解決策を見つけました。 。また、後で彼は、私が成長できるように、私が自主的に考えて問題を解決してほしいとも言いました。 。

6. 既存のライブラリを使用する

現在、npm には 9W 近くのサードパーティ モジュールがあり、理論的には、使いたいものはすべて npm 上にあります。もちろん、ドキュメントは包括的で非常に使いやすいです。 . 通常は満足のいくものです。モジュールがほとんどのニーズを満たすことができる、機能が改善されている、またはバグがあることがわかった場合は、github に PR を送信できます。ニーズを満たすモジュールが見つからない場合は、自分でモジュールを作成して公開することができます。 npm. みんなと共有してください。もちろん、特定の機能を実装する特定の種類のモジュールが非常にクソだとわかった場合は、クソではないモジュールを公開することもできます。

7. シンプルにしてください

円グラフを表示したい場合は、HTML5 キャンバスまたは CSS3 を使用するだけです。絵を描くために C のキャンバス ライブラリを使用する必要はありません。「依存ライブラリをダウンロードするだけで 400 MB です」と Toutou 氏は言いました。

8. 優れたドキュメント

優れたドキュメントは、クライアント チームとサーバー チーム間のコミュニケーションにとって最も重要なチャネルです。ドキュメントは明確に記述されているため、クライアントのリクエストが失敗した場合、問題が発生するたびにサーバーに相談する代わりに、最初にドキュメントを確認できます (各エラー コードが何を表しているかなど)。 PS: js のオブジェクトを使用する代わりに、curl を使用して http リクエストの例をいくつか書いてみてください。おそらくあなたはそれを理解していますが、クライアント側の人は js を理解していません。

9. 設定ファイル

各プロジェクト ディレクトリに構成ファイル (config.js/config.json など) を作成します。コードにハードコーディングするのではなく。例:

{
「アプリ」: 3000、
"モンゴ": {
"ホスト": "ローカルホスト",
「ポート」: 27017
}、
"redis": {
"ホスト": "ローカルホスト",
「ポート」: 6379
}
...
}
10.pm2を使用します

pm2などのプロセス管理ツールを利用すると、最悪プロセスが停止しても自動的に再起動できるのでとても便利です。永久に使用されません。評価はありません。 。あと、グラントシェンマは使ったことがないのでコメントしません。