Computer >> คอมพิวเตอร์ >  >> การเขียนโปรแกรม >> Ruby

วิธีเอาชนะการผัดวันประกันพรุ่งในโครงการรถไฟใหม่ของคุณ

คุณเพิ่งพิมพ์ rails new ในโครงการต่อไปของคุณ ตอนนี้อะไร? คุณจะเริ่มต้นที่ไหน คุณเขียนทุกอย่างในแอปเดียวหรือไปกับ Service Oriented Architecture? นี่เป็นเวลาที่ดีในการเรียนรู้ RSpec หรือไม่ คุณควรเริ่มสร้างแบบจำลองข้อมูลทั้งหมดของคุณ หรือดำเนินการบางอย่างที่ทำงานแบบ end-to-end? มีการตัดสินใจมากมายที่คุณต้องตัดสินใจล่วงหน้า และมันง่ายที่จะรู้สึกหลงทาง ผัดวันประกันพรุ่ง และหงุดหงิด และไม่เคยทำให้แอปของคุณเสร็จ

ปัญหานี้เป็นเรื่องธรรมดามาก มันมาจากการเลือกล่วงหน้ามากเกินไป เมื่อคุณมีข้อมูลน้อยที่สุดที่คุณต้องใช้ในการตัดสินใจอย่างมีการศึกษา

คอนเวนชั่นเหนือการตัดสินใจ

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

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

ต่อไปนี้คือข้อตกลงบางประการที่ฉันปฏิบัติตามเมื่อเริ่มแอปใหม่:

  • เริ่มด้วยคุณสมบัติเต็มรูปแบบบางส่วน

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

  • เริ่มต้นด้วยแอปเดียว

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

    SOA เป็นวิธีที่ยอดเยี่ยมในการแยกแอปขนาดใหญ่และซับซ้อนออกจากกัน แต่มันเพิ่ม ตัน ของความเจ็บปวด และเว้นแต่ความเจ็บปวดจากการสร้าง การบำรุงรักษา และการตรวจสอบบริการจะมีค่ามากกว่าความเจ็บปวดในการทำงานกับแอป Rails แบบเสาหินของคุณ ก็ไม่คุ้มค่าที่จะทำ และถ้าคุณยังไม่ได้เริ่ม การเขียนแอปของคุณยังไม่รู้สึกเจ็บปวด เริ่มต้นด้วยแอปเดียว

  • เริ่มต้นด้วยสแต็กที่คุณเคยใช้มาก่อน

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

ขนส่งลำบาก. หากคุณต้องการทำให้แอปของคุณเสร็จ คุณจะต้องขูดรีดทุกข้อได้เปรียบที่คุณจะได้รับ ดังนั้นให้เริ่มเล็ก ๆ เริ่มง่าย ๆ และเริ่มต้นด้วยสิ่งที่คุณรู้

การประชุมอาจไม่สมบูรณ์แบบเสมอไป แต่จะช่วยให้คุณเริ่มต้นได้ และการเริ่มต้นเป็นส่วนที่ยากที่สุด

มีอะไรต่อไป

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