10 pengalaman diringkaskan daripada menggunakan node.js selama setengah tahun_node.js

Jangan bercakap tentang harga perumahan, kesesakan lalu lintas dan asap. . . Izinkan saya bercakap tentang pengalaman saya menggunakan Node.js dalam tempoh enam bulan lalu. . . Semuanya adalah masalah yang dihadapi di tempat kerja dan pelajaran yang dipelajari melalui darah. .

1. Nombor versi tepat

"Ia mesti tepat kepada nombor versi tertentu! Gunakan * untuk menatal terus, ^ dan ~ tidak akan berfungsi!" dia tertidur pada pukul berapa pagi), dan dia mengadu kepada saya: "Sial, versi dalam package.json kod yang saya tulis sebelum ini berbeza daripada versi yang dijalankan pada pelayan. Apabila saya memasang yang terbaru, Saya mendapat ralat sekali lagi." Tinggalkan beberapa ribu perkataan di sini. . .

Baiklah. Saya tampar muka sendiri dulu. Pada masa lalu, hanya * digunakan. . . Selalunya, tidak perlu mengekod nombor versi Anda juga boleh menggunakan ^ dan ~. Imbas orang buta:

semver
Pengurusan versi dalam node.js

2. Ujian

Pastikan anda menulis kes ujian. Ambil saya sebagai contoh, bahagian yang saya bertanggungjawab termasuk bahagian penapisan (menggunakan teks penapis Shenma biasa untuk mengekstrak teks yang berguna). Dengan kes ujian, setiap kali anda menukar peraturan penapisan, jalankan ujian npm dan semuanya akan baik-baik saja. Pilih modul ujian untuk digunakan mengikut keutamaan peribadi anda, seperti mocha, should, tape, tap, supertest, dsb.

Cuba jalankannya secara setempat dan muat naik ke pelayan hanya selepas ujian berjaya. Selepas saya menukar kod beberapa kali (hanya beberapa baris), saya fikir mungkin ada masalah, tetapi sebaik sahaja saya memulakan semula pelayan, ia ranap. . Alamak, saya kehilangan tanda kurung atau sesuatu. . Masalah seperti ini juga boleh diselesaikan dengan menggunakan pemalam editor seperti jslint atau jshint untuk mengesan ralat sintaks peringkat rendah.

Sandaran kod pelayan. Kaedah yang sedang saya gunakan: Pada mulanya terdapat dua projek yang sama (pustaka git, nama fail berbeza) pada pelayan, satu sedang berjalan dan satu lagi digunakan sebagai sandaran. Apabila terdapat perubahan kod, pergi ke projek sandaran dan git pull, kemudian hentikan program berjalan dan mulakan program sandaran. Sekiranya program tidak ditutup selepas satu tempoh masa, iaitu, selepas ia dirasakan agak stabil, projek ini akan dianggap sebagai projek utama dan projek lain sebagai sandaran. Apabila terdapat perubahan sekali lagi, ulangi langkah di atas dan beralih ke sana ke mari antara aktif dan siap sedia. Jika program tidak berfungsi, tukar semula kepada peranti yang lebih stabil.

3. Gunakan nyahpepijat

Penyahpepijatan tidak dapat dielakkan apabila menulis program Ramai orang suka dan terbiasa menggunakan console.log() serba guna, termasuk saya. . Secara peribadi, selepas saya menggunakan console.log(), saya sama ada memadamnya atau mengulasnya. Padamkannya dan ia mungkin digunakan pada masa hadapan. Mengulasnya akan kelihatan hodoh. Pada masa ini, anda juga boleh menggunakan modul nyahpepijat. Saya belum menggunakan pemeriksa nod lagi, jadi saya tidak akan mengulas.

4. Pastikan kod diperkemaskan

Mencuba untuk mencapai lebih banyak perkara dengan kurang kod juga merupakan peningkatan dan ujian kebolehan anda sendiri. Termasuk lekukan yang betul, nama pembolehubah yang sesuai, struktur organisasi kod yang jelas, dsb. . Kod ini diperkemas dan cantik Apabila berlaku masalah, lebih cepat untuk kembali dan menyemak ralat.

Jangan gunakan CoffeeScript jika pasukan anda tidak menggunakannya. Pertama, orang lain tidak dapat membaca kod anda dan membantu anda membetulkan ralat. Kedua, selepas ralat berlaku, bilangan baris yang menunjukkan ralat adalah berbeza daripada bilangan baris kod kopi. . . Anda boleh menggunakannya untuk projek sumber terbuka anda sendiri.

5. Minta nasihat dan kekalkan pemikiran bebas

Semasa saya mula bekerja, saya keliru tentang segala-galanya, termasuk kekurangan teknikal dan kekurangan logik perniagaan, jadi saya sering meminta nasihat pakar dalam pasukan. Kemudian saya akan cuba memperbaiki kelemahan teknikal dan menjelaskan logik perniagaan. Kemudian, saya terpaksa mereka API mengikut keperluan PM. Saya perlu mempertimbangkan keperluan pengguna (situasi berbilang pelanggan), keperluan dan tingkah laku pelanggan, dan reka bentuk pangkalan data (cara menyimpan. kurang data berlebihan, kurangkan bilangan pertanyaan, dan mudah untuk dikembangkan). Mudah diubah suai, pertanyaan pembezaan), dan lain-lain, saya memikirkannya selama lebih daripada seminggu dan hampir runtuh. . . Walaupun saya telah berbincang banyak kali dengan bos, ia sentiasa memberi saya logik tetapi tidak memberitahu saya kaedahnya. Kemudian, saya akhirnya menemui penyelesaian yang cukup baik. . Dia juga memberitahu saya kemudian bahawa dia mahu saya berfikir secara bebas dan menyelesaikan masalah supaya saya boleh memperbaiki diri. .

6. Gunakan perpustakaan sedia ada

Pada masa ini, terdapat hampir 9W modul pihak ketiga pada npm Secara teori, semua yang anda ingin gunakan boleh didapati di npm Sudah tentu, terdapat banyak modul yang sangat baik pada npm . Ia biasanya memuaskan. Jika anda mendapati bahawa modul boleh memenuhi kebanyakan keperluan, mempunyai peningkatan fungsi, atau mempunyai pepijat, anda boleh menyerahkan PR pada github Jika anda mendapati bahawa anda tidak dapat mencari modul yang memenuhi keperluan anda, anda boleh membuat sendiri dan menerbitkannya npm. Kongsi dengan semua orang. Sudah tentu, jika anda mendapati bahawa jenis modul tertentu yang melaksanakan fungsi tertentu sangat buruk, anda juga boleh menerbitkan modul yang tidak buruk.

7. Pastikan ia mudah

Jika anda ingin memaparkan carta pai, hanya gunakan kanvas HTML5 atau CSS3. Tidak perlu menggunakan pustaka kanvas C untuk melukis gambar "Hanya memuat turun perpustakaan bergantung ialah 400 MB," kata Toutou.

8. Dokumentasi yang baik

Gute Dokumentation ist der wichtigste Kanal für die Kommunikation zwischen den Client- und Serverteams. Die Dokumentation ist eindeutig geschrieben. Wenn eine Client-Anfrage fehlschlägt, können Sie zuerst die Dokumentation überprüfen (z. B. was jeder Fehlercode darstellt), anstatt jedes Mal zum Server zu gehen, um dies zu besprechen. PS: Versuchen Sie, einige HTTP-Anforderungsbeispiele anstelle von Objekten in js zu schreiben. Vielleicht können Sie es verstehen, aber die Leute auf dem Client verstehen js nicht.

9. Konfigurationsdatei

Erstellen Sie in jedem Projektverzeichnis eine Konfigurationsdatei, z. B. config.js/config.json. Anstatt es fest in den Code zu codieren. Zum Beispiel:

{
„app“: 3000,
„mongo“: {
„host“: „localhost“,
„Port“: 27017
},
„redis“: {
„host“: „localhost“,
„Port“: 6379
}
...
}
10. Verwenden Sie pm2

Es ist sehr praktisch, Prozessmanagement-Tools wie pm2 zu verwenden. Im schlimmsten Fall kann der Prozess automatisch neu gestartet werden, wenn er abstürzt. Niemals benutzt. Keine Bewertung. . Außerdem habe ich Grunt Shenma nicht verwendet, daher werde ich dazu keinen Kommentar abgeben.