ปรัชญาความเชื่อของ Rails:
เรื่องนี้มาจาก The Rails Doctrine ที่เขียนโดย DHH ผู้สร้าง Framework Ruby on Rails ที่เขียนไว้ในเดือนมกราคม 2016
ในการสร้างเฟรมเวิร์คอะไรก็ตาม ส่วนตัวเชื่อว่าทีมผู้พัฒนามักจะมีแนวความคิด หรือความเชื่อ ในการที่จะตัดสินใจว่าเฟรมเวิร์คนี้ทำอะไรได้บ้าง และทำอะไรไม่ได้บ้าง ปรัชญาความเชื่อเหล่านี้จะเป็นเหมือนเข็มทิศที่บอกแนวทางของเฟรมเวิร์คนั้นต่อไปในอนาคต
โดยใน The Rails Doctrine นั้น มีอยู่ทั้งหมด 9 ข้อดังนี้
- Optimize for programmer happiness
- Convention over Configuration
- The menu is omakase
- No one paradigm
- Exalt beautiful code
- Provide sharp knives
- Value integrated systems
- Progress over stability
- Push up a big tent
ซึ่งแต่ละข้อเดี๋ยวจะขอสรุปไว้ตามทีเข้าใจนะครับ อาจจะไม่ได้แปลมาตรงๆ เพราะรู้สึกว่าประโยคที่เขียนแอบดูเข้าใจยากพอสมควรในบางจุด
1. Optimize for programmer happiness
อย่างแรกสุดต้องยอมรับว่า Ruby เป็นภาษาที่เป็นแรงบันดาลใจในการสร้าง Rails มาก เป็นภาษาที่ค่อนข้างที่จะสามารถอธิบายสิ่งที่จะทำได้ เหมือนเขียนประโยคบอกเล่า DHH ให้ความเห็นว่า Ruby เป็นภาษาที่เกิดขึ้นมาเพื่อความสุขของคนเขียนโปรแกรม
สิ่งหนึ่งที่ Ruby มีคือ Principle of Least Surprise คร่าวๆ คือ เขาบอกว่าภาษาจะทำอย่างที่คุณคิดว่ามันทำ เช่น ถ้าต้องการออกจากโปรแกรม เราสามารถพิมพ์ exit หรือ quit ได้ หรือถ้าเราใช้ method กับ object ที่เป็นเอกพจน์เราอาจจะใส่ s ตามหลังได้
ทาง DHH เลยเสริมจากเรื่องนี้ให้เป็น Principle of Bigger Smile ทำยังไงให้คนใช้ Rails ยิ้มได้ ตัวอย่างเช่น เขาใส่ method ที่ช่วยสนับสนุนการทำงาน เช่นการแปลงเอกพจน์เป็นพหูพจน์ไป หรือการ method ประเภท Array#third เพื่อบอกว่าจะใช้ตัวที่ 3 ของ Array
2. Convention over Configuration
เขาเปิดด้วยประโยคที่ว่า
“You are not a beautiful and unique snowflake”
สิ่งหนึ่งสำหรับใครที่เป็นสายรายละเอียดต้องปรับตัวเมื่อมาใช้ Ruby คือ การลดรายละเอียดเล็กๆน้อยๆ เช่น ต้องเลิกไปซีเรียสหรือจับเจ่าว่า จะตั้ง Primary Key ของ Table ใน Database ว่าอะไร
ทั้งนี้เขาให้เหตุผลว่า ถ้าละทิ้งความเป็นเฉพาะตัวลง จะสามารถก้าวข้ามการตัดสินใจมากมาย และจะได้ให้เวลาในการทำสิ่งที่ควรทำจริงๆ ให้ก้าวหน้าและรวดเร็วขึ้น
ถ้าใครใช้ Rails ก็จะพอเข้าใจว่าเหตุผลหนึ่งที่การ Deploy บน Rails มันเร็ว คือ Library ต่างๆ มันจัดให้หมดแล้ว จนไม่ต้องไปวุ่นวายกับการกำหนด Schema อะไรให้มากมาย ซึ่งตรงนี้จะมีข้อดีคือ
- ลดการตัดสินใจในระดับลึกได้มากมาย
- มี Convention ที่เข้าใจง่าย เพราะเป็น Abstraction เยอะ เช่น :has_many ใน ActiveRecord
- มี Low Barrier of entry ผู้ที่เริ่มต้นเข้ามาช่วยพัฒนา สามารถทำความเข้าใจได้ไม่ยากนัก
3. Menu is Omakase
อันนี้จะดูคล้ายๆ กับข้อที่ 2 กล่าวโดยคร่าวๆ คือ ปกติแล้วในการพัฒนาระบบอะไรสักอย่างเราจะต้องไปนั่งพิจารณา Library ต่างๆ ว่าจะใช้อะไร เหมือนดูเมนูอาหาร แล้วเอาสิ่งเหล่านั้นมาประกอบกัน
แต่ Rails จะเอา Library ต่างๆ มาจัดสรรและเสิร์ฟให้เราใช้งานเป็นเซ็ต เหมือนกับ Omakase จาก Chef ซึ่งก็คือ Core Team จาก Rails นั่นเอง โดยทางทีมงานจะการันตีความเข้ากันของ Stack ให้เรียบร้อยแล้ว ซึ่งจะมีข้อดีคือ
- เมื่อเป็น ระบบเดียวกันหมด ก็ทำให้การเรียนรู้ หรือช่วยเหลือคนในทีมสามารถทำได้ง่าย
- ส่วนต่างๆ สามารถเปลี่ยนได้ แต่ไม่จำเป็นต้องเปลี่ยน ซึ่งถ้าเรา Dev ไปจนเข้าใจว่าเราต้องการที่จะทำอะไรอย่างชัดเจนแล้ว ก็สามารถที่จะปรับเปลี่ยนให้เหมาะสมได้
4. No One Paradigm
หลักๆ ของข้อนี้คือ ในการทำ Rails ไม่ได้มีหลักการอะไรเป็นตัวหลักตัวเดียวที่สำคัญ โดยเขายกตัวอย่าง concept ของ Template, Presenter และ MVC ที่ปรับเปลี่ยนไปมาได้ หรือในปัจจุบันที่มีส่วน javascript ที่เป็น React เข้ามา
5. Exalt Beautiful Code
หลักๆ ของข้อนี้คือ นอกจากที่จะทำให้โค้ดของ Rails สามารถสื่อสารได้กับทั้งเครื่องและผู้ร่วมงานแล้ว ยังต้องมีความสวยงามด้วย โดยความสวยงามในกรณีนี้จะเป็นส่วนผสมระหว่าง แนวทางของ Ruby และ Domain Specific-Language
ยกตัวอย่างเช่น ถ้าต้องการ ตรวจสอบว่า ตัวแปร person อยู่ใน people หรือไม่ เราสามารถเขียนได้เป็น
if people.include? personแต่เราก็สามารถเขียนแบบนี้ได้เช่นกัน
if person.in? peopleทั้งสองอย่างนี้ได้ผลลัพธ์ที่เหมือนกัน แต่อยากให้สังเกตว่า แบบหลังจะตรงกับสามัญสำนึกในการอ่านทั่วไปของคนเรามากกว่า หรือในอีกมุมหนึ่งคือ flow การอ่านและทำความเข้าใจมันไหลลื่นกว่านั่นเอง
6. Provide Sharp Knives
สำหรับข้อนี้ ง่ายๆ คือเขาเปรียบว่าเขาจะให้มีดที่คมมากๆ ถ้าใครเป็นพ่อครัวมีดคมๆ จะช่วยเพิ่มประสิทธิภาพการแล่เนื้อได้มาก แต่ถ้าใครเป็นมือใหม่ มีดเดียวกันก็อาจจะทำให้เลือดตกยางออกได้เช่นเดียวกัน
เขายกตัวอย่างเคสของ Ruby คือ ตัวภาษาจะมีความสามารถในการทำ Monkey Patching หรือ การเปลี่ยนแปลง implementation ของ Class หรือ method ได้
เช่น เราสามารถแก้ไข String#capitalize ให้สามารถที่จะเป็นอักษรตัวใหญ่ทั้งหมดแทนที่จะเป็นเฉพาะตัวหน้า
ณ จุดนี้ น่าจะมีคนที่กังวลว่า Feature นี้อาจจะถูกเอาไป Abuse ได้
แต่ทาง DHH ก็มีความเชื่อว่า เราไม่ควรจะปิด Feature เพราะกลัวเรื่องพวกนี้ แล้วให้เขาไปใช้อะไรก็ไม่รู้ที่มันดีไม่พอ
แล้วก็มีแซะเล็กน้อยว่า ส่วนใหญ่ที่กลัวคือ กลัวคนอื่นทำ แต่ไม่เคยมีใครเคยบอกว่า ปิด Feature เถอะ เพราะตัวเองไม่เชื่อมั่นว่าจะควบคุมได้
ส่วนตัวชอบในประโยคที่เขาเขียนว่า ภาษา/framework จะต้องเป็นผู้สอนที่อดทนพอที่จะช่วยเหลือและนำนักพัฒนาไปสู่ความเป็นมืออาชีพ
Language & Framework should be patient tutors willing to help and guide anyone to experthood
7. Value Integrated System
อันนี้ในมุมของ Engineering น่าจะเป็นข้อที่ดูขัดใจมากที่สุด นั่นคือ เขามองว่า Rails จะเป็นระบบที่จัดการทุกอย่างให้เสร็จในตัว หรือพูดเป็นศัพท์ก็คือ Monoliths นี่เอง
โดย Rails จะช่วยให้ผู้พัฒนาสามารถทำระบบแบบสมบูรณ์ได้ แม้ว่าจะไม่ได้เป็น Specialist มากก็ตาม โดยสิ่งที่ได้ในการทำเป็นระบบ Monolith คือ
- มันจะตัด Abstraction ที่ไม่จำเป็น เช่น ต้องไปทำ interface ที่คล้ายๆ กันทั้ง Backend และ Frontend
- ลดความซ้ำซ้อนระหว่างชั้น มีหลายครั้งที่เวลาเราแยก Service แล้ว เราก็ไปเจอว่าต้องเขียน code ซ้ำ กัน
- หลีกเลี่ยงการแยกระบบ ก่อนที่มันจะจำเป็นต้องแยกจริงๆ
เขาน่าจะเจอว่าสมัยนี้ มีความเชื่อผิดๆ ที่ว่า จะทำ Internet App จะต้องแยกส่วนต่างๆ มากมายไม่ว่าจะเป็น Front/ Back , Mobile ซึ่งเขารู้สึกว่ามันไม่เป็นธรรมชาติ และอาจจะก่อนให้เกิดปัญหาความซับซ้อนในการคุยกันระหว่าง Component อีก
ตรงนี้ส่วนตัวกลับไปที่ ประโยคในตำนานของ Donald Knuth ที่ว่า Premature Optimization is the root of evils
ทาง DHH ก็คงคิดว่า Premature distribution is the root of evils เช่นเดียวกัน
ซึ่งถ้าสุดท้ายมันจำเป็นที่จะต้องแยกกัน เราก็ค่อยแยกภายหลังได้
8. Progress over Stability
ข้อนี้ความหมายคือ เขาเลือกที่จะให้ Rails เติบโตและตอบรับกับสิ่งทีเข้ามาใหม่ มากกว่าจะรักษา Compatibility กับระบบที่ใช้กับ Rails version เก่าๆ
สาเหตุสำคัญคือ ถ้าไม่ทำ Rails ก็จะไม่โตและไม่สามารถอยู่รอดในโลกได้ในอนาคต
ดังนั้น Rails จึงต้องกล้าที่จะเปลี่ยนแปลงและในบางครั้งอาจจะมีการ Break Behavior เดิม
ซึ่งเขาก็เคยเจ็บมา จากการ migrate จาก rails 2.x ไป rails 3.x
ส่วนตัวผมเองก็เจอหนักอยู่เพราะ migrate จาก 2 เป็น 6 เลย
ผลที่ได้คือการที่เราได้เห็น library ใหม่ๆ มาช่วยให้การพัฒนาดีขึ้นเช่น Bundler , Pipeline, Spring หรือแม้กระทั่ง React
จุดที่สำคัญที่จะทำให้สิ่งนี้เกิดขึ้นคือทีมงาน ดังนั้นทีมงาน Core, Committer ของ Rails จะมีการรับคนใหม่ๆ เรื่อยๆ เพราะคนใหม่ๆ ตาม Generation จะรู้ว่าปัจจุบันแนวโน้มของระบบเป็นยังไง
9. Push up a big tent
สำหรับข้อนี้คือ Community ของ Rails เป็น community ที่ใหญ่ แต่เขาก็ต้องการความเห็นต่าง ความหลากหลาย การ contribute หรือการโต้เถียงจะทำให้เกิดการพัฒนา
เขายกตัวอย่างเช่น เริ่มต้นเขาก็ไม่ได้เห็นด้วยกับเรื่อง Rspec หรือ Rails API แต่สุดท้ายมันก็สามารถไปได้
สิ่งสำคัญในการทำเรื่องนี้คือการทำให้ Community ต้อนรับทุกคน และต้องขอบคุณในทุก contribution ที่ทำให้เกิดความก้าวหน้าใน Community
ก็หวังว่าจะเป็นประโยชน์ครับ ใครสนใจบทความเต็มๆ ก็อ่านได้ที่