อย่าพูดถึงราคาที่อยู่อาศัยการจราจรติดขัดและหมอกควัน - - ก่อนอื่นให้ฉันพูดถึงประสบการณ์ของฉันโดยใช้ node.js ในช่วงหกเดือนที่ผ่านมา - - ทั้งหมดเป็นปัญหาที่พบในที่ทำงานและบทเรียนนองเลือด -
1. หมายเลขเวอร์ชันที่ถูกต้อง
"คุณต้องแม่นยำกับหมายเลขเวอร์ชันเฉพาะ! ใช้ * เพื่อม้วนโดยตรง ^ และ ~ ไม่เป็นไร!" ทันทีที่เรามาถึง บริษัท ในตอนเช้าเซิร์ฟเวอร์ของเราถูกปกคลุมด้วยตาเลือด (อาจเป็นช่วงเวลาของตอนเช้าที่จะเข้านอน) และบ่นกับฉัน: "ไอ้บ้าเวอร์ชันในแพ็คเกจรหัส json ที่ฉันเขียนก่อนหน้านี้แตกต่างจากเวอร์ชันที่ทำงานบนเซิร์ฟเวอร์ติดตั้งล่าสุดแล้วรายงานข้อผิดพลาด" ไม่กี่พันคำถูกละไว้ที่นี่ - -
เอาล่ะ. ฉันจะตบหน้าตัวเองก่อน ฉันเคยใช้เท่านั้น * - - ส่วนใหญ่ไม่จำเป็นต้องเขียนหมายเลขเวอร์ชันที่ตายแล้วและเป็นไปได้ที่จะใช้ ^ และ ~ สแกนตาบอด:
กรรไกร
การจัดการเวอร์ชันใน node.js
2. ทดสอบ
ให้แน่ใจว่าได้เขียนกรณีทดสอบ ยกตัวอย่างฉัน ชิ้นส่วนที่ฉันรับผิดชอบในการมีส่วนการกรอง (โดยใช้ข้อความตัวกรองของ Shenma ปกติเพื่อแยกข้อความที่มีประโยชน์) ด้วยกรณีทดสอบหลังจากการเปลี่ยนแปลงกฎการกรองแต่ละครั้งมันเป็นเรื่องจริงอย่างแน่นอนภายใต้การทดสอบ NPM เลือกโมดูลทดสอบที่จะใช้ตามความชอบส่วนตัวของคุณมอคค่าควรเทปแตะซูเปอร์เทสต์ ฯลฯ
ลองใช้งานในเครื่องและอัปโหลดไปยังเซิร์ฟเวอร์หลังจากการทดสอบสำเร็จ ฉันได้แก้ไขรหัสหลายครั้ง (เพิ่งเปลี่ยนสองสามบรรทัด) และคิดว่าอาจมีปัญหา แต่ทันทีที่เซิร์ฟเวอร์รีสตาร์ทมันก็วางสาย - ไอ้มันไม่มีวงเล็บหรืออะไรสักอย่าง - ปัญหานี้สามารถตรวจพบได้โดยใช้ปลั๊กอินตัวแก้ไขเช่น JSlint หรือ JShint
การสำรองข้อมูลรหัสเซิร์ฟเวอร์ วิธีการที่ฉันใช้: ในตอนแรกมีสองโครงการที่เหมือนกันบนเซิร์ฟเวอร์ (ไลบรารี Git, ชื่อไฟล์ที่แตกต่างกัน), หนึ่งที่กำลังทำงานและอีกโครงการหนึ่งเป็นการสำรองข้อมูล เมื่อมีการเปลี่ยนแปลงรหัสให้ไปที่โครงการสำรองเพื่อดึง Git แล้วหยุดโปรแกรมที่กำลังทำงานและเริ่มโปรแกรมสำรอง หากโปรแกรมไม่ล้มเหลวในช่วงเวลาหนึ่งนั่นหมายความว่ารู้สึกค่อนข้างเสถียรให้ใช้โครงการนี้เป็นหลักและโครงการอื่นเป็นการเตรียมการ เมื่อมีการเปลี่ยนแปลงอื่นให้ทำซ้ำขั้นตอนข้างต้นและสวิตช์หลักและสำรองข้อมูลกลับไปกลับมา หากโปรแกรมล้มเหลวให้สลับกลับเป็นการสำรองข้อมูลที่มีเสถียรภาพมากขึ้น
3. ใช้การดีบัก
การดีบักเป็นสิ่งที่หลีกเลี่ยงไม่ได้เมื่อเขียนโปรแกรม หลายคนชอบและคุ้นเคยกับการใช้ Universal Console.log () รวมถึงฉันด้วย - โดยส่วนตัวหลังจากที่ฉันใช้ console.log () เพื่อปรับไม่ว่าจะลบหรือแสดงความคิดเห็น มันอาจจะใช้ในภายหลังถ้าคุณลบมัน แต่มันน่าเกลียดมากที่จะแสดงความคิดเห็น คุณอาจใช้โมดูลดีบั๊กในเวลานี้ ยังไม่มีการใช้ผู้ตรวจการโหนดดังนั้นจึงยังไม่มีการประเมินผล
4. รักษารหัสให้ง่าย
การพยายามทำสิ่งต่าง ๆ ให้สำเร็จมากขึ้นด้วยรหัสที่น้อยลงก็เป็นการปรับปรุงและทดสอบความสามารถของคุณเอง รวมถึงการเยื้องที่ถูกต้องชื่อตัวแปรที่เหมาะสมองค์กรรหัสที่ชัดเจน ฯลฯ รหัสนั้นบางกว่าและสวยงาม เมื่อมีบางอย่างผิดปกติมันเร็วกว่าที่จะตรวจสอบข้อผิดพลาด มันดีกว่าที่จะคิดออกว่ารหัสยุ่งเหยิงทำอะไรและต้องใช้เวลาหลายชั่วโมงในการทำ
หากทีมไม่ได้ใช้ CoffeeScript อย่าใช้มัน ก่อนอื่นคนอื่นไม่สามารถเข้าใจรหัสของคุณเพื่อช่วยคุณแก้ไขข้อผิดพลาด ประการที่สองจำนวนบรรทัดที่ปรากฏหลังจากข้อผิดพลาดแตกต่างจากจำนวนบรรทัดที่แสดงในรหัสกาแฟ - - สามารถใช้โครงการโอเพ่นซอร์สของคุณเองได้
5. ถามคำแนะนำเพิ่มเติมและคิดอย่างอิสระ
เมื่อฉันเริ่มทำงานครั้งแรกฉันก็สับสนรวมถึงข้อบกพร่องทางเทคนิคและการขาดตรรกะทางธุรกิจ ฉันมักจะถามคนตัวใหญ่ในทีม จากนั้นฉันจะพยายามชดเชยข้อบกพร่องทางเทคนิคและชี้แจงตรรกะทางธุรกิจ ต่อมาฉันต้องการออกแบบ API ตามข้อกำหนดของ PM ซึ่งไม่เพียง แต่คำนึงถึงความต้องการของผู้ใช้ (สถานการณ์ของลูกค้าหลายราย) ความต้องการและพฤติกรรมของลูกค้าการออกแบบฐานข้อมูล (วิธีการจัดเก็บความซ้ำซ้อนน้อยกว่าการสืบค้นน้อยลงง่ายต่อการปรับเปลี่ยน - - แม้ว่าฉันจะพูดคุยกับ tou tou หลายครั้ง แต่มันก็ให้เหตุผลกับฉันเสมอและไม่ได้บอกวิธีการนี้ ต่อมาในที่สุดฉันก็พบทางออกที่ดีทีเดียว - หลังจากนั้นเขาก็บอกฉันว่าเขาต้องการให้ฉันคิดอย่างอิสระเพื่อแก้ปัญหาเพื่อให้ฉันสามารถปรับปรุงได้ -
6. ใช้ห้องสมุดที่มีอยู่
ปัจจุบันมีโมดูลบุคคลที่สามเกือบ 9W ใน NPM ในทางทฤษฎีทุกสิ่งที่คุณต้องการใช้สามารถพบได้ใน NPM แน่นอนว่ามีโมดูลที่ยอดเยี่ยมมากมายเกี่ยวกับ NPM พร้อมเอกสารประกอบที่ครอบคลุมและการใช้งานที่สะดวกมากซึ่งมักจะตอบสนองความต้องการ หากคุณพบว่าโมดูลสามารถตอบสนองความต้องการได้มากที่สุดก็สามารถปรับปรุงได้ตามหน้าที่หรือมีข้อบกพร่องคุณสามารถไปที่ GitHub เพื่อเพิ่ม PR หากคุณพบว่าคุณไม่พบโมดูลที่น่าพอใจคุณสามารถสร้างและเผยแพร่ใน NPM เพื่อแบ่งปันกับคุณ แน่นอนถ้าคุณพบว่าโมดูลบางประเภทที่ใช้ฟังก์ชั่นบางอย่างนั้นน่ารังเกียจมากคุณยังสามารถเผยแพร่อึได้
7. ทำให้มันง่าย
หากคุณต้องการแสดงแผนภูมิวงกลมเพียงใช้ HTML5 Canvas หรือ CSS3 ไม่จำเป็นต้องใช้ไลบรารี C ++ Canvas เพื่อวาดรูปภาพ "ห้องสมุดที่ขึ้นอยู่กับคือ 400+ MB" กล่าว
8. เอกสารที่ดี
เอกสารที่ดีเป็นช่องทางที่สำคัญที่สุดสำหรับลูกค้าในการสื่อสารกับทีมเซิร์ฟเวอร์ เอกสารถูกเขียนอย่างชัดเจน หากเกิดข้อผิดพลาดคำขอไคลเอนต์คุณสามารถตรวจสอบเอกสารก่อน (เช่นสิ่งที่รหัสข้อผิดพลาดแต่ละรายการแสดง) แทนที่จะขอให้เซิร์ฟเวอร์หารือทุกครั้งที่มีปัญหา PS: ตัวอย่างคำขอ HTTP บางอย่างควรเขียนด้วย Curl แทนที่จะเป็นวัตถุใน JS ฯลฯ คุณอาจเข้าใจได้ดี แต่ลูกค้าไม่เข้าใจ JS
9. ไฟล์กำหนดค่า
สร้างไฟล์การกำหนดค่าในแต่ละไดเรกทอรีโครงการเช่น config.js/config.json แทนที่จะเขียนมันตายในรหัส ชอบ:
-
"แอพ": 3000,
"Mongo": {
"โฮสต์": "localhost",
"พอร์ต": 27017
-
"Redis": {
"โฮสต์": "localhost",
"พอร์ต": 6379
-
-
-
10. ใช้ PM2
การใช้เครื่องมือการจัดการกระบวนการเช่น PM2 นั้นสะดวกมากและกระบวนการสามารถรีสตาร์ทโดยอัตโนมัติหากล้มเหลว ไม่ได้ใช้ตลอดไปไม่มีการประเมิน - นอกจากนี้ยังมีคำราม ฉันไม่เคยใช้มาก่อนดังนั้นฉันจะไม่แสดงความคิดเห็น