ทับทิมบนราง (“ Rails”) เป็นเฟรมเวิร์กโอเพนซอร์สยอดนิยมโดยใช้ ทับทิม ภาษาโปรแกรมที่พยายามทำให้กระบวนการพัฒนาเว็บแอปพลิเคชันง่ายและคล่องตัว
รางถูกสร้างขึ้นบนหลักการของ การประชุมมากกว่าการกำหนดค่า . พูดง่ายๆก็คือตามค่าเริ่มต้น Rails จะถือว่ามันเป็น นักพัฒนาผู้เชี่ยวชาญ จะเป็นไปตามแนวทางปฏิบัติที่ดีที่สุด 'มาตรฐาน' (สำหรับสิ่งต่างๆเช่นการตั้งชื่อโครงสร้างรหัสและอื่น ๆ ) และหากคุณทำสิ่งต่างๆจะทำงานให้คุณ 'อัตโนมัติอย่างน่าอัศจรรย์' โดยที่คุณไม่จำเป็นต้องระบุรายละเอียดเหล่านี้ แม้ว่ากระบวนทัศน์นี้จะมีข้อดี แต่ก็ไม่ผิดพลาดด้วยเช่นกัน สิ่งที่น่าสังเกตอย่างยิ่งคือ“ เวทมนตร์” ที่เกิดขึ้นเบื้องหลังในเฟรมเวิร์กบางครั้งอาจนำไปสู่ความบังเอิญสับสนและ“ เกิดอะไรขึ้น?” ประเภทของปัญหา นอกจากนี้ยังสามารถมีการแบ่งส่วนที่ไม่พึงปรารถนาเกี่ยวกับความปลอดภัยและประสิทธิภาพ
ดังนั้นในขณะที่ Rails ใช้งานง่าย แต่ก็ไม่ยากที่จะใช้ในทางที่ผิด บทช่วยสอนนี้กล่าวถึงปัญหา Rails ทั่วไป 10 ประการรวมถึงวิธีหลีกเลี่ยงปัญหาเหล่านี้และปัญหาที่ทำให้เกิด
Rails ขึ้นอยู่กับไฟล์ สถาปัตยกรรม MVC . ในชุมชน Rails เราได้พูดถึง โมเดลไขมันตัวควบคุมผอม ในขณะนี้แอปพลิเคชัน Rails ล่าสุดหลายรายการที่ฉันได้รับมานั้นละเมิดหลักการนี้ มันง่ายเกินไปที่จะย้ายตรรกะมุมมอง (ซึ่งดีกว่าอยู่ในตัวช่วย) หรือลอจิกโดเมน / โมเดลไปยังคอนโทรลเลอร์
ปัญหาคือวัตถุคอนโทรลเลอร์จะเริ่มละเมิดไฟล์ หลักการความรับผิดชอบเดียว การเปลี่ยนแปลงฐานรหัสในอนาคตทำได้ยากและเกิดข้อผิดพลาดได้ง่าย โดยทั่วไปไฟล์ เท่านั้น ประเภทของตรรกะที่คุณควรมีในคอนโทรลเลอร์ ได้แก่ :
แม้ว่าสิ่งนี้จะยังคงผลักดันขีด จำกัด ของหลักการความรับผิดชอบเดียว แต่ก็เป็นประเภทของขั้นต่ำที่ไม่จำเป็นที่เฟรมเวิร์ก Rails กำหนดให้เรามีในคอนโทรลเลอร์
เครื่องยนต์เทมเพลต Rails แบบสำเร็จรูป ERB เป็นวิธีที่ยอดเยี่ยมในการสร้างเพจที่มีเนื้อหาหลากหลาย อย่างไรก็ตามหากคุณไม่ระวังในไม่ช้าคุณจะพบกับไฟล์ขนาดใหญ่ที่ผสมผสานระหว่างโค้ด HTML และ Ruby ซึ่งอาจจัดการและดูแลรักษาได้ยาก นอกจากนี้ยังเป็นพื้นที่ที่อาจนำไปสู่การทำซ้ำหลายครั้งซึ่งนำไปสู่การละเมิด แห้ง (อย่าพูดซ้ำตัวเอง) หลักการ
สิ่งนี้สามารถแสดงให้เห็นได้หลายวิธี หนึ่งคือการใช้ตรรกะเงื่อนไขมากเกินไปในมุมมอง ดังตัวอย่างง่ายๆให้พิจารณากรณีที่เรามี current_user วิธีที่มีอยู่ซึ่งส่งคืนผู้ใช้ที่เข้าสู่ระบบในปัจจุบัน บ่อยครั้งจะมีโครงสร้างลอจิกแบบมีเงื่อนไขเช่นนี้ในไฟล์มุมมอง:
Welcome, Guest
วิธีที่ดีกว่าในการจัดการบางสิ่งเช่นนี้คือตรวจสอบให้แน่ใจว่าวัตถุส่งคืนโดย current_user คือ เสมอ ตั้งค่าไม่ว่าจะมีใครบางคนเข้าสู่ระบบหรือไม่และตอบสนองวิธีการที่ใช้ในมุมมองด้วยวิธีที่สมเหตุสมผล (บางครั้งเรียกว่าวัตถุว่าง) ตัวอย่างเช่นคุณอาจกำหนด current_user ผู้ช่วยใน app/controllers/application_controller แบบนี้:
require 'ostruct' helper_method :current_user def current_user @current_user ||= User.find session[:user_id] if session[:user_id] if @current_user @current_user else OpenStruct.new(name: 'Guest') end end จากนั้นจะช่วยให้คุณสามารถแทนที่ตัวอย่างโค้ดมุมมองก่อนหน้าด้วยโค้ดบรรทัดเดียวนี้:
Welcome,
แนวทางปฏิบัติที่ดีที่สุดสองสามข้อที่แนะนำเพิ่มเติม:
ได้รับคำแนะนำในการลดตรรกะในมุมมองและตัวควบคุมให้เหลือเพียงที่เดียวในไฟล์ สถาปัตยกรรม MVC ที่จะใส่ตรรกะทั้งหมดนั้นจะอยู่ในแบบจำลองใช่ไหม?
ก็ไม่เชิง
มากมาย นักพัฒนา Rails ทำผิดพลาดนี้และจบลงด้วยการติดทุกอย่างใน ActiveRecord คลาสโมเดลที่นำไปสู่ไฟล์ Mongo ที่ไม่เพียง แต่ละเมิดหลักการความรับผิดชอบเดียว แต่ยังเป็นฝันร้ายในการบำรุงรักษาอีกด้วย
ฟังก์ชันการทำงานเช่นการสร้างการแจ้งเตือนทางอีเมลการเชื่อมต่อกับบริการภายนอกการแปลงเป็นรูปแบบข้อมูลอื่น ๆ และสิ่งที่คล้ายกันนั้นไม่เกี่ยวข้องกับความรับผิดชอบหลักของ ActiveRecord แบบจำลองที่ควรทำมากกว่าการค้นหาและคงอยู่ข้อมูลในฐานข้อมูล
ดังนั้นหากตรรกะไม่ควรไปอยู่ในมุมมองและไม่ควรไปอยู่ในคอนโทรลเลอร์และไม่ควรอยู่ในโมเดลแล้วควรไปที่ใด
ป้อน วัตถุเก่า ๆ ของ Ruby (โปโร). ด้วยกรอบงานที่ครอบคลุมเช่น Rails นักพัฒนารุ่นใหม่มักไม่เต็มใจที่จะสร้างชั้นเรียนของตนเองนอกกรอบงาน อย่างไรก็ตามการย้ายตรรกะออกจากโมเดลไปยังโพโรมักเป็นเพียงสิ่งที่แพทย์สั่งให้หลีกเลี่ยงโมเดลที่ซับซ้อนเกินไป ด้วย PORO คุณสามารถห่อหุ้มสิ่งต่างๆเช่นการแจ้งเตือนทางอีเมลหรือการโต้ตอบกับ API ในชั้นเรียนของตนเองแทนที่จะรวมไว้ใน ActiveRecord แบบ.
ทำไมเราต้องการ devops
ด้วยเหตุนี้โดยทั่วไปแล้วตรรกะเดียวที่ควรคงอยู่ในโมเดลของคุณคือ:
ActiveRecord การกำหนดค่า (เช่นความสัมพันธ์และการตรวจสอบความถูกต้อง)full_name วิธีที่รวมฟิลด์ first_name และ last_name ในฐานข้อมูล)find); โดยทั่วไปคุณไม่ควรใช้ where วิธีการหรือวิธีการสร้างแบบสอบถามอื่น ๆ เช่นนี้นอกคลาสแบบจำลองเองข้อผิดพลาดนี้เป็นข้อพิสูจน์ที่ผิดพลาด # 3 ข้างต้น ตามที่กล่าวไว้กรอบงาน Rails ให้ความสำคัญกับส่วนประกอบที่มีชื่อ (เช่นโมเดลมุมมองและตัวควบคุม) ของเฟรมเวิร์ก MVC มีคำจำกัดความที่ดีพอสมควรเกี่ยวกับประเภทของสิ่งต่างๆที่อยู่ในคลาสของแต่ละองค์ประกอบเหล่านี้ แต่บางครั้งเราอาจต้องการวิธีการที่ดูเหมือนจะไม่เข้ากับสามอย่างใด
ตัวสร้าง Rails สร้างไดเร็กทอรีผู้ช่วยและคลาสผู้ช่วยใหม่เพื่อใช้กับทรัพยากรใหม่แต่ละรายการที่เราสร้างขึ้น แต่มันกลายเป็นเรื่องที่น่าดึงดูดเกินไปที่จะเริ่มบรรจุฟังก์ชันการทำงานใด ๆ ที่ไม่เข้ากับโมเดลมุมมองหรือตัวควบคุมอย่างเป็นทางการในคลาสตัวช่วยเหล่านี้
ในขณะที่ Rails เป็น MVC เป็นศูนย์กลางอย่างแน่นอนไม่มีอะไรป้องกันไม่ให้คุณสร้างประเภทของคลาสของคุณเองและเพิ่มไดเร็กทอรีที่เหมาะสมเพื่อเก็บโค้ดสำหรับคลาสเหล่านั้น เมื่อคุณมีฟังก์ชันเพิ่มเติมให้นึกถึงวิธีการใดที่รวมกลุ่มกันและหาชื่อที่ดีสำหรับคลาสที่มีเมธอดเหล่านั้น การใช้กรอบงานที่ครอบคลุมเช่น Rails ไม่ใช่ข้ออ้างที่จะปล่อยให้แนวทางปฏิบัติที่ดีที่สุดในการออกแบบเชิงวัตถุที่ดีดำเนินไปข้างทาง
Ruby และ Rails รองรับโดยไฟล์ ระบบนิเวศที่อุดมสมบูรณ์ของอัญมณี ที่รวมเอาความสามารถใด ๆ ที่นักพัฒนาสามารถนึกถึงได้ นี่เป็นสิ่งที่ยอดเยี่ยมสำหรับการสร้างแอปพลิเคชันที่ซับซ้อนได้อย่างรวดเร็ว แต่ฉันยังเคยเห็นแอปพลิเคชั่นที่พองตัวจำนวนมากซึ่งมีจำนวนอัญมณีในแอปพลิเคชัน Gemfile มีขนาดใหญ่ผิดสัดส่วนเมื่อเทียบกับฟังก์ชันที่ให้มา
สิ่งนี้ทำให้เกิดปัญหา Rails หลายประการ การใช้อัญมณีมากเกินไปทำให้ขนาดของ Rails มีขนาดใหญ่กว่าที่จำเป็น สิ่งนี้สามารถชะลอประสิทธิภาพในการผลิตได้ นอกเหนือจากความไม่พอใจของผู้ใช้แล้วสิ่งนี้ยังส่งผลให้ต้องมีการกำหนดค่าหน่วยความจำเซิร์ฟเวอร์ที่ใหญ่ขึ้นและต้นทุนการดำเนินงานที่เพิ่มขึ้น นอกจากนี้ยังใช้เวลานานกว่าในการเริ่มแอปพลิเคชัน Rails ขนาดใหญ่ซึ่งทำให้การพัฒนาช้าลงและทำให้การทดสอบอัตโนมัติใช้เวลานานขึ้น (และตามกฎแล้วการทดสอบแบบช้าจะไม่ได้ทำงานบ่อยเท่า)
โปรดจำไว้ว่าอัญมณีแต่ละชิ้นที่คุณนำเข้ามาในแอปพลิเคชันของคุณอาจมีการพึ่งพาอัญมณีอื่น ๆ และอาจมีการพึ่งพาอัญมณีอื่น ๆ และอื่น ๆ การเพิ่มอัญมณีอื่น ๆ อาจมีผลต่อการทบต้น ตัวอย่างเช่นการเพิ่มไฟล์ rails_admin อัญมณีจะนำอัญมณีเข้ามาอีก 11 อัญมณีเพิ่มขึ้นมากกว่า 10% จากการติดตั้ง Rails พื้นฐาน
จากการเขียนนี้การติดตั้ง Rails 4.1.0 ใหม่จะมี 43 อัญมณีใน Gemfile.lock ไฟล์. เห็นได้ชัดว่ามีมากกว่าที่รวมอยู่ใน Gemfile และแสดงถึงอัญมณีทั้งหมดที่อัญมณี Rails มาตรฐานจำนวนหนึ่งหยิบมาเป็นที่พึ่งพา
พิจารณาอย่างรอบคอบว่าค่าใช้จ่ายพิเศษนั้นคุ้มค่าหรือไม่เมื่อคุณเพิ่มอัญมณีแต่ละชิ้น ตัวอย่างเช่นนักพัฒนามักจะเพิ่ม rails_admin โดยไม่ตั้งใจ อัญมณีเพราะโดยพื้นฐานแล้วมันมีส่วนหน้าเว็บที่ดีสำหรับโครงสร้างแบบจำลอง แต่จริงๆแล้วมันไม่ได้เป็นอะไรมากไปกว่าเครื่องมือเรียกดูฐานข้อมูลที่สวยงาม แม้ว่าแอปพลิเคชันของคุณต้องการผู้ดูแลระบบที่มีสิทธิ์เพิ่มเติมคุณอาจไม่ต้องการให้สิทธิ์เข้าถึงฐานข้อมูลดิบแก่พวกเขาและคุณจะได้รับบริการที่ดีกว่าด้วยการพัฒนาฟังก์ชันการดูแลระบบที่มีประสิทธิภาพมากกว่าการเพิ่มอัญมณีนี้
แม้ว่านักพัฒนา Rails ส่วนใหญ่จะทราบถึงไฟล์บันทึกเริ่มต้นที่มีให้ในระหว่างการพัฒนาและในการใช้งานจริง แต่พวกเขามักไม่ใส่ใจกับข้อมูลในไฟล์เหล่านั้นมากพอ ในขณะที่แอปพลิเคชันจำนวนมากพึ่งพาเครื่องมือตรวจสอบบันทึกเช่น ฮันนี่แบดเจอร์ หรือ ใหม่ Relic ในการผลิตสิ่งสำคัญคือต้องคอยสังเกตไฟล์บันทึกของคุณตลอดขั้นตอนการพัฒนาและทดสอบแอปพลิเคชันของคุณ
ดังที่ได้กล่าวไว้ก่อนหน้านี้ในบทช่วยสอนนี้เฟรมเวิร์ก Rails สร้าง 'เวทมนตร์' มากมายให้คุณโดยเฉพาะในรุ่นต่างๆ การกำหนดความสัมพันธ์ในแบบจำลองของคุณทำให้ง่ายต่อการดึงความสัมพันธ์และมีทุกสิ่งที่พร้อมสำหรับมุมมองของคุณ SQL ทั้งหมดที่จำเป็นในการเติมอ็อบเจ็กต์โมเดลของคุณถูกสร้างขึ้นสำหรับคุณ เยี่ยมไปเลย แต่คุณจะรู้ได้อย่างไรว่า SQL ที่สร้างขึ้นนั้นมีประสิทธิภาพ?
ตัวอย่างหนึ่งที่คุณมักจะใช้เรียกว่าไฟล์ ปัญหาการสืบค้น N + 1 . แม้ว่าปัญหาจะเป็นที่เข้าใจกันดี แต่วิธีเดียวที่แท้จริงในการสังเกตว่าเกิดขึ้นคือการตรวจสอบการสืบค้น SQL ในไฟล์บันทึกของคุณ
ตัวอย่างเช่นคุณมีข้อความค้นหาต่อไปนี้ในแอปพลิเคชันบล็อกทั่วไปที่คุณจะแสดงความคิดเห็นทั้งหมดสำหรับชุดโพสต์ที่เลือก:
def comments_for_top_three_posts posts = Post.limit(3) posts.flat_map do |post| post.comments.to_a end end เมื่อเราดูไฟล์บันทึกของคำขอที่เรียกใช้เมธอดนี้เราจะเห็นสิ่งต่างๆดังต่อไปนี้ซึ่งมีการสืบค้นหนึ่งรายการเพื่อรับวัตถุโพสต์สามรายการจากนั้นจะมีการค้นหาอีก 3 รายการเพื่อรับความคิดเห็นของแต่ละออบเจ็กต์:
Started GET '/posts/some_comments' for 127.0.0.1 at 2014-05-20 20:05:13 -0700 Processing by PostsController#some_comments as HTML Post Load (0.4ms) SELECT 'posts'.* FROM 'posts' LIMIT 3 Comment Load (5.6ms) ELECT 'comments'.* FROM 'comments' WHERE 'comments'.'post_id' = ? [['post_id', 1]] Comment Load (0.4ms) SELECT 'comments'.* FROM 'comments' WHERE 'comments'.'post_id' = ? [['post_id', 2]] Comment Load (1.5ms) SELECT 'comments'.* FROM 'comments' WHERE 'comments'.'post_id' = ? [['post_id', 3]] Rendered posts/some_comments.html.erb within layouts/application (12.5ms) Completed 200 OK in 581ms (Views: 225.8ms | ActiveRecord: 10.0ms) ActiveRecord ’ส กำลังโหลด ความสามารถใน Rails ทำให้สามารถลดจำนวนคิวรีลงได้มากโดยให้คุณระบุ ล่วงหน้า การเชื่อมโยงทั้งหมดที่จะโหลด ซึ่งทำได้โดยเรียก includes (หรือ preload) บนวัตถุ Arel (ActiveRecord::Relation) ที่กำลังสร้าง ด้วย includes, ActiveRecord ตรวจสอบให้แน่ใจว่าการเชื่อมโยงที่ระบุทั้งหมดถูกโหลดโดยใช้จำนวนการสืบค้นขั้นต่ำที่เป็นไปได้ เช่น.:
def comments_for_top_three_posts posts = Post.includes(:comments).limit(3) posts.flat_map do |post| post.comments.to_a end end เมื่อมีการเรียกใช้โค้ดที่แก้ไขข้างต้นเราจะเห็นในไฟล์บันทึกว่าความคิดเห็นทั้งหมดถูกรวบรวมในแบบสอบถามเดียวแทนที่จะเป็นสาม:
Started GET '/posts/some_comments' for 127.0.0.1 at 2014-05-20 20:05:18 -0700 Processing by PostsController#some_comments as HTML Post Load (0.5ms) SELECT 'posts'.* FROM 'posts' LIMIT 3 Comment Load (4.4ms) SELECT 'comments'.* FROM 'comments' WHERE'comments '.'post_id' IN (1, 2, 3) Rendered posts/some_comments.html.erb within layouts/application (12.2ms) Completed 200 OK in 560ms (Views: 219.3ms | ActiveRecord: 5.0ms) มีประสิทธิภาพมากขึ้น
วิธีแก้ปัญหา N + 1 นี้มีไว้เพื่อเป็นเพียงตัวอย่างของความไร้ประสิทธิภาพที่สามารถเกิดขึ้นได้ในแอปพลิเคชันของคุณหากคุณไม่ได้รับการเอาใจใส่อย่างเพียงพอ ประเด็นสำคัญคือคุณควรตรวจสอบการพัฒนาและทดสอบไฟล์บันทึกระหว่างการพัฒนาเพื่อตรวจสอบความไร้ประสิทธิภาพ (และที่อยู่!) ในโค้ดที่สร้างคำตอบของคุณ
การตรวจสอบไฟล์บันทึกเป็นวิธีที่ยอดเยี่ยมในการกำจัดความไร้ประสิทธิภาพในโค้ดของคุณและแก้ไขก่อนที่แอปพลิเคชันของคุณจะเริ่มใช้งานจริง มิฉะนั้นคุณอาจไม่ทราบถึงปัญหาประสิทธิภาพของ Rails จนกว่าระบบของคุณจะใช้งานได้จริงเนื่องจากชุดข้อมูลที่คุณใช้ในการพัฒนาและทดสอบมีแนวโน้มที่จะมีขนาดเล็กกว่าในการผลิตมาก หากคุณกำลังทำงานกับแอปใหม่แม้แต่ชุดข้อมูลการใช้งานจริงของคุณก็อาจเริ่มมีขนาดเล็กและแอปของคุณจะดูเหมือนทำงานได้ดี อย่างไรก็ตามเมื่อชุดข้อมูลการผลิตของคุณเติบโตขึ้นปัญหา Rails เช่นนี้จะทำให้แอปพลิเคชันของคุณทำงานช้าลงและช้าลง
หากคุณพบว่าไฟล์บันทึกของคุณอุดตันด้วยข้อมูลมากมายที่คุณไม่ต้องการ ที่นี่ มีบางสิ่งที่คุณสามารถทำได้เพื่อล้างข้อมูลเหล่านี้ (เทคนิคที่ใช้ในการพัฒนาเช่นเดียวกับบันทึกการผลิต)
Ruby และ Rails ให้ความสามารถในการทดสอบอัตโนมัติที่มีประสิทธิภาพตามค่าเริ่มต้น นักพัฒนา Rails หลายคนเขียนการทดสอบที่ซับซ้อนมากโดยใช้ สไตล์ TDD และ BDD และใช้ประโยชน์จากกรอบการทดสอบที่ทรงพลังยิ่งขึ้นด้วยอัญมณีเช่น rspec และ แตงกวา .
แม้ว่าจะง่ายแค่ไหนในการเพิ่มการทดสอบอัตโนมัติลงในแอปพลิเคชัน Rails ของคุณ แต่ฉันก็รู้สึกประหลาดใจอย่างมากกับจำนวนโครงการที่ได้รับช่วงต่อหรือเข้าร่วมในที่ที่มี ไม่ การทดสอบที่เขียนขึ้น (หรืออย่างดีที่สุดมีน้อยมาก) โดยทีมพัฒนาก่อนหน้านี้ แม้ว่าจะมีการถกเถียงกันมากมายเกี่ยวกับความครอบคลุมของการทดสอบของคุณ แต่อย่างน้อยก็ค่อนข้างชัดเจน บาง การทดสอบอัตโนมัติควรมีอยู่สำหรับทุกแอปพลิเคชัน
ตามหลักการทั่วไปแล้วควรมีการทดสอบการรวมระดับสูงอย่างน้อยหนึ่งรายการที่เขียนขึ้นสำหรับแต่ละการกระทำในคอนโทรลเลอร์ของคุณ ในอนาคตนักพัฒนา Rails คนอื่น ๆ มักจะต้องการขยายหรือแก้ไขโค้ดหรืออัปเกรดเวอร์ชัน Ruby หรือ Rails และกรอบการทดสอบนี้จะช่วยให้พวกเขามีวิธีที่ชัดเจนในการตรวจสอบว่าฟังก์ชันพื้นฐานของแอปพลิเคชันคืออะไร ทำงาน. ประโยชน์เพิ่มเติมของแนวทางนี้คือช่วยให้นักพัฒนาในอนาคตสามารถอธิบายถึงคอลเลคชันฟังก์ชันทั้งหมดที่แอปพลิเคชันมีให้อย่างชัดเจน
ผู้ให้บริการ Rails บุคคลที่สามมักจะทำให้การรวมบริการเข้ากับแอปพลิเคชันของคุณเป็นเรื่องง่ายมากผ่านทางอัญมณีที่รวม API แต่จะเกิดอะไรขึ้นหากบริการภายนอกของคุณขัดข้องหรือเริ่มทำงานช้ามาก?
เพื่อหลีกเลี่ยงการบล็อกการโทรเหล่านี้แทนที่จะเรียกใช้บริการเหล่านี้โดยตรงในแอปพลิเคชัน Rails ของคุณในระหว่างการดำเนินการตามปกติของคำขอคุณควรย้ายไปยังบริการจัดคิวงานเบื้องหลังบางประเภทที่เป็นไปได้ อัญมณียอดนิยมที่ใช้ในแอพพลิเคชั่น Rails เพื่อจุดประสงค์นี้ ได้แก่ :
ในกรณีที่ไม่สามารถดำเนินการได้หรือเป็นไปไม่ได้ที่จะมอบหมายการประมวลผลไปยังคิวงานเบื้องหลังคุณจะต้องตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณมีการจัดการข้อผิดพลาดที่เพียงพอและข้อกำหนดด้านความล้มเหลวสำหรับสถานการณ์ที่หลีกเลี่ยงไม่ได้เมื่อบริการภายนอกหยุดทำงานหรือประสบปัญหา . นอกจากนี้คุณควรทดสอบแอปพลิเคชันของคุณโดยไม่ใช้บริการภายนอก (อาจโดยการลบเซิร์ฟเวอร์ที่แอปพลิเคชันของคุณเปิดอยู่ออกจากเครือข่าย) เพื่อตรวจสอบว่าแอปพลิเคชันไม่ได้ส่งผลที่ไม่คาดคิดใด ๆ
Rails ’ กลไกการย้ายฐานข้อมูล ช่วยให้คุณสร้างคำสั่งเพื่อเพิ่มและลบตารางและแถวฐานข้อมูลโดยอัตโนมัติ เนื่องจากไฟล์ที่มีการย้ายข้อมูลเหล่านี้มีการตั้งชื่อตามลำดับคุณสามารถเล่นไฟล์เหล่านี้ได้ตั้งแต่เริ่มต้นเพื่อนำฐานข้อมูลว่างไปยังสคีมาเดียวกับที่ใช้งานจริง นี่จึงเป็นวิธีที่ยอดเยี่ยมในการจัดการการเปลี่ยนแปลงสคีมาฐานข้อมูลของแอปพลิเคชันของคุณอย่างละเอียดและหลีกเลี่ยงปัญหา Rails
แม้ว่าสิ่งนี้จะใช้งานได้ดีในช่วงเริ่มต้นโครงการของคุณ แต่เมื่อเวลาผ่านไปกระบวนการสร้างฐานข้อมูลอาจใช้เวลาสักครู่และบางครั้งการย้ายข้อมูลจะผิดตำแหน่งแทรกไม่เป็นระเบียบหรือนำมาจากแอปพลิเคชัน Rails อื่น ๆ โดยใช้เซิร์ฟเวอร์ฐานข้อมูลเดียวกัน
Rails สร้างการแสดงสคีมาปัจจุบันของคุณในไฟล์ชื่อ db/schema.rb (โดยค่าเริ่มต้น) ซึ่งโดยปกติจะอัปเดตเมื่อมีการเรียกใช้การย้ายฐานข้อมูล schema.rb ยังสามารถสร้างไฟล์ได้เมื่อไม่มีการย้ายข้อมูลโดยเรียกใช้ rake db:schema:dump งาน. ข้อผิดพลาดทั่วไปเกี่ยวกับ Rails คือการตรวจสอบการย้ายข้อมูลใหม่ไปยังแหล่งที่มาของคุณ แต่ไม่ได้รับการอัปเดต schema.rb ไฟล์.
เมื่อการย้ายข้อมูลหมดไปและใช้เวลาทำงานนานเกินไปหรือสร้างฐานข้อมูลไม่ถูกต้องอีกต่อไปนักพัฒนาไม่ควรกลัวที่จะล้างไดเรกทอรีการย้ายข้อมูลเก่าทิ้งสคีมาใหม่และดำเนินการต่อจากที่นั่น การตั้งค่าสภาพแวดล้อมการพัฒนาใหม่จะต้องมี rake db:schema:load แทนที่จะเป็น rake db:migrate ที่นักพัฒนาส่วนใหญ่ต้องพึ่งพา
jwt ปฏิเสธการพิสูจน์ตัวตนผู้ใช้ล้มเหลว
บางส่วนของเหล่านี้ มีการหารือประเด็นต่างๆ ในคู่มือ Rails ด้วย
เฟรมเวิร์ก Rails ทำให้ง่ายต่อการสร้างแอปพลิเคชันที่ปลอดภัยไม่สามารถโจมตีได้หลายประเภท บางส่วนสามารถทำได้โดยใช้โทเค็นลับเพื่อรักษาความปลอดภัยเซสชันกับเบราว์เซอร์ แม้ว่าตอนนี้โทเค็นนี้จะถูกเก็บไว้ใน config/secrets.yml และไฟล์นั้นอ่านโทเค็นจากตัวแปรสภาพแวดล้อมสำหรับเซิร์ฟเวอร์ที่ใช้งานจริง Rails เวอร์ชันที่ผ่านมารวมโทเค็นไว้ใน config/initializers/secret_token.rb ไฟล์นี้มักจะถูกตรวจสอบโดยไม่ได้ตั้งใจในที่เก็บซอร์สโค้ดกับส่วนที่เหลือของแอปพลิเคชันของคุณและเมื่อสิ่งนี้เกิดขึ้น ทุกคนที่มีสิทธิ์เข้าถึงที่เก็บสามารถโจมตีผู้ใช้แอปพลิเคชันทั้งหมดของคุณได้อย่างง่ายดาย .
ดังนั้นคุณควรตรวจสอบให้แน่ใจว่าไฟล์คอนฟิกูเรชันที่เก็บของคุณ (เช่น .gitignore สำหรับ ไป ผู้ใช้) ไม่รวมไฟล์ที่มีโทเค็นของคุณ จากนั้นเซิร์ฟเวอร์ที่ใช้งานจริงของคุณสามารถรับโทเค็นจากตัวแปรสภาพแวดล้อมหรือจากกลไกเช่นเดียวกับที่ อัญมณี dotenv ให้.
Rails เป็นเฟรมเวิร์กที่ทรงพลังที่ซ่อนรายละเอียดที่น่าเกลียดมากมายที่จำเป็นในการสร้างไฟล์ แอปพลิเคชันเว็บที่มีประสิทธิภาพ . แม้ว่าสิ่งนี้จะทำให้การพัฒนาแอปพลิเคชันเว็บ Rails เร็วขึ้นมาก แต่นักพัฒนาควรให้ความสำคัญกับข้อผิดพลาดในการออกแบบและการเข้ารหัสที่อาจเกิดขึ้นเพื่อให้แน่ใจว่าแอปพลิเคชันของพวกเขาสามารถขยายและบำรุงรักษาได้อย่างง่ายดาย
นักพัฒนายังต้องระวังปัญหาที่ทำให้แอปพลิเคชันทำงานช้าลงเชื่อถือได้น้อยลงและมีความปลอดภัยน้อยลง สิ่งสำคัญคือต้องศึกษากรอบงานและตรวจสอบให้แน่ใจว่าคุณเข้าใจอย่างถ่องแท้เกี่ยวกับสถาปัตยกรรมการออกแบบและการแลกเปลี่ยนการเข้ารหัสที่คุณทำตลอดกระบวนการพัฒนาเพื่อช่วยให้มั่นใจได้ว่าแอปพลิเคชันที่มีคุณภาพสูงและมีประสิทธิภาพสูง
ที่เกี่ยวข้อง: Ruby on Rails มีประโยชน์อย่างไร? หลังจากสองทศวรรษของการเขียนโปรแกรมฉันใช้ Rails
