अपने नए रेल्स प्रोजेक्ट में महारत हासिल करें: टालमटोल दूर करने की सिद्ध रणनीतियाँ

आपने अपने अगले प्रोजेक्ट पर rails new टाइप किया है। अब क्या? कहां से शुरू करें? क्या आप सब कुछ एक ही ऐप में लिखते हैं, या सर्विस ओरिएंटेड आर्किटेक्चर के साथ जाते हैं? क्या RSpec सीखने का ये अच्छा समय है? क्या आपको अपने सभी डेटा मॉडल्स बनाना शुरू करना चाहिए, या कुछ एक्शन्स को एंड-टू-एंड काम करना चाहिए? आपको शुरुआत में ढेर सारे निर्णय लेने होते हैं, और खोया हुआ, टालमटोल करना, निराश होना और अपना ऐप कभी खत्म न करना आसान है।

ये समस्या बहुत आम है। ये बहुत सारे विकल्पों को शुरुआत में ही चुनने से आती है, जब आपके पास एक शिक्षित निर्णय लेने के लिए सबसे कम जानकारी होती है।

निर्णय लेने पर कन्वेंशन

कन्वेंशन ओवर कॉन्फिगरेशन मेरा पसंदीदा रेल्स सिद्धांत है। रेल्स से पहले, मैं फाइलें कहां रखनी हैं, डेटाबेस टेबल्स को क्या नाम देना है, उन्हें ऑब्जेक्ट्स पर कैसे मैप करना है, और ढेर सारे अन्य छोटे अर्थहीन निर्णयों में फंस जाता था। मैं दिशा चुनने में अधिक समय बिताता था जितना कि बाद में अपना मन बदलने में लगता अगर मुझे पता चलता कि मैं गलत था।

नया प्रोजेक्ट शुरू करते समय आपके सामने आने वाले बहुत सारे निर्णय इनके जैसे ही होंगे। लेकिन आप इन निर्णयों को बदल सकते हैं अगर आप किताबों, ब्लॉग्स या स्टाइलगाइड्स से कन्वेंशन्स उधार लेते हैं। और आप खुद को बहुत समय, तनाव और अर्थहीन बहस से बचा लेंगे।

यहाँ कुछ कन्वेंशन्स हैं जिनका पालन मैं नया ऐप शुरू करते समय करता हूँ:

• कुछ पूर्ण फीचर्स के साथ शुरू करें।

  आपके ऐप को तुरंत वो सब कुछ करने की ज़रूरत नहीं है जो आप सोच सकते हैं। छोटा शुरू करें, सरल शुरू करें। उन एक या दो फीचर्स का पता लगाएं जिनके बिना आप नहीं रह सकते, और अपना सारा ध्यान पहले उन पर केंद्रित करें। उन्हें वास्तव में अच्छी तरह बनाएं। आप बाद में दूसरी चीजें जोड़ सकते हैं अगर आपको उनकी ज़रूरत हो। लेकिन शायद, YAGNI। (और आप आमतौर पर पाएंगे कि जो आपको लगता है कि आपको चाहिए वो आपके ग्राहकों की सोच से पूरी तरह अलग है)।

• एक सिंगल ऐप के साथ शुरू करें।

  मुझे पता है, आप मोनोरेल बनाने से बचना चाहते हैं। और आधा दर्जन रेल्सकॉन्फ बातें हैं कि SOA लंबे समय में रेल्स ऐप्स को बनाए रखने योग्य रखने का सबसे अच्छा तरीका है। क्या आपको ये नहीं पता लगाना चाहिए कि आपके ऐप के कौन से हिस्से स्वतंत्र हो सकते हैं, और प्रत्येक भाग के लिए एक सर्विस बनानी चाहिए?

  SOA एक बड़े, जटिल ऐप को तोड़ने का एक शानदार तरीका है। लेकिन ये बहुत दर्द जोड़ता है, और जब तक सर्विसेज बनाने, बनाए रखने और मॉनिटर करने का दर्द आपके मोनोलिथिक रेल्स ऐप पर काम करने के दर्द से अधिक न हो, ये करने लायक नहीं है। और अगर आपने अभी तक अपना ऐप शुरू नहीं किया है, तो आप उस दर्द को महसूस नहीं कर रहे हैं। तो, एक ऐप के साथ शुरू करें।

• एक ऐसे स्टैक के साथ शुरू करें जिसे आपने पहले इस्तेमाल किया हो।

  अगर आप अभी तक किसी स्टैक को नहीं जानते, तो बस ओमाकास स्टैक का उपयोग करें। लेकिन किसी भी तरह से, आप एक ऐसे टेस्ट फ्रेमवर्क को रेल्स के साथ इंटीग्रेट करने में आधा दिन बर्बाद नहीं करना चाहते जिसे आपने पहले कभी इस्तेमाल नहीं किया। आप VCR और WebMock के बीच वर्जन कन्फ्लिक्ट्स से नहीं लड़ना चाहते। आप ये पता लगाने में समय नहीं गंवाना चाहते कि आपके टेस्ट्स का क्रैश होना आपकी गलती है या resque_unit की। अगर आप कोई नई लाइब्रेरी आज़माना चाहते हैं, तो आप इसे बाद में हमेशा जोड़ सकते हैं (या किसी टॉय प्रोजेक्ट पर आज़मा सकते हैं)।

शिप करना कठिन है। अगर आप अपना ऐप खत्म करना चाहते हैं, तो आपको हर उस लाभ के लिए लड़ना होगा जो आप प्राप्त कर सकते हैं। तो छोटा शुरू करें, सरल शुरू करें, और जो आप जानते हैं उसके साथ शुरू करें।

कन्वेंशन्स हमेशा परफेक्ट नहीं हो सकते, लेकिन ये आपको शुरू करने में मदद करेंगे। और शुरू करना सबसे कठिन हिस्सा है।

आगे क्या है?

आप अपने प्रोजेक्ट्स पर किन कन्वेंशन्स का पालन करते हैं? और आप कैसे तय करते हैं कि किन फीचर्स या टेस्ट्स से शुरू करना चाहिए? मैं अगली बार अपने विचार साझा करूंगा, लेकिन मुझे आपके कुछ विचार सुनना अच्छा लगेगा।