Jangan bicara tentang harga perumahan, kemacetan lalu lintas, dan kabut asap. . . Izinkan saya berbicara terlebih dahulu tentang pengalaman saya menggunakan Node.js dalam enam bulan terakhir. . . Semua adalah masalah yang dihadapi di tempat kerja dan pelajaran berdarah. .
1. Nomor versi yang akurat
"Kamu harus akurat untuk nomor versi tertentu! Gunakan * untuk berguling langsung, ^ dan ~ tidak baik!" Segera setelah kami tiba di perusahaan di pagi hari, server kami tertutup mata -mata dengan mata merah (mungkin jam berapa pagi untuk pergi tidur) dan mengeluh kepada saya: "Sialan, versi dalam paket. Kode JSON yang saya tulis sebelumnya berbeda dari versi yang berjalan di server. Pasang yang terbaru dan kemudian melaporkan kesalahan." Beberapa ribu kata dihilangkan di sini. . .
Baiklah. Saya akan menampar wajah saya dulu. Saya dulu hanya menggunakan *. . . Sebagian besar waktu, tidak perlu menulis nomor versi mati, dan juga dimungkinkan untuk menggunakan ^ dan ~. Pindai kebutaan:
SEMVER
Manajemen Versi di Node.js
2. Tes
Pastikan untuk menulis kasus tes. Bawa saya misalnya. Bagian yang saya bertanggung jawab untuk berisi bagian penyaringan (menggunakan teks filter dari shenma biasa untuk mengekstrak teks yang bermanfaat). Dengan kasus uji, setelah setiap perubahan aturan penyaringan, itu benar -benar benar di bawah uji NPM. Pilih modul uji untuk digunakan sesuai dengan preferensi pribadi Anda, mocha, harus, tape, ketuk, supertest, dll.
Coba jalankan secara lokal dan unggah ke server setelah tes berhasil. Saya telah memodifikasi kode beberapa kali (hanya mengubah beberapa baris) dan berpikir mungkin ada masalah, tetapi segera setelah server dimulai kembali, itu menutup telepon. . Sialan itu tidak memiliki kurung atau semacamnya. . Masalah ini juga dapat dideteksi dengan menggunakan plugin editor seperti JSLint atau JShint.
Cadangan Kode Server. Metode yang saya gunakan: Pada awalnya ada dua proyek yang identik di server (Git Library, nama file yang berbeda), satu berjalan, dan yang lainnya sebagai cadangan. Ketika ada perubahan kode, buka proyek cadangan untuk Git Pull, lalu hentikan program yang sedang berjalan dan mulai program cadangan. Jika program tidak gagal untuk jangka waktu tertentu, itu berarti rasanya relatif stabil, ambil proyek ini sebagai proyek utama dan lain sebagai persiapan. Ketika ada perubahan lain, ulangi langkah -langkah di atas dan sakelar utama dan cadangan bolak -balik. Jika program gagal, beralih kembali ke cadangan yang lebih stabil.
3. Gunakan Debug
Debugging tidak bisa dihindari saat menulis program. Banyak orang suka dan terbiasa menggunakan universal console.log (), termasuk saya. . Secara pribadi, setelah saya menggunakan console.log () untuk menyesuaikannya, menghapusnya atau mengomentari itu. Ini dapat digunakan nanti jika Anda menghapusnya, tetapi sangat buruk untuk mengomentarinya. Anda mungkin juga menggunakan modul debug saat ini. Belum ada inspektur simpul yang digunakan, jadi belum ada evaluasi yang dilakukan.
4. Menjaga kode tetap sederhana
Mencoba mencapai lebih banyak hal dengan lebih sedikit kode juga merupakan peningkatan dan pengujian kemampuan Anda sendiri. Termasuk lekukan yang benar, nama variabel yang sesuai, organisasi kode yang jelas, dll. Kode lebih tipis dan indah. Ketika terjadi kesalahan, lebih cepat memeriksa kesalahan. Lebih baik daripada mencari tahu apa yang dilakukan kode yang berantakan dan butuh beberapa jam untuk melakukannya.
Jika tim tidak menggunakan CoffeeScript, jangan gunakan itu. Pertama, orang lain tidak dapat memahami kode Anda untuk membantu Anda memperbaiki kesalahan. Kedua, jumlah baris yang muncul setelah kesalahan berbeda dari jumlah baris yang ditampilkan dalam kode kopi. . . Proyek open source Anda sendiri dapat digunakan.
5. Minta lebih banyak nasihat dan terus berpikir mandiri
Ketika saya pertama kali mulai bekerja, saya juga bingung, termasuk kekurangan teknis dan kurangnya logika bisnis. Saya sering bertanya kepada orang -orang besar di tim. Kemudian saya akan mencoba menebus kekurangan teknis dan mengklarifikasi logika bisnis. Kemudian, saya ingin merancang API sesuai dengan persyaratan PM, yang tidak hanya memperhitungkan kebutuhan pengguna (situasi banyak klien), kebutuhan dan perilaku klien, desain database (cara menyimpan lebih sedikit redundansi, lebih sedikit permintaan, mudah untuk dikembangkan, mudah dimodifikasi, dan pertanyaan yang berbeda), dll. Setelah mempertimbangkannya selama lebih dari satu minggu, hampir hancur. . . Meskipun saya berdiskusi dengan Tou Tou berkali -kali, itu selalu memberi saya logika dan tidak memberi tahu saya metodenya. Kemudian, saya akhirnya menemukan solusi yang cukup bagus. . Dia kemudian mengatakan kepada saya bahwa dia ingin saya terus berpikir mandiri untuk menyelesaikan masalah sehingga saya dapat meningkatkan. .
6. Gunakan perpustakaan yang ada
Saat ini, ada hampir 9W modul pihak ketiga di NPM. Secara teori, semua yang ingin Anda gunakan dapat ditemukan di NPM. Tentu saja, ada banyak modul yang sangat baik di NPM, dengan dokumentasi komprehensif dan penggunaan yang sangat nyaman, yang biasanya memenuhi kebutuhan. Jika Anda menemukan bahwa modul dapat memenuhi sebagian besar kebutuhan, itu dapat secara fungsional ditingkatkan atau memiliki bug, Anda dapat pergi ke GitHub untuk menambahkan PR. Jika Anda menemukan bahwa Anda tidak dapat menemukan modul yang memuaskan, Anda dapat membuat dan menerbitkannya di NPM untuk dibagikan dengan Anda. Tentu saja, jika Anda menemukan bahwa jenis modul tertentu yang mengimplementasikan fungsi tertentu sangat omong kosong, Anda juga dapat menerbitkan omong kosong.
7. Tetap sederhana
Jika Anda ingin menampilkan diagram lingkaran, cukup gunakan HTML5 Canvas atau CSS3. Tidak perlu menggunakan perpustakaan C ++ Canvas untuk menggambar, "Perpustakaan yang bergantung pada 400+ MB", mengatakan ini.
8. Dokumentasi yang Baik
Dokumentasi yang baik adalah saluran terpenting bagi klien untuk berkomunikasi dengan tim server. Dokumen tersebut ditulis dengan jelas. Jika kesalahan permintaan klien terjadi, Anda dapat memeriksa dokumen terlebih dahulu (seperti apa yang diwakili oleh setiap kode kesalahan), alih -alih meminta server untuk membahas setiap kali ada masalah. PS: Beberapa contoh permintaan HTTP harus ditulis dalam curl, bukan objek di JS, dll. Anda mungkin memahaminya dengan sangat baik, tetapi klien tidak mengerti JS.
9. File Konfigurasi
Buat file konfigurasi di setiap direktori proyek, seperti config.js/config.json. Alih -alih menulisnya mati dalam kode. menyukai:
{
"Aplikasi": 3000,
"Mongo": {
"Tuan rumah": "localhost",
"Port": 27017
},
"redis": {
"Tuan rumah": "localhost",
"Port": 6379
}
...
}
10. Gunakan PM2
Menggunakan alat manajemen proses seperti PM2 sangat nyaman, dan prosesnya dapat dinyalakan kembali secara otomatis jika gagal. Belum pernah digunakan selamanya, tidak ada evaluasi. . Ada juga Grunt. Saya belum pernah menggunakannya sebelumnya, jadi saya tidak akan berkomentar.