रेल डेवलपर्स द्वारा 5 सामान्य गलतियाँ

मैंने कुछ समय के लिए रेल के साथ काम किया है, और इस दौरान मैंने कई रेल एप्लिकेशन देखे हैं, और बहुत सारे रूबी कोड भी पढ़े और लिखे हैं। और यहां 5 सबसे आम त्रुटियां हैं जो मैंने लगभग हर एप्लिकेशन में देखी हैं।

1. प्रतिबंध के बिना प्रवासन

आपका डेटा मॉडल आपके एप्लिकेशन का दिल है। योजना के प्रतिबंध के बिना, आपके कोड में बग के कारण, डेटा धीरे-धीरे नष्ट हो जाएगा जब तक आप अपने डेटाबेस में एक भी फ़ील्ड पर पूरी तरह से भरोसा नहीं कर सकते। यहाँ संपर्क मॉडल का आरेख है:

create_table "contacts" do |t| t.integer "user_id" t.string "name" t.string "phone" t.string "email" end 

यहाँ क्या गायब है? सबसे अधिक संभावना है कि संपर्क उपयोगकर्ता ( उपयोगकर्ता ) के अंतर्गत आता है ( rel_to ) और संपर्क में कम से कम एक नाम होना चाहिए - इसके लिए डेटाबेस प्रतिबंध का उपयोग करें। " : Null => false " जोड़कर हम हमेशा मॉडल की अखंडता के बारे में सुनिश्चित होंगे, भले ही हमारे सत्यापन कोड में कीड़े हों, क्योंकि डेटाबेस खुद हमें एक मॉडल को बचाने की अनुमति नहीं देगा जो इन प्रतिबंधों का उल्लंघन करता है।

 create_table "contacts" do |t| t.integer "user_id", :null => false t.string "name", :null => false t.string "phone" t.string "email" end 

बोनस संकेत : अपने स्ट्रिंग फ़ील्ड के उचित आकार को इंगित करने के लिए " : limit => N " का उपयोग करें। डिफ़ॉल्ट रूप से, लाइन की लंबाई 255 वर्णों पर सेट है, और शायद " फोन " फ़ील्ड को इस आकार की बिल्कुल भी आवश्यकता नहीं है, क्या यह तर्कसंगत है?

2. ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग

अधिकांश रेल डेवलपर ऑब्जेक्ट-ओरिएंटेड रूबी कोड नहीं लिखते हैं। वे वांछित फ़ोल्डरों में मॉडल और नियंत्रकों का विस्तार करके एमवीसी-उन्मुख कोड लिखते हैं। कुछ सहायक विधियों को क्लास के तरीकों के साथ "lib" फ़ोल्डर में जोड़ते हैं, लेकिन अधिक नहीं। डेवलपर को पता चलने से पहले यह 2-3 साल तक रहता है: “रेल सिर्फ रूबी है। मैं साधारण वस्तुएं बना सकता हूं और उन्हें फ्रेमवर्क के साथ तैयार कर सकता हूं, जैसा कि वह पसंद करता है, न कि जैसा वह निर्धारित करता है। "

बोनस संकेत : आपके द्वारा उपयोग की जाने वाली तृतीय-पक्ष सेवाओं के लिए facades बनाएं। अपने परीक्षणों में उपयोग के लिए एक मुखौटा-नकली बनाएं, ताकि परीक्षण के दौरान तृतीय-पक्ष सेवाओं को न खींचा जाए।

3. सहायकों में एचटीएमएल कॉन्‍टेनेटेशन

यदि आप सहायक तरीके (अच्छी तरह से किया है!) बनाते हैं, तो कम से कम आप अपने टेम्पलेट्स को साफ रखने की कोशिश कर रहे हैं। लेकिन बहुत बार, डेवलपर्स को सहायकों के अंदर टैग बनाने की मूल बातें नहीं पता होती हैं, जिससे चिपके हुए लाइनों का एक हैश होता है।

 str = "<li class='vehicle_list'> " str += link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title)) str += " </li>" str.html_safe 

टिन! यह बदसूरत है और आसानी से XSS कमजोरियों की ओर जाता है। content_tag आपका दोस्त है!

 content_tag :li, :class => 'vehicle_list' do link_to("#{vehicle.title.upcase} Sale", show_all_styles_path(vehicle.id, vehicle.url_title)) end 

बोनस संकेत : एक तर्क के रूप में एक ब्लॉक लेने वाले सहायकों का उपयोग करना शुरू करें। नेस्टेड HTML उत्पन्न करने की आवश्यकता होने पर नेस्टेड ब्लॉक बहुत अच्छे हैं।

4. विशाल प्रश्न सब कुछ स्मृति में लोड करते हैं

आपको डेटा में कुछ ठीक करने की आवश्यकता है और आप बस उन सभी को एक लूप में जाते हैं और इसे ठीक करते हैं?

 User.has_purchased(true).each do |customer| customer.grant_role(:customer) end 

अब कल्पना करें कि आपके पास एक वाणिज्यिक साइट और एक मिलियन उपयोगकर्ता हैं। उपयोगकर्ता वर्ग के प्रत्येक ऑब्जेक्ट को मेमोरी में 500 बाइट्स पर कब्जा करने दें। आपका कोड 500 एमबी मेमोरी खा जाएगा। बेहतर विकल्प:

 User.has_purchased(true).find_each do |customer| customer.grant_role(:customer) end 

find_each आंतरिक रूप से find_in_batches पद्धति का उपयोग करता है, एक बार में 1000 रिकॉर्ड का चयन करता है और मेमोरी खपत को काफी कम करता है।

बोनस संकेत : बल्क डेटा अपडेट करने के लिए update_all या नंगे SQL का उपयोग करें। SQL को सीखने में कुछ समय लगता है, लेकिन आपको मिलने वाले लाभ बहुत अधिक होंगे: x100 प्रदर्शन में सुधार।

5. कोड की समीक्षा

मैं मानता हूं कि आप GitHub का उपयोग कर रहे हैं, और मैं यह भी मानता हूं कि आप पूल अनुरोध का उपयोग नहीं कर रहे हैं। यदि आप एक नई सुविधा को लागू करने के लिए एक या दो दिन बिताते हैं, तो इसे एक अलग शाखा में करें और पूल अनुरोध का उपयोग करें। आपकी टीम आपके कोड की जांच करने में सक्षम होगी, सुझाव दे सकती है कि क्या सुधार किया जा सकता है, और आपको कुछ बिंदुओं की ओर भी इशारा करता है जिन्हें आप देख सकते हैं। मैं गारंटी देता हूं कि इससे आपके कोड की गुणवत्ता में सुधार होगा।

बोनस संकेत : परीक्षण के बिना पूल अनुरोधों को स्वीकार न करें जो सफल हैं। परीक्षण आपके आवेदन को स्थिर रखने और आपकी आरामदायक नींद के लिए अमूल्य है।

---

बोनस: मूल लेख पर उपयोगी टिप्पणी

find_each और find_in_batches बड़े चयनों के लिए पसंद किए जाते हैं , लेकिन ध्यान रखें कि आप डेटाबेस के लिए एप्लिकेशन मेमोरी को प्रोसेसर साइकल में बदल रहे हैं।

मान लें कि आप एक क्वेरी बनाते हैं जो 1'000'000 रिकॉर्ड लौटाती है।

 SELECT * FROM users WHERE unindexed_field = true; 

यदि आप User.all.each करते हैं, तो डेटाबेस एक बड़ी क्वेरी करेगा, एक बार में पूरे परिणाम की गणना करेगा। यदि आप User.where (...)। Find_each (: batch_size => 100) करते हैं , तो डेटाबेस को समान क्वेरी 1'000'000 / 100 = 10'000 बार करनी होगी। और यदि आप MySQL का उपयोग करते हैं, तो यह हर बार फिर से परिणाम का वर्णन करेगा। यानी रिकॉर्ड 100-200 के लिए वह पहले 200 रिकॉर्ड की गणना करेगा, 200-300 के लिए - पहले 300 रिकॉर्ड, फिर 300-400 के लिए - पहले 400 रिकॉर्ड और इतने पर 999900-1000000 तक।

इसलिए बड़े चयनों के लिए, find_each या find_in_batches का उपयोग करना बेहतर है, लेकिन ध्यान रखें कि यह आपके लिए समस्याएँ भी पैदा कर सकता है।

इस समस्या को हल करने के लिए सामान्य "हैक" इस प्रकार है:

 ids = User.where(...).select(:id).all ids.in_groups_of(100) do |id_group| # ... end