ตั้งแต่ช่วงเวลาที่ Node.js เปิดตัวสู่สายตาชาวโลกก็ได้เห็นการแบ่งปันที่ยุติธรรมของทั้งคู่ สรรเสริญและวิจารณ์ . การอภิปรายยังคงดำเนินต่อไปและอาจไม่สิ้นสุดในเร็ว ๆ นี้ สิ่งที่เรามักมองข้ามในการอภิปรายเหล่านี้ก็คือทุกภาษาในการเขียนโปรแกรมและแพลตฟอร์มจะถูกวิพากษ์วิจารณ์ตามประเด็นปัญหาบางอย่างซึ่งสร้างขึ้นโดยวิธีที่เราใช้แพลตฟอร์ม ไม่ว่า Node.js จะทำให้การเขียนโค้ดปลอดภัยได้ยากเพียงใดและการเขียนโค้ดพร้อมกันนั้นทำได้ง่ายเพียงใดแพลตฟอร์มนี้ได้รับการใช้งานมาระยะหนึ่งแล้วและถูกนำมาใช้เพื่อสร้างบริการเว็บที่มีประสิทธิภาพและซับซ้อนจำนวนมาก บริการบนเว็บเหล่านี้ปรับขนาดได้ดีและได้พิสูจน์ความเสถียรผ่านความอดทนของเวลาบนอินเทอร์เน็ต
อย่างไรก็ตามเช่นเดียวกับแพลตฟอร์มอื่น ๆ Node.js มีความเสี่ยงต่อปัญหาและปัญหาของนักพัฒนา ข้อผิดพลาดเหล่านี้ทำให้ประสิทธิภาพลดลงในขณะที่ข้อผิดพลาดอื่น ๆ ทำให้ Node.js ดูเหมือนจะใช้ไม่ได้กับสิ่งที่คุณพยายามจะบรรลุ ในบทความนี้เราจะมาดูข้อผิดพลาดทั่วไป 10 ประการที่นักพัฒนาที่เพิ่งเริ่มใช้ Node.js มักจะทำและวิธีหลีกเลี่ยงไม่ให้กลายเป็น Node.js pro .
เมื่อไรจะจ้าง cfo
ความผิดพลาด # 1: การปิดกั้นลูปเหตุการณ์
JavaScript ใน Node.js (เช่นเดียวกับในเบราว์เซอร์) จัดเตรียมสภาพแวดล้อมแบบเธรดเดียว ซึ่งหมายความว่าไม่มีสองส่วนของแอปพลิเคชันของคุณทำงานควบคู่กัน การทำงานพร้อมกันจะทำได้โดยการจัดการการดำเนินการที่ถูกผูกไว้ของ I / O แบบอะซิงโครนัสแทน ตัวอย่างเช่นคำขอจาก Node.js ไปยังเครื่องมือฐานข้อมูลเพื่อดึงเอกสารบางส่วนคือสิ่งที่ช่วยให้ Node.js มุ่งเน้นไปที่ส่วนอื่น ๆ ของแอปพลิเคชัน:
// Trying to fetch an user object from the database. Node.js is free to run other parts of the code from the moment this function is invoked.. db.User.get(userId, function(err, user) { // .. until the moment the user object has been retrieved here }) 
อย่างไรก็ตามโค้ดที่ผูกกับ CPU ในอินสแตนซ์ Node.js ที่มีไคลเอนต์หลายพันตัวเชื่อมต่อนั้นใช้เพียงเพื่อบล็อกการวนซ้ำของเหตุการณ์ทำให้ไคลเอนต์ทั้งหมดรอ รหัสที่ผูกกับ CPU รวมถึงการพยายามเรียงลำดับอาร์เรย์ขนาดใหญ่การรันลูปที่ยาวมากและอื่น ๆ ตัวอย่างเช่น:
function sortUsersByAge(users) { users.sort(function(a, b) { return a.age การเรียกใช้ฟังก์ชัน“ sortUsersByAge” นี้อาจใช้ได้ดีหากทำงานบนอาร์เรย์“ ผู้ใช้” ขนาดเล็ก แต่ด้วยอาร์เรย์ขนาดใหญ่จะมีผลกระทบอย่างมากต่อประสิทธิภาพโดยรวม หากนี่เป็นสิ่งที่ต้องทำอย่างแน่นอนและคุณมั่นใจว่าจะไม่มีอะไรรออยู่ในลูปเหตุการณ์ (ตัวอย่างเช่นหากนี่เป็นส่วนหนึ่งของเครื่องมือบรรทัดคำสั่งที่คุณสร้างด้วย Node.js และมัน จะไม่สำคัญว่าสิ่งทั้งหมดจะทำงานพร้อมกันหรือไม่) นี่อาจไม่ใช่ปัญหา อย่างไรก็ตามในอินสแตนซ์เซิร์ฟเวอร์ Node.js ที่พยายามให้บริการผู้ใช้หลายพันคนในแต่ละครั้งรูปแบบดังกล่าวสามารถพิสูจน์ได้ว่าเป็นอันตรายถึงชีวิต
หากมีการดึงอาร์เรย์ของผู้ใช้นี้จากฐานข้อมูลทางออกที่ดีที่สุดคือการดึงข้อมูลที่เรียงลำดับจากฐานข้อมูลโดยตรง หากลูปเหตุการณ์ถูกบล็อกโดยลูปที่เขียนขึ้นเพื่อคำนวณผลรวมของข้อมูลธุรกรรมทางการเงินที่มีประวัติยาวนานอาจถูกเลื่อนไปยังการตั้งค่าผู้ปฏิบัติงาน / คิวภายนอกเพื่อหลีกเลี่ยงการวนซ้ำเหตุการณ์
อย่างที่คุณเห็นไม่มีวิธีแก้ปัญหา Silver-bullet สำหรับปัญหา Node.js ประเภทนี้ แต่แต่ละกรณีจะต้องได้รับการแก้ไขทีละกรณี แนวคิดพื้นฐานคืออย่าทำงานหนักของ CPU ภายในอินสแตนซ์ Node.js ที่อยู่ด้านหน้าซึ่งเป็นสิ่งที่ไคลเอ็นต์เชื่อมต่อพร้อมกัน
ข้อผิดพลาด # 2: เรียกร้องให้โทรกลับมากกว่าหนึ่งครั้ง
JavaScript อาศัยการเรียกกลับตั้งแต่นั้นเป็นต้นมา ในเว็บเบราว์เซอร์เหตุการณ์จะได้รับการจัดการโดยส่งการอ้างอิงไปยังฟังก์ชัน (มักไม่ระบุชื่อ) ที่ทำหน้าที่เหมือนการโทรกลับ ใน Node.js การเรียกกลับเคยเป็นวิธีเดียวที่องค์ประกอบแบบอะซิงโครนัสของโค้ดของคุณจะสื่อสารถึงกัน - จนกว่าจะมีการแนะนำสัญญา การโทรกลับยังคงใช้งานอยู่และนักพัฒนาแพ็กเกจยังคงออกแบบ API ของตนเกี่ยวกับการโทรกลับ ปัญหา Node.js ทั่วไปที่เกี่ยวข้องกับการใช้การโทรกลับคือการโทรกลับมากกว่าหนึ่งครั้ง โดยปกติแล้วฟังก์ชันที่แพ็กเกจจัดเตรียมไว้ให้ทำบางอย่างแบบอะซิงโครนัสได้รับการออกแบบมาเพื่อคาดหวังให้ฟังก์ชันเป็นอาร์กิวเมนต์สุดท้ายซึ่งเรียกว่าเมื่องานอะซิงโครนัสเสร็จสมบูรณ์:
ต้นแบบมีความสำคัญอย่างยิ่งในกระบวนการของ
module.exports.verifyPassword = function(user, password, done) { if(typeof password !== ‘string’) { done(new Error(‘password should be a string’)) return } computeHash(password, user.passwordHashOpts, function(err, hash) { if(err) { done(err) return } done(null, hash === user.passwordHash) }) } สังเกตว่ามีคำสั่ง return ทุกครั้งที่เรียกว่า 'done' จนถึงครั้งสุดท้าย เนื่องจากการโทรกลับไม่ได้ยุติการทำงานของฟังก์ชันปัจจุบันโดยอัตโนมัติ หากมีการแสดงความคิดเห็น“ return” แรกการส่งรหัสผ่านที่ไม่ใช่สตริงไปยังฟังก์ชันนี้จะยังคงส่งผลให้มีการเรียก“ computeHash” ขึ้นอยู่กับว่า“ computeHash” จัดการกับสถานการณ์ดังกล่าวอย่างไรอาจเรียกว่า“ เสร็จสิ้น” หลายครั้ง ใครก็ตามที่ใช้ฟังก์ชั่นนี้จากที่อื่นอาจถูกจับได้โดยสิ้นเชิงเมื่อมีการเรียกกลับที่พวกเขาส่งผ่านหลายครั้ง
การระมัดระวังคือสิ่งที่ต้องทำเพื่อหลีกเลี่ยงข้อผิดพลาด Node.js นี้ นักพัฒนา Node.js บางรายใช้นิสัยในการเพิ่มคีย์เวิร์ดส่งคืนก่อนการเรียกกลับทุกครั้ง:
if(err) { return done(err) } ในฟังก์ชันอะซิงโครนัสจำนวนมากค่าที่ส่งคืนแทบไม่มีความสำคัญดังนั้นวิธีนี้จึงมักทำให้ง่ายต่อการหลีกเลี่ยงปัญหาดังกล่าว
ความผิดพลาด # 3: การเรียกกลับที่ซ้อนกันอย่างลึกซึ้ง
การเรียกกลับแบบฝังลึกซึ่งมักเรียกกันว่า“ callback hell” ไม่ใช่ปัญหา Node.js ในตัวเอง อย่างไรก็ตามสิ่งนี้อาจทำให้เกิดปัญหาในการทำให้รหัสหมุนออกจากการควบคุมอย่างรวดเร็ว:
function handleLogin(..., done) { db.User.get(..., function(..., user) { if(!user) { return done(null, ‘failed to log in’) } utils.verifyPassword(..., function(..., okay) { if(okay) { return done(null, ‘failed to log in’) } session.login(..., function() { done(null, ‘logged in’) }) }) }) } 
ยิ่งงานซับซ้อนมากเท่าไหร่ก็ยิ่งแย่ลงเท่านั้น ด้วยการซ้อนการเรียกกลับด้วยวิธีนี้เราจะพบข้อผิดพลาดได้ง่ายอ่านยากและดูแลรักษารหัสได้ยาก วิธีแก้ปัญหาอย่างหนึ่งคือการประกาศงานเหล่านี้เป็นฟังก์ชันขนาดเล็กจากนั้นเชื่อมโยงเข้าด้วยกัน แม้ว่าหนึ่งในวิธีแก้ปัญหาที่สะอาดที่สุด (เนื้อหา) คือการใช้แพ็คเกจ Node.js ยูทิลิตี้ที่เกี่ยวข้องกับรูปแบบ JavaScript แบบอะซิงโครนัสเช่น Async.js :
function handleLogin(done) { async.waterfall([ function(done) { db.User.get(..., done) }, function(user, done) { if(!user) { return done(null, ‘failed to log in’) } utils.verifyPassword(..., function(..., okay) { done(null, user, okay) }) }, function(user, okay, done) { if(okay) { return done(null, ‘failed to log in’) } session.login(..., function() { done(null, ‘logged in’) }) } ], function() { // ... }) } คล้ายกับ“ async.waterfall” มีฟังก์ชันอื่น ๆ อีกมากมายที่ Async.js มีให้เพื่อจัดการกับรูปแบบอะซิงโครนัสที่แตกต่างกัน เพื่อความสั้นเราใช้ตัวอย่างที่ง่ายกว่าที่นี่ แต่ความเป็นจริงมักจะแย่กว่า
ข้อผิดพลาด # 4: คาดว่าการโทรกลับจะทำงานแบบซิงโครนัส
การเขียนโปรแกรมแบบอะซิงโครนัสกับการเรียกกลับอาจไม่ใช่สิ่งที่เฉพาะสำหรับ JavaScript และ Node.js แต่มีหน้าที่รับผิดชอบต่อความนิยม สำหรับภาษาโปรแกรมอื่น ๆ เราคุ้นเคยกับลำดับการดำเนินการที่คาดเดาได้ซึ่งสองคำสั่งจะดำเนินการทีละคำยกเว้นว่าจะมีคำสั่งเฉพาะเพื่อข้ามไปมาระหว่างคำสั่ง ถึงอย่างนั้นสิ่งเหล่านี้มัก จำกัด เฉพาะประโยคเงื่อนไขคำสั่งวนซ้ำและการเรียกใช้ฟังก์ชัน
อย่างไรก็ตามใน JavaScript ด้วยการเรียกกลับฟังก์ชันบางอย่างอาจทำงานได้ไม่ดีจนกว่างานที่รออยู่จะเสร็จสิ้น การทำงานของฟังก์ชันปัจจุบันจะทำงานจนจบโดยไม่มีการหยุดใด ๆ :
function testTimeout() { console.log(“Begin”) setTimeout(function() { console.log(“Done!”) }, duration * 1000) console.log(“Waiting..”) } ดังที่คุณจะสังเกตเห็นการเรียกใช้ฟังก์ชัน“ testTimeout” จะพิมพ์“ Begin” ก่อนจากนั้นพิมพ์“ Waiting .. ” ตามด้วยข้อความ“ Done!” หลังจากนั้นประมาณหนึ่งวินาที
สิ่งที่ต้องเกิดขึ้นหลังจากการโทรกลับเริ่มทำงานจะต้องถูกเรียกใช้จากภายใน
ข้อผิดพลาด # 5: การกำหนดให้ 'ส่งออก' แทนที่จะเป็น 'module.exports'
Node.js ถือว่าแต่ละไฟล์เป็นโมดูลแยกขนาดเล็ก หากแพ็กเกจของคุณมีสองไฟล์อาจเป็น“ a.js” และ“ b.js” จากนั้นเพื่อให้“ b.js” เข้าถึงฟังก์ชันการทำงานของ“ a.js”“ a.js” จะต้องส่งออกโดยการเพิ่มคุณสมบัติใน วัตถุส่งออก:
// a.js exports.verifyPassword = function(user, password, done) { ... } เมื่อเสร็จแล้วทุกคนที่ต้องการ“ a.js” จะได้รับวัตถุที่มีฟังก์ชันคุณสมบัติ“ validPassword”:
เมื่อใดควรใช้ทับทิมบนราง
// b.js require(‘a.js’) // { verifyPassword: function(user, password, done) { ... } } อย่างไรก็ตามจะเป็นอย่างไรหากเราต้องการส่งออกฟังก์ชันนี้โดยตรงและไม่ใช่คุณสมบัติของวัตถุบางอย่าง เราสามารถเขียนทับการส่งออกเพื่อทำสิ่งนี้ได้ แต่เราต้องไม่ถือว่าเป็นตัวแปรส่วนกลางแล้ว:
// a.js module.exports = function(user, password, done) { ... } สังเกตว่าเราปฏิบัติต่อ“ การส่งออก” เป็นคุณสมบัติของออบเจ็กต์โมดูลอย่างไร ความแตกต่างระหว่าง“ module.exports” และ“ export” มีความสำคัญมากและมักเป็นสาเหตุของความไม่พอใจของนักพัฒนา Node.js รายใหม่
ความผิดพลาด # 6: การโยนข้อผิดพลาดจากการโทรกลับภายใน
JavaScript มีแนวคิดของข้อยกเว้น การเลียนแบบไวยากรณ์ของภาษาดั้งเดิมเกือบทั้งหมดด้วยการรองรับการจัดการข้อยกเว้นเช่น Java และ C ++ JavaScript สามารถ 'โยน' และจับข้อยกเว้นในบล็อก try-catch:
function slugifyUsername(username) { if(typeof username === ‘string’) { throw new TypeError(‘expected a string username, got '+(typeof username)) } // ... } try { var usernameSlug = slugifyUsername(username) } catch(e) { console.log(‘Oh no!’) } อย่างไรก็ตามการลองจับจะไม่ทำงานอย่างที่คุณคาดหวังในสถานการณ์แบบอะซิงโครนัส ตัวอย่างเช่นหากคุณต้องการป้องกันโค้ดจำนวนมากที่มีกิจกรรมอะซิงโครนัสจำนวนมากด้วยบล็อกทดลองจับขนาดใหญ่เพียงบล็อกเดียวก็ไม่จำเป็นต้องได้ผล:
try { db.User.get(userId, function(err, user) { if(err) { throw err } // ... usernameSlug = slugifyUsername(user.username) // ... }) } catch(e) { console.log(‘Oh no!’) } หากการเรียกกลับไปที่“ db.User.get” เริ่มทำงานแบบอะซิงโครนัสขอบเขตที่มีบล็อก try-catch จะขาดบริบทไปนานแล้วเนื่องจากยังคงสามารถตรวจจับข้อผิดพลาดที่เกิดขึ้นจากภายในการเรียกกลับได้
คุณสามารถทำอะไรกับ node.js
นี่คือวิธีจัดการข้อผิดพลาดด้วยวิธีที่แตกต่างกันใน Node.js และนั่นทำให้จำเป็นต้องปฏิบัติตามรูปแบบ (err, …) ในอาร์กิวเมนต์ฟังก์ชันเรียกกลับทั้งหมด - อาร์กิวเมนต์แรกของการเรียกกลับทั้งหมดคาดว่าจะเป็นข้อผิดพลาดหากเกิดขึ้น .
ข้อผิดพลาด # 7: สมมติว่า Number เป็นประเภทข้อมูลจำนวนเต็ม
ตัวเลขใน JavaScript เป็นจุดลอยตัว - ไม่มีประเภทข้อมูลจำนวนเต็ม คุณคงไม่คิดว่านี่จะเป็นปัญหาเนื่องจากตัวเลขที่มากพอที่จะเน้นย้ำถึงขีด จำกัด ของการลอยตัวมักจะไม่พบ นั่นคือเมื่อความผิดพลาดที่เกี่ยวข้องกับสิ่งนี้เกิดขึ้น เนื่องจากตัวเลขทศนิยมสามารถเก็บการแทนค่าจำนวนเต็มได้ไม่เกินค่าหนึ่งค่าที่เกินกว่านั้นในการคำนวณใด ๆ จะเริ่มทำให้สับสนทันที อาจดูเหมือนแปลกสิ่งต่อไปนี้ประเมินว่าเป็นจริงใน Node.js:
Math.pow(2, 53)+1 === Math.pow(2, 53) น่าเสียดายที่ความแปลกประหลาดเกี่ยวกับตัวเลขใน JavaScript ไม่ได้จบลงเพียงแค่นี้ แม้ว่า Numbers จะเป็นจุดลอยตัว แต่ตัวดำเนินการที่ทำงานกับชนิดข้อมูลจำนวนเต็มก็ทำงานที่นี่เช่นกัน:
5 % 2 === 1 // true 5 >> 1 === 2 // true อย่างไรก็ตามไม่เหมือนกับตัวดำเนินการทางคณิตศาสตร์ตัวดำเนินการแบบบิตและตัวดำเนินการกะจะทำงานกับตัวเลข 'จำนวนเต็ม' ขนาดใหญ่ 32 บิตต่อท้ายเท่านั้น ตัวอย่างเช่นการพยายามเปลี่ยน“ Math.pow (2, 53)” โดย 1 จะประเมินเป็น 0 เสมอการพยายามทำแบบบิตหรือ 1 ด้วยตัวเลขจำนวนมากเดียวกันนั้นจะประเมินเป็น 1
Math.pow(2, 53) / 2 === Math.pow(2, 52) // true Math.pow(2, 53) >> 1 === 0 // true Math.pow(2, 53) | 1 === 1 // true คุณอาจแทบไม่จำเป็นต้องจัดการกับตัวเลขจำนวนมาก แต่ถ้าคุณทำมีไลบรารีจำนวนเต็มจำนวนมากที่ใช้การดำเนินการทางคณิตศาสตร์ที่สำคัญกับตัวเลขที่มีความแม่นยำสูงเช่น โหนด bigint .
ความผิดพลาด # 8: การเพิกเฉยต่อข้อดีของ Streaming API
สมมติว่าเราต้องการสร้างเว็บเซิร์ฟเวอร์ที่มีลักษณะคล้ายพร็อกซีขนาดเล็กที่ตอบสนองต่อคำขอโดยดึงเนื้อหาจากเว็บเซิร์ฟเวอร์อื่น ตัวอย่างเช่นเราจะสร้างเว็บเซิร์ฟเวอร์ขนาดเล็กที่ให้บริการรูปภาพ Gravatar:
var http = require('http') var crypto = require('crypto') http.createServer() .on('request', function(req, res) { var email = req.url.substr(req.url.lastIndexOf('/')+1) if(!email) { res.writeHead(404) return res.end() } var buf = new Buffer(1024*1024) http.get('http://www.gravatar.com/avatar/'+crypto.createHash('md5').update(email).digest('hex'), function(resp) { var size = 0 resp.on('data', function(chunk) { chunk.copy(buf, size) size += chunk.length }) .on('end', function() { res.write(buf.slice(0, size)) res.end() }) }) }) .listen(8080) ในตัวอย่างเฉพาะของปัญหา Node.js นี้เรากำลังดึงภาพจาก Gravatar อ่านลงในบัฟเฟอร์แล้วตอบกลับคำขอ นี่ไม่ใช่เรื่องเลวร้ายที่ต้องทำเนื่องจากภาพ Gravatar มีขนาดไม่ใหญ่เกินไป อย่างไรก็ตามลองนึกดูว่าขนาดของเนื้อหาที่เรากำลังพร็อกซีมีขนาดหลายพันเมกะไบต์หรือไม่ แนวทางที่ดีกว่ามากคือ:
http.createServer() .on('request', function(req, res) { var email = req.url.substr(req.url.lastIndexOf('/')+1) if(!email) { res.writeHead(404) return res.end() } http.get('http://www.gravatar.com/avatar/'+crypto.createHash('md5').update(email).digest('hex'), function(resp) { resp.pipe(res) }) }) .listen(8080) ที่นี่เราดึงภาพและเพียงแค่ส่งต่อการตอบสนองไปยังลูกค้า เราไม่จำเป็นต้องอ่านเนื้อหาทั้งหมดลงในบัฟเฟอร์ก่อนที่จะให้บริการ
ข้อผิดพลาด # 9: การใช้ Console.log เพื่อวัตถุประสงค์ในการดีบัก
ใน Node.js“ console.log” ช่วยให้คุณพิมพ์เกือบทุกอย่างไปยังคอนโซล ส่งออบเจ็กต์ไปที่มันและมันจะพิมพ์ออกมาเป็นตัวอักษร JavaScript ยอมรับอาร์กิวเมนต์ตามจำนวนที่กำหนดและพิมพ์ทั้งหมดแยกพื้นที่อย่างเรียบร้อย มีสาเหตุหลายประการที่นักพัฒนาอาจรู้สึกอยากใช้สิ่งนี้ในการดีบักโค้ดของเขา อย่างไรก็ตามขอแนะนำอย่างยิ่งให้คุณหลีกเลี่ยง“ console.log” ในโค้ดจริง คุณควรหลีกเลี่ยงการเขียน 'console.log' ทับโค้ดเพื่อดีบักแล้วแสดงความคิดเห็นเมื่อไม่ต้องการอีกต่อไป ให้ใช้หนึ่งในไลบรารีที่น่าทึ่งที่สร้างขึ้นเพื่อสิ่งนี้เช่น แก้จุดบกพร่อง .
แพ็กเกจเช่นนี้มีวิธีที่สะดวกในการเปิดใช้งานและปิดใช้งานบรรทัดการดีบักบางอย่างเมื่อคุณเริ่มแอปพลิเคชัน ตัวอย่างเช่นด้วยการดีบักคุณสามารถป้องกันไม่ให้พิมพ์บรรทัดการดีบักไปยังเทอร์มินัลได้โดยไม่ตั้งค่าตัวแปรสภาพแวดล้อมดีบัก ใช้งานง่าย:
// app.js var debug = require('debug')('app') debug('Hello, %s!', 'world') ในการเปิดใช้งานบรรทัดการดีบักเพียงแค่เรียกใช้รหัสนี้โดยตั้งค่า DEBUG ตัวแปรสภาพแวดล้อมเป็น 'app' หรือ '*':
อะไรคือเป้าหมายของระบบ Android ตามที่ระบุไว้ในเว็บไซต์ Android สำหรับนักพัฒนา?
DEBUG=app node app.js ข้อผิดพลาด # 10: ไม่ใช้โปรแกรมหัวหน้างาน
ไม่ว่าโค้ด Node.js ของคุณจะทำงานในการผลิตหรือในสภาพแวดล้อมการพัฒนาในพื้นที่ของคุณการตรวจสอบโปรแกรมของผู้ดูแลที่สามารถจัดเตรียมโปรแกรมของคุณเป็นสิ่งที่มีประโยชน์อย่างยิ่ง แนวทางปฏิบัติอย่างหนึ่งที่นักพัฒนาออกแบบและนำแอปพลิเคชันสมัยใหม่มาใช้มักแนะนำว่าโค้ดของคุณควรล้มเหลวอย่างรวดเร็ว หากเกิดข้อผิดพลาดที่ไม่คาดคิดอย่าพยายามจัดการ แต่ปล่อยให้โปรแกรมของคุณขัดข้องและให้หัวหน้ารีสตาร์ทในไม่กี่วินาที ประโยชน์ของโปรแกรมหัวหน้างานไม่ได้ จำกัด เพียงแค่การรีสตาร์ทโปรแกรมที่ขัดข้องเท่านั้น เครื่องมือเหล่านี้ช่วยให้คุณสามารถรีสตาร์ทโปรแกรมเมื่อเกิดข้อขัดข้องและรีสตาร์ทเมื่อไฟล์บางไฟล์เปลี่ยนแปลง ทำให้การพัฒนาโปรแกรม Node.js เป็นประสบการณ์ที่น่าพึงพอใจยิ่งขึ้น
มีโปรแกรมหัวหน้างานมากมายสำหรับ Node.js ตัวอย่างเช่น:
เครื่องมือเหล่านี้มาพร้อมกับข้อดีข้อเสีย แอปพลิเคชั่นบางตัวเหมาะสำหรับการจัดการแอพพลิเคชั่นหลายตัวในเครื่องเดียวกันในขณะที่แอพอื่น ๆ ดีกว่าในการจัดการบันทึก อย่างไรก็ตามหากคุณต้องการเริ่มต้นกับโปรแกรมดังกล่าวทั้งหมดนี้เป็นทางเลือกที่ยุติธรรม
สรุป
ดังที่คุณทราบปัญหา Node.js บางอย่างอาจส่งผลร้ายแรงต่อโปรแกรมของคุณ บางอย่างอาจเป็นสาเหตุของความไม่พอใจในขณะที่คุณพยายามใช้สิ่งที่ง่ายที่สุดใน Node.js แม้ว่า Node.js จะทำให้ผู้มาใหม่เริ่มต้นใช้งานได้ง่ายมาก แต่ก็ยังมีพื้นที่ที่ทำให้ยุ่งเหยิงได้ง่าย นักพัฒนาจากภาษาโปรแกรมอื่น ๆ อาจเกี่ยวข้องกับปัญหาเหล่านี้บางส่วนได้ แต่ข้อผิดพลาดเหล่านี้มักเกิดขึ้นบ่อยในหมู่คนใหม่ นักพัฒนา Node.js . โชคดีที่พวกเขาหลีกเลี่ยงได้ง่าย ฉันหวังว่าคำแนะนำสั้น ๆ นี้จะช่วยให้ผู้เริ่มต้นเขียนโค้ดใน Node.js ได้ดีขึ้นและพัฒนาซอฟต์แวร์ที่เสถียรและมีประสิทธิภาพสำหรับเราทุกคน
