Ruby on Rails มีประโยชน์อย่างไร? หลังจากสองทศวรรษของการเขียนโปรแกรม ฉันใช้ Rails

เผยแพร่แล้ว: 2022-03-11

บางครั้งฉันได้ยินคนบ่นเกี่ยวกับลูกค้าของพวกเขา โดยบอกว่าพวกเขา ยืนยัน ที่จะใช้ Rails ว่าพวกเขามี Kool Aid มากเกินไป หากพวกเขาเป็นนายหน้า พวกเขาเกือบจะรู้สึกไม่สบายท้องที่ต้องหานักพัฒนา 'primadona' ของ Ruby on Rails อีกราย จากนั้นพวกเขาก็ดึงบางสิ่งที่คล้ายกับการเปรียบเทียบระหว่าง Git และ PHP ที่โง่เขลาอย่างเหลือเชื่อนี้ออกมาเพื่อพิสูจน์ประเด็นของพวกเขา “พวกเขาไม่รู้ด้วยซ้ำว่ากำลังขออะไร” พวกเขากล่าว

สำหรับเราในฐานะโปรแกรมเมอร์ บางครั้งดูเหมือนว่าลูกค้าของเราจะไม่รู้อะไรเลย เราชอบที่จะพูดเกินจริงกรณีเช่นนี้ เมื่อคุณลองคิดดูสักนิด มันดูไม่ถูกต้องที่จะคิดว่าบุคคลที่ให้เงินฉันเพื่อสร้างสิ่งของนั้นถูกจำกัดและ 'แค่ไม่เข้าใจ' อันที่จริง ฉันเชื่อว่าลูกค้าส่วนใหญ่รู้ทางเลือกของตนดี แต่ก็ ยัง ตัดสินใจเลือกใช้ Rails

ฉันจะพยายามอธิบายว่าอะไรในความคิดของฉันที่ทำให้ Rails มีประโยชน์เพียงพอที่จะได้รับการพิจารณาอย่างจริงจังสำหรับโครงการและความต้องการมากมายเหลือเฟือ

ประโยชน์ของทับทิม

เป็นไปได้ว่าไม่มีใครรู้ถึงประโยชน์ของ Ruby ด้วยซ้ำ ถ้าไม่ใช่สำหรับ Rails เอง บางคนชอบดูถูก Ruby โดยบอกว่า "ง่ายสำหรับ Ruby" ด้วย "อัศวินในชุดเกราะเรืองแสงชื่อ Rails" และถ้าไม่มี Rails "Ruby ก็ไม่มีความหมาย" ฉันไม่สามารถพูดได้อย่างแน่ชัดว่าจริงหรือไม่ แต่ฉันรู้ว่ามันน่าเสียดายอย่างยิ่งหากโลกพลาดภาษาที่ยอดเยี่ยมเช่นนี้ ความจริงก็คือ: ผู้เขียน Rails เลือก Ruby อย่างจงใจ และการเดิมพันที่ 'ดุร้าย' ของเขาได้รับผลตอบแทนมหาศาล สิ่งที่เขาเห็นในตอนนั้น คนอื่นๆ หลายคนสามารถเห็นได้ในวันนี้ Ruby เปิดใช้งานโปรแกรมเมอร์ในลักษณะพิเศษที่ยากต่อการอธิบายให้ 'คนจำนวนมากที่ยังไม่ได้ล้าง' ทำไมต้องใช้ Ruby on Rails? Ruby ทำให้โปรแกรมเมอร์มีความสุขตามที่โฆษณาไว้

ในขณะที่นักพัฒนาส่วนใหญ่ยอมรับว่า Ruby นั้นมีประโยชน์ แต่บางคนก็มองว่ามัน มากเกินไป พวกเขากังวลเกี่ยวกับสิ่งที่อาจเกิดขึ้นกับเสรีภาพทั้งหมดที่ Ruby อนุญาต ศักยภาพทั้งหมดสำหรับการใช้ในทางที่ผิด ให้ฉันอธิบายด้วยการแก้ไขลิงบางตัว:

 "1".to_i #=> 1 class String def to_i raise 'foobar' end end "1".to_i #=> RuntimeError: foobar

ง่ายมาก: ด้วยโค้ดเพียงห้าบรรทัด เราได้นำคลาสที่มีอยู่แล้วและแทนที่พฤติกรรมของคลาส Nohting เป็นสิ่งศักดิ์สิทธิ์ - ไม่ใช่แม้แต่สตริง ข้อผิดพลาดนี้จะมองเห็นได้ง่าย แต่สิ่งต่างๆ อาจเลวร้ายกว่านั้นมาก:

 class String def to_i self.to_f - 1.13 end end "2".to_i #=> 0.8700000000000001

ในทำนองเดียวกัน เราได้แนะนำข้อผิดพลาดในคลาส String ที่สามารถห่อหุ้มและบดบังด้วยเลเยอร์ต่อเลเยอร์ของความซับซ้อน

คุณอาจกำลังคิดว่า: ทุกคนและแม่ของพวกเขาจะทำให้ใบสมัครอันมีค่าของฉันยุ่งเหยิงได้ไหม แม้ว่าพฤติกรรมนี้จะดูน่ากลัวจริงๆ แต่ก็ไม่เลย ในช่วงห้าปีที่ใช้ Ruby ฉันไม่มีปัญหากับพฤติกรรมนี้เลย อาจดูเหมือนขัดกับสัญชาตญาณ แต่แล้วอีกครั้ง การขับรถที่ความเร็ว 60 ไมล์ต่อชั่วโมงในทิศทางตรงกันข้ามคั่นด้วยเส้นสีขาวบางๆ ตรงกลางถนนเท่านั้น ในทางปฏิบัติ ทั้งสองทำงานได้ดีอย่างน่าทึ่ง

อาจดูเหมือนขัดกับสัญชาตญาณ แต่แล้วอีกครั้ง การขับรถที่ความเร็ว 60 ไมล์ต่อชั่วโมงในทิศทางตรงกันข้ามคั่นด้วยเส้นสีขาวบางๆ ตรงกลางถนนเท่านั้น ในทางปฏิบัติ ทั้งสองทำงานได้ดีอย่างน่าทึ่ง

ข้อดีอีกประการหนึ่งคือ Ruby เป็นเครื่องมืออเนกประสงค์ จึงมีขอบคมเหมือนมีด ฉันชอบคิดว่าผู้ใหญ่สามารถจัดการกับมีดได้ดี – การป้องกันเด็กนั้นมีไว้สำหรับเด็กๆ (ทวีต) และการได้รับการปฏิบัติเหมือนเด็กในด้านไอที ทำให้คุณตกเป็นเหยื่อของ Blub Paradox ของ Paul Graham: คุณคิดว่าคุณจะดีกว่าหากไม่มีคุณสมบัติบางอย่างที่คุณไม่เข้าใจหรือมีคนบอกคุณว่าอันตรายเกินไป แน่นอน วันนี้เราจะถามตัวเองว่า “ทำไมต้องใช้ Ruby on Rails”; ดังนั้น นี่เป็นการอภิปรายอีกครั้ง เป็นที่ยอมรับว่า Ruby พลาดคุณสมบัติบางอย่างที่ภาษาอื่นมี (Lisp hmm, hmm) โดยรวมแล้ว Ruby อยู่ใกล้กับจุดสูงสุดของ 'ความต่อเนื่องของพลังภาษา'

สองสามปีแรกของฉันกับ Ruby นั้นอ่อนน้อมถ่อมตน ฉันเรียนรู้มากมายจากการอ่านโค้ดของผู้อื่น บางครั้งฉันรู้สึกทึ่ง บางครั้งฉันก็บ้า แต่ในที่สุด ความรู้นี้ทำให้ฉันสามารถสื่อสารกับคอมพิวเตอร์ของฉันได้อย่างมีประสิทธิภาพมากขึ้นกว่าเดิม ฉันเกือบจะรู้สึกเสียใจกับภาษา 'เทปสีแดง' อื่นๆ ที่ทำให้คุณกระโดดข้ามห่วงเพียงเพื่อกระโดดข้ามพวกเขา ในขณะที่บอกคุณว่า “ฉันแค่ทำสิ่งที่ดีที่สุดสำหรับคุณ มันเป็นเพื่อประโยชน์ของคุณเอง!”

ลัทธิปฏิบัตินิยม

มีความเคารพอย่างลึกซึ้งต่อลัทธิปฏิบัตินิยมที่ถักทอเข้ากับ DNA ของ Rails ในระดับที่ต่ำที่สุดเท่าที่จะเป็นไปได้ เมื่อใช้ร่วมกับประโยชน์ของ Ruby ลัทธิปฏิบัตินิยมนี้จะสร้างโซลูชันที่สวยงามและสนับสนุน/สร้างแรงบันดาลใจให้ชุมชนการพัฒนา Ruby on Rails ทำเช่นเดียวกัน ลัทธิปฏิบัตินิยมมักถูกโฆษณาว่าเป็นเต็นท์ของ Rails ดังนั้นคำกล่าวอ้างนี้จึงไม่ใช่เรื่องใหม่ แต่ฉันจำได้เมื่อไม่นานนี้เองว่าความจริงเป็นความจริง เนื่องจากเพื่อนของฉันพยายามแสดงให้ฉันเห็นได้ว่าไฮเบอร์เนต "เจ๋ง" จริงๆ เป็นอย่างไร เขากำลังดิ้นรน ฉันสัมผัสได้ถึงความเจ็บปวดของเขาเพราะเขาไม่สามารถตั้งค่าตัวเลือกและพารามิเตอร์การกำหนดค่ามากมายที่ควรเป็นค่าเริ่มต้นของเฟรมเวิร์กตั้งแต่แรก

ด้วยอายุที่มากขึ้น มาตรฐานของฉันสำหรับความซับซ้อนของการประดิษฐ์ก็เพิ่มมากขึ้นเรื่อยๆ เมื่อพิจารณาว่าฉันเริ่มเขียนรหัสการผลิตในปี 1989 เมื่ออายุ 11 ขวบ (เริ่มด้วยโครงการเพื่อนบ้านของฉันใน Clipper Summer '87) ฉันมีความอดทนต่อปัญหาที่ไม่จำเป็น และเรลส์ทำคะแนนได้สูงมากในแผนกนั้น เป็นมากกว่า 'การประชุมผ่านการกำหนดค่า'; ฉันกำลังพูดถึงแนวความคิดเชิงปฏิบัติทั้งหมดที่มีมูลค่าสูงภายในและแทรกซึมผ่านชุมชน Rails

การแสดงออก

Rails ใกล้เคียงกับภาษาอังกฤษมากที่สุด (ยกเว้นกรณีที่คุณใช้ภาษาโคบอล) มันใช้สิ่งที่เรียกว่า DSL ภายใน ซึ่งขยาย Ruby ด้วยความหมายของตัวเอง การสร้าง DSL นั้นอันตรายเสมอ เนื่องจากคุณกำลังพัฒนาภาษาใหม่อย่างมีประสิทธิภาพ เนื่องจากเป็นภาษาภายใน คุณไม่จำเป็นต้องใช้ parser ภายนอก แต่ในแง่หนึ่ง คุณจะรู้สึกเหมือนเป็นภาษาใหม่ ทีมงาน Rails ได้สร้างสมดุลที่ดีกับ DSL โดยใช้งานในที่ที่เหมาะสมและแทบจะไม่ได้ทำเกินเลย ซึ่งแสดงให้เห็นถึงการควบคุมตนเองที่ยอดเยี่ยม ฉันคิดว่าโปรแกรมเมอร์ทุกคนโดยไม่คำนึงถึงประสบการณ์ Rails (และแม้แต่ผู้ที่ไม่ใช่โปรแกรมเมอร์) สามารถเข้าใจสิ่งนี้:

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

ที่จริงแล้ว หากคุณไม่คุ้นเคยกับ Ruby สิ่งนี้อาจดูแปลก ๆ เกือบจะเหมือนกับว่าไม่ใช่ภาษาโปรแกรม เมื่อคุณตระหนักว่าเป็นเพียงการเรียกเมธอดโดยไม่มีวงเล็บ คุณก็พร้อมแล้วที่จะไป ถึงกระนั้น Rails DSL ก็ให้ความรู้สึกเหมือนเป็นภาษาพิเศษสำหรับการอธิบายข้อกำหนด โดยแท้จริงแล้วมันเป็นเพียงแค่การตั้งชื่อที่ชาญฉลาดและการใช้ไวยากรณ์ที่ยอดเยี่ยมของ Ruby โดยธรรมชาติ

ชุมชน

Rails มีกองทัพผู้บังคับบัญชาที่คอยดูแลให้อยู่ในสภาพดีเยี่ยม หลายโครงการลดน้อยลงตามอายุ แต่ด้วย Rails ประกายไฟยังคงโบยบินเมื่อต้องตัดสินใจ รู้สึกเหมือนผู้ดูแล (ยังคง) ใส่ใจและต้องการให้ผู้คนใช้ Ruby on Rails และเข้าใจถึงประโยชน์ของมันอย่างแท้จริง

หลายโครงการลดน้อยลงตามอายุ แต่ด้วย Rails ประกายไฟยังคงโบยบินเมื่อต้องตัดสินใจ
ทวีต

ภายใต้ Rails ในฐานะเชอร์รี่ที่อยู่ด้านบน Ruby ยืนหยัดด้วย RubyGems ผู้จัดการแพ็คเกจที่น่าเกรงขาม เทียบได้กับ CPAN ในแง่ของจำนวนแพ็คเกจ และเมื่อพิจารณาจากอายุของ CPAN การกล่าวอ้างนั้น (พูดง่าย ๆ ) นั้นน่าประทับใจมาก Rails มีปัญหาเล็กน้อยเมื่อพยายามสร้าง "ปลั๊กอิน Rails" ของตัวเอง โชคดีที่สิ่งนี้ไม่เกาะติด ดังนั้น RubyGems ยังคงเป็นแหล่งรวมที่ยอดเยี่ยมสำหรับรหัสที่ตั้งโปรแกรมโดยบุคคลที่ฉลาดมาก

การทำงานร่วมกันระหว่างภาษาเจ๋งๆ เว็บเฟรมเวิร์กในทางปฏิบัติ และชุมชนที่ยอดเยี่ยมทำให้ Rails ได้ผลลัพธ์ ที่ดีกว่าผลรวมของส่วนต่างๆ อย่างมาก

ครบกำหนด

Rails ได้รับรอบบล็อก ในแบบฮิปสเตอร์ มันไม่เท่ขนาดนั้นแล้ว นี่เป็นสิ่งที่ดีเมื่อต้องเลือกกลุ่มเทคโนโลยี: คุณต้องการสิ่งที่พิสูจน์ได้ และ Rails ก็เป็นเช่นนั้น เมื่อเร็ว ๆ นี้เราได้เขียนบทความเกี่ยวกับล่ามและรันไทม์ของ Ruby ที่หลากหลายซึ่งพร้อมใช้งานแล้ว

การตลาด

ฉันรู้ว่าฉันรู้ว่า. ในฐานะผู้เชี่ยวชาญด้านไอที ฉันควรให้ความสำคัญกับสิ่งที่ 'จริงจัง' และละเลย 'แวววาว' อาจดูเหมือนตื้น แต่ให้เผชิญ:

  1. ไซต์ Rails ดู ดี เมื่อเทียบกับคู่แข่ง
  2. การแสดงหน้าจอครั้งแรกของ Rails ในสมัยนั้นช่างน่าทึ่งจริงๆ วันนี้อาจดูไม่น่าประทับใจนัก แต่จำไว้ว่าเหตุผลเดียวที่เราทุกคนรู้เกี่ยวกับ Java ก็คือทุกคนรู้สึกตื่นเต้นกับความเป็นไปได้ในการเรียกใช้ Java Applet ในเบราว์เซอร์ สิ่งนี้กลับกลายเป็นว่าไม่ได้มีความสำคัญมากนัก แต่ถึงกระนั้นสิ่งนี้ก็ทำให้ Java อยู่ในเรดาร์ ในทำนองเดียวกัน screencast เอ็นจิ้นบล็อกความยาว 15 นาทีนี้ได้รับความนิยมอย่างมากที่ทำให้ผู้คนจำนวนมากตื่นเต้น

นี่ไม่เกี่ยวกับความไร้สาระด้วยซ้ำ มันเกี่ยวกับการมีส่วนร่วมกับคนฉลาดๆ ให้มากที่สุดเท่าที่จะทำได้เพื่อเติมน้ำลงในโรงสี เมื่อพิจารณาถึงกรอบงานแล้ว ที่ที่ดีที่สุดที่จะอยู่ในฝูงชน การเลือกกรอบการทำงานที่คนฉลาดเหล่านี้มุ่งเน้นก็หมายความว่าคุณได้ครอบคลุมพื้นที่มากขึ้นแล้ว และนี่นำฉันไปสู่จุดต่อไปของฉัน

(ไม่) คิดค้นล้อใหม่

ฉันมีจุดอ่อนสำหรับเฟรมเวิร์กขนาดเล็ก ฉันชอบเวลาที่ฉันสามารถเข้าใจได้ว่ากรอบงานใดกำลังทำอะไรอยู่และทำไม ในแง่นี้ Rails ค่อนข้างจะบวมและบางครั้งก็ท่วมท้น

ภาวะที่กลืนไม่เข้าคายไม่ออกที่นี่: คุณต้องการเขียนสิ่งเดียวกันซ้ำแล้วซ้ำอีกกี่ครั้ง? บางส่วนสามารถเขียนใหม่ได้ดีกว่าฉันแน่ใจ แต่ต้องใช้เวลามาก ยิ่งคุณอนุญาตให้ Rails ทำเพื่อคุณมากเท่าไหร่ คุณก็ยิ่งไม่ต้องกังวลกับการเขียนซ้ำหรือการนำฟังก์ชันของคุณไปใช้ใหม่

Rails คือ (ตามที่พวกเขาพูด) 'รวมแบตเตอรี่' นี่ไม่ใช่เรื่องดีหากคุณสนใจเรื่องความเบาบางหรือถ้าคุณรู้สึกว่าจำเป็นต้องมีความรู้กว้างขวางเกี่ยวกับวิธีการทำงานของทุกอย่าง ในทางปฏิบัติ หากคุณละทิ้งความกลัว ดูเหมือนว่าจะได้ผล Rails มีค่าเริ่มต้นที่สมเหตุสมผลสำหรับเกือบทุกอย่างที่คุณต้องการ และเป็นแบบแยกส่วนพอที่จะหลีกเลี่ยงไม่ให้คุณต้องเข้าโค้ง

บทสรุป

ถามตัวเองอีกครั้ง ทำไมต้องใช้ Ruby on Rails? Rails เหมาะสำหรับทั้งเว็บไซต์สาธารณะที่ล้ำสมัยที่แข่งขันกับแอปพลิเคชัน JavaScript หน้าเดียว และแอปพลิเคชันระบบหลักขององค์กรที่ซับซ้อนซึ่งมักจะดู 'น่าเกลียด' เล็กน้อย (ด้วย UI ทั่วไปที่มีความเที่ยงตรงต่ำกว่า) แต่ชดเชยสิ่งนี้ มีปัญหากับกฎเกณฑ์ทางธุรกิจและตรรกะที่ซับซ้อนมากมาย ประโยชน์ของมันคือมันอเนกประสงค์และสามารถแข่งขันกับทั้งที่โฉบเฉี่ยวและทรงพลัง

สำหรับปัญหาทั่วไปส่วนใหญ่ Rails มีองค์ประกอบพร้อมให้คุณใช้งานเกือบจะทันทีพร้อมเอกสารประกอบที่สูงกว่าค่าเฉลี่ยอย่างสม่ำเสมอ (อย่างไรก็ตาม ทีมงานหลักของ Rails ได้ชักชวนผู้ร่วมให้ข้อมูลว่าการเขียนเอกสารนั้นยอดเยี่ยม (แม้ว่าเราทุกคนจะทราบดีอยู่แล้วก็ตาม) ไม่ได้) นำไปสู่เอกสารที่เขียนได้ดี กระชับ และประหยัดเวลา)

เมื่อคุณเลิกใช้ยูนิคอร์นและกอดในวันศุกร์ คุณจะได้เฟรมเวิร์กอันทรงพลังที่สามารถใช้ได้ทั้งสำหรับผู้เปลี่ยนเกมในอนาคตและเว็บไซต์ธุรกิจกลางถนนแห่งต่อไปของคุณ และด้วยแหล่งรวมอัญมณีระดับแนวหน้า คุณมีคลังแสงเพียงปลายนิ้วสัมผัสที่จะนำแนวคิดที่เฉียบแหลมที่สุดในการเขียนโปรแกรมคอมพิวเตอร์มาใช้ ด้วยความไม่วุ่นวาย

ที่เกี่ยวข้อง: การตัดทอนเวลา: A Ruby on Rails ActiveRecord Tale