3 पार्टी एक्सटेंशन का मूल्यांकन कैसे करें?


41

जबकि Magento बहुत सारे 'आउट ऑफ द बॉक्स' करता है, हमने पाया है कि ग्राहक स्टोरों के लिए आवश्यक सुविधाएँ और सुविधाएँ हैं जिन्हें 3 जी एक्सटेंशन की आवश्यकता है।

हालांकि, माध्यम की प्रकृति को देखते हुए, वाणिज्यिक लेनदेन से निपटने वाली ऐसी जटिल प्रणाली के लिए 'विदेशी' कोड पेश करना एक जोखिम भरा प्रस्ताव हो सकता है।

Magento एक्सटेंशन का मूल्यांकन करते समय आप क्या देखते हैं? आपके द्वारा प्रदर्शन किए गए 'लाल झंडे' (प्रदर्शन हॉग, सुरक्षा जोखिम, वास्तु खराब अभ्यास) क्या हैं?


3
थोड़ा ग्लिब, लेकिन ग्रेप 'एवैल' * -आर। यदि आप इसे देखते हैं, तो दौड़ें।
आरोन बोनर

जवाबों:


27

3 पार्टी मॉड्यूल के मूल्यांकन के बारे में कुछ विचार इस प्रकार हैं:

मूल बातें:

  • वर्तमान Magento के संस्करण का समर्थन - क्या यह Magento के नवीनतम संस्करण का समर्थन करता है (वर्तमान में हम इसे विकसित कर रहे हैं सहित)?

    यदि कोई मॉड्यूल Magento की नवीनतम रिलीज़ का समर्थन नहीं करता है, तो उस पर कीमती विकास समय खर्च किए बिना इसे काम करना मुश्किल होगा।

  • समर्थन - क्या डेवलपर्स जिन्होंने मॉड्यूल बनाया उत्पाद का समर्थन करते हैं?

    एक स्वस्थ मॉड्यूल के संकेतों में से एक यह है कि डेवलपर्स सक्रिय रूप से इसका समर्थन करते हैं। यदि वे इसका समर्थन नहीं करते हैं तो यह लाल झंडा है, अगर यह अच्छा है तो वे उत्पाद का समर्थन क्यों नहीं करेंगे?

    इसके अतिरिक्त, जब कोई मॉड्यूल समर्थित होता है, तो हम आमतौर पर डेवलपर्स से एक साधारण ईमेल के साथ महत्वपूर्ण जानकारी प्राप्त कर सकते हैं (उदाहरण के लिए, क्या यह मॉड्यूल jQuery या प्रोटोटाइप का उपयोग करता है)।

  • समीक्षाएं - अन्य उपयोगकर्ता क्या कह रहे हैं? उनका अनुभव कैसा रहा?

    समीक्षाओं को पढ़ने से हम बड़ी तस्वीर का बेहतर अर्थ प्राप्त कर सकते हैं, क्या कोई स्थापना मुद्दा है? क्या डेवलपर्स समय पर और सहायक तरीके से प्रतिक्रिया करते हैं? क्या यह विज्ञापन के रूप में काम करता है?

  • धनवापसी - क्या वे आपको अपना पैसा वापस देंगे यदि यह इरादा के अनुसार काम नहीं करता है?

    कई बार हम मॉड्यूल को आज़माना चाहते हैं ताकि हम इसका परीक्षण कर सकें, अगर यह काम करता है और हमारे विनिर्देशों को पूरा करता है! लेकिन अगर ऐसा नहीं है, तो हम इसे वापस करने और इसके लिए धनवापसी का विकल्प चाहते हैं।

इंटरमीडिएट:

  • क्लास ओवरराइड्स - क्या मॉड्यूल किसी कोर क्लास को ओवरराइड करता है?

    आम तौर पर एक अच्छा मॉड्यूल बोलते हुए किसी भी कोर वर्गों को ओवरराइड नहीं करना चाहिए, बल्कि इसका पालन करना चाहिए।

    इसका एक कारण, यह है कि यह Magento के उन्नयन को कठिन बना सकता है। इसके अतिरिक्त, अन्य मॉड्यूल किसी दिए गए फ़ंक्शन से एक आउटपुट के आधार पर हो सकते हैं, और यह मॉड्यूल एक अलग प्रदान कर रहा है।

    कभी-कभी ऐसा करना संभव नहीं होता है, यदि यह मामला है, तो एक बहुत अच्छा कारण होना चाहिए कि यह एक मुख्य वर्ग से आगे निकल रहा है।

  • लेआउट अपडेट - क्या मॉड्यूल मेरी लेआउट सेटिंग्स में से कुछ को बदलता है?

    कुछ मॉड्यूल आपकी साइट के लिए लेआउट सेटिंग्स को बदलते हैं (उदाहरण के लिए: उत्पाद पृष्ठ), सुनिश्चित करें कि यह आपके वर्तमान लेआउट को नहीं तोड़ता है, और यदि ऐसा होता है तो इसकी आवश्यकता होगी (पढ़ें: इसे ठीक करने में हमें कितना समय लगेगा) ।

  • टेम्पलेट परिवर्तन - क्या मॉड्यूल में मेरे वर्तमान डिज़ाइन को बदलने वाले टेम्पलेट शामिल हैं?

    क्या यह मॉड्यूल नए टेम्पलेट पेश करेगा? यदि हाँ, तो क्या वे मेरे डिज़ाइन को तोड़ देंगे? जिस तरह से हम चाहते हैं उस डिजाइन को बनाने में कितना समय लगेगा?

  • निर्भरता - क्या मॉड्यूल किसी अन्य मॉड्यूल पर निर्भर करता है?

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

उन्नत:

  • एसक्यूएल अपग्रेड स्क्रिप्ट - क्या मॉड्यूल डीबी को किसी तरह से अपडेट करता है?

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

    क्या यह एक कोर तालिका को अद्यतन करता है? यदि हाँ, तो यह अच्छा नहीं है, हम अपने डेटाबेस को साफ और अपग्रेड के लिए तैयार करना पसंद करते हैं।

    क्या यह जानकारी को समझदार तरीके से संग्रहीत करता है? यदि हम डेटाबेस से डेटा को स्वयं प्राप्त करना चाहते हैं, तो क्या हम इसे समझ पाएंगे?

  • घटनाएँ - क्या मॉड्यूल किसी भी घटना का निरीक्षण या प्रेषण करता है?

    यदि कोई मॉड्यूल ईवेंट भेजता या देखता है, तो हम जानना चाहते हैं:

    यह किन घटनाओं का अवलोकन / प्रेषण है? क्या यह सिस्टम में काम करने वाले दूसरे मॉड्यूल को प्रभावित करेगा। उदाहरण के लिए, यदि हमारा कोई मॉड्यूल हमारे उत्पादों के नाम को लोड-अपरकेस में बदलता है, और यह मॉड्यूल उत्पाद को लोड करने के नाम पर 'मुक्त' शब्द जोड़ता है, तो यह कैसे काम करेगा? क्या 'मुक्त' शब्द भी ऊपरी आवरण से निकलेगा?

  • कोड की समीक्षा - क्या मॉड्यूल स्वीकार्य कोडिंग तकनीकों का उपयोग करता है?

    यह Magento की तुलना में PHP कोडिंग तकनीकों के साथ अधिक है।

    क्या कोड कोशिश / पकड़ ब्लॉक का उपयोग करता है?

    क्या कोड उपयोगकर्ता इनपुट से बच जाता है?

    इस की बारीकियाँ वास्तव में हमारे कौशल स्तर / आवश्यकताओं पर निर्भर करती हैं।

  • संभावित मुद्दे - इस मॉड्यूल को स्थापित करने के परिणामस्वरूप कौन से संभावित मुद्दे आ सकते हैं?

    शीर्ष पांच समस्याओं की कल्पना करने की कोशिश करें जो अगर हम इस मॉड्यूल को स्थापित कर सकते हैं, तो आश्चर्य की बात यह है कि यह हो सकता है, यह वास्तव में समग्र रूप से परियोजना को अंतर्दृष्टि प्रदान करता है।

जमीनी स्तर:

इन सभी चीजों को एक आदर्श दुनिया में होना अच्छा लगता है, वास्तविक दुनिया के परिदृश्यों में हमें 'समझौता' नामक इस चीज को करने की आवश्यकता है :)

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

दूसरे शब्दों में: यह हमारे समय के साथ कुशल होने के बारे में है, अगर इस (मद में) दिशानिर्देश का उपयोग करने से मुझे लंबे समय तक उपयोग में समय बचाने में मदद मिलती है, अगर इसे छोड़ना नहीं है और अपनी पवित्रता को बचाना है।


4
हो सकता है कि आप अपने शानदार जवाब में अपेक्षाकृत नई विधि जज को जोड़ना चाहते हों ...
साइमन

@ साझा करने के लिए धन्यवाद, और अधिक अच्छी तरह से जाँच करेगा और पोस्ट को अपडेट करेगा :)
pzirkind

1
जैसा कि साइमन ने जज के रूप में उल्लेख करना चाहा, थकाऊ कार्य मशीनों के लिए सबसे उपयुक्त हैं: github.com/magento-ecg/coding-standard यदि आप PHP_CodeSniffer का उपयोग करते हैं या एक PHP आधारित संस्करण भी मौजूद है: github.com/magento-ecg/ मैग्निफ़र और पीडीएफ लगभग 5 सबसे आम Magento कोडिंग मुद्दे: info.magento.com/rs/magentocommerce/images/…
B00MER

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

10

कुछ Magento के विशिष्ट "बुरे अभ्यास" लाल झंडे हैं:

  • किसी भी कोड में app/code/local/Mage
  • अधिलेखित टेम्प्लेट ( app/designउस फ़ाइल पहले से ही कोर में मौजूद हैं)
  • आवश्यक वर्गों की तरह फिर से लिखना catalog/product। सामान्य तौर पर मैं हर पुनर्लेखन को ध्यान से देखता हूं, यह देखने के लिए कि क्या इसे टाला जा सकता था
  • Zend / Magento कोडिंग मानकों का गंभीर उल्लंघन। जबकि यह केवल कोड स्वरूपण के बारे में है, मैं यह निष्कर्ष निकालता हूं कि मानकों के प्रति लापरवाह रहने वाले देव सबसे अधिक अन्य, अधिक महत्वपूर्ण, चीजों के बारे में लापरवाह होंगे।
  • कोर डेटाबेस तालिकाओं में परिवर्तन
  • टेम्प्लेट में कठिन कोडित पाठ (अनुवाद तंत्र का उपयोग नहीं करना) और अन्य जगहों पर
  • टेम्प्लेट में व्यावसायिक तर्क (अंगूठे का नियम: Mage::getModelटेम्प्लेट डायरेक्टरी में किसी भी तरह का प्रदूषण आमतौर पर एक बुरा संकेत है)

कुछ PHP संबंधित लाल झंडे (यह एक बहुत ही चयनात्मक और अपूर्ण सूची है):

  • सक्षम त्रुटि रिपोर्टिंग ( E_STRICT) के साथ कोई सूचना और चेतावनी
  • @ऑपरेटर का उपयोग
  • आउटपुट से पहले उपयोगकर्ता डेटा को साफ नहीं करना

कुछ प्रदर्शन संबंधित लाल झंडे:

  • डेटाबेस प्रश्न लूप के अंदर
  • केवल एक भाग का उपयोग करने के लिए एक संपूर्ण संग्रह लोड करना

सामान्य कोड गंध के लिए भी देखें , वे आवश्यक लाल झंडे नहीं हैं, लेकिन समग्र गुणवत्ता का अनुमान लगाने में मदद करते हैं।


4

चरण # 1 - क्या आपका ग्राहक इस विस्तार का समर्थन कर सकता है यदि डेवलपर AWOL जाता है?

यदि नहीं, तो आप एक्सटेंशन का उपयोग नहीं कर सकते।

यदि हाँ, विस्तार मूल्यांकन के लिए आगे बढ़ें।


2

Inchoo में ठीक लोगों के पास 3 पार्टी मॉड्यूल कोड के विश्लेषण पर एक लेख है । लेख में वर्ग पुनर्लेखन, क्रॉन जॉब्स, लेआउट अपडेट और घटना पर्यवेक्षकों का उल्लेख है।

मुझे उच्चतम प्रदर्शन हिट के लिए संभावित घटना कोड प्रेक्षक कोड मिला है। संसाधन गहन, तृतीय पक्ष कोड के लिए देखें जो अक्सर प्रेषित घटनाओं के लिए चलता है। कंट्रोलर_एक्शन_प्रोस्पीस्पैच, या कलेक्शन लोडिंग जैसी घटनाएँ।

मैं प्रिट्स्की से इस उपयोगिता मॉड्यूल का उपयोग पुनर्लेखन और पर्यवेक्षकों का एक अच्छा अवलोकन प्राप्त करने के लिए करता हूं।


क्या घटनाओं के कारण एक प्रदर्शन प्रभावित होगा? मैंने प्रेषण कोड पढ़ा और यह बहुत दुबला लग रहा है। एकमात्र समस्या वास्तविक लोडेड कोड होगी ...
बोरुच

@ दबोच यह मुझे भी संदिग्ध लग रहा था। लेख में वह गुणवत्ता नहीं है जिसका उपयोग मैं इनचू से करता हूं, विशेष रूप से यह हिस्सा भ्रामक है। पर्यवेक्षक ज्यादातर मामलों में एक्सटेंशन के लिए सबसे साफ समाधान करते हैं और मुझे यकीन है कि लेख उनके उपयोग को हतोत्साहित करने के लिए नहीं था, लेकिन इसे आसानी से इस तरह से पढ़ा जा सकता है। वे क्या कहते हैं कि यदि संभव हो तो *_afterघटनाओं के बजाय घटनाओं का उपयोग करना हमेशा प्राथमिकता दी जानी चाहिए *_before। प्रदर्शन के लिहाज से पर्यवेक्षकों के बारे में कोई बयान नहीं दिया गया है।
फैबियन शेंगलर

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

@fab - मैं पोस्ट का उल्लेख कर रहा था, बल्कि इंचू लेख। मैं लेख के औसत दर्जे के होने की गुणवत्ता के बारे में सहमत हूं। जहाँ तक पहले बनाम बनाम के बाद, स्पष्ट रूप से (प्रदर्शन, बग और अखंडता) के बाद का उपयोग करना बेहतर है, लेकिन कई बार यह असंभव है। उदाहरण के लिए कई बार हमें उपयोगकर्ता को पर्यवेक्षक से पुनर्निर्देशित करने की आवश्यकता होती है। केवल यह करना था कि पर्यवेक्षक-> getController-> एक पूर्व घटना पर पुनर्निर्देशित किया जाए। यह एक बेहतर तरीका है, फिर नियंत्रकों को
पछाड़ कर

1

आधार / डिफ़ॉल्ट के बजाय डिफ़ॉल्ट / डिफ़ॉल्ट (या प्रो या उद्यम) में स्थित किसी भी टेम्पलेट और त्वचा की संपत्ति का होना बहुत कष्टप्रद है।

Obfuscated कोड बाहर देखने के लिए कुछ है - eval (), base64_decode (), और जैसे कॉल की खोज करें। यह अक्सर लाइसेंस सत्यापन के लिए उपयोग किया जाता है, लेकिन दुर्भावनापूर्ण या डरावना हो सकता है - मैंने कम से कम एक घटक देखा है जो आरएसएस फ़ीड से मनमाना कोड निकालता है।

Dl () कॉल के लिए देखें - कम से कम एक भुगतान गेटवे घटक मैंने देखा है कि इसके कनेक्शन करने के लिए एक PHP एक्सटेंशन स्थापित करने की आवश्यकता है!


0

तुम सही हो।

दुर्भाग्य से कोई जादू नहीं है: आपको उन्हें परीक्षण करना होगा, यह देखने के लिए कोड की जांच करनी चाहिए कि क्या यह अच्छी तरह से विकसित है, अपने मंच के लिए वाणिज्यिक मॉड्यूल के लिए एक अच्छा समर्थन है या आपके सवालों के जवाब देने के लिए क्रूरता ...

Magento Connect पर कुछ समीक्षाएं हैं और एक एक्सटेंशन की लोकप्रियता यह जानने में मदद कर सकती है कि यह मूल्यवान है या नहीं लेकिन ईमानदारी से आप बहुत सारे बग के साथ बहुत लोकप्रिय मॉड्यूल पा सकते हैं। मेरे पास पिछले हफ्ते एक MailChimp मॉड्यूल के साथ एक अच्छा उदाहरण था, मुख्य रूप से अच्छी तरह से किया गया था, लेकिन मुझे कुछ बग्स को ठीक करना था और उन्हें डेवलपर को प्रदान करना था। हमेशा जोखिम होते हैं, आपको परीक्षण करना होगा।

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


0

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


0

# 1 परीक्षण जो मैं कर सकता हूं, उनके कोड में एक शून्य-दिवसीय कारनामे का पता लगाना है (आमतौर पर मैगेंटो एक्सटेंशन के साथ बहुत मुश्किल नहीं है), केवल उनकी सुरक्षा टीम को एक नकली शोषण के परिणामस्वरूप नुकसान की रिपोर्ट करें (जिसमें कोई संकेत नहीं दिया गया है कोड का हिस्सा कमजोर है), और स्टॉप-वॉच शुरू करें - क्योंकि आपकी साइट हैक होने पर ठीक यही होने वाला है। जब उनके सहायक कर्मचारी वैश्विक एफ़टीपी और mysql का उपयोग करने के लिए कहते हैं, तो यह बताते हुए विनम्रता से कि यह PCI-DSS का उल्लंघन है और उन्हें आपके स्रोत कोड रिपॉजिटरी में केवल पढ़ने के लिए पहुँच प्रदान करने की पेशकश करता है।

# 2 परीक्षण जो मैं करता हूं, वह विक्रेता को कॉल करना और उन्हें गार्ड से पकड़ना है। उनसे पूछें कि वे किस तरह का व्यवहार / यूनिट परीक्षण करते हैं, वे किस स्रोत-नियंत्रण प्रणाली का उपयोग करते हैं, वे PHP के किन संस्करणों का परीक्षण करते हैं, मैगेंटो के कौन से संस्करणों का परीक्षण किया जाता है, कौन से वेब-सर्वरों का परीक्षण किया जाता है, वे ब्राउज़र का उपयोग करते हैं या नहीं फ्रंट-एंड घटकों के परीक्षण के लिए -स्टैक, आदि ... यदि विक्रेता को पता नहीं है कि आप किस बारे में बात कर रहे हैं, तो चुप हो जाता है या "आपको वापस ईमेल करने के लिए एक विशेषज्ञ प्राप्त करना चाहता है", नरक की तरह चलाएं क्योंकि वे सबसे अधिक संभावना नंबर का उपयोग करते हैं। "संस्करण नियंत्रण" के लिए ज़िप फाइल करें और अपने ग्राहकों द्वारा रिपोर्ट किए जाने के 3 महीने बाद ही उन्हें ठीक करें।

PCI-DSS की बात करें तो, सभी सिस्टम संशोधनों के लिए एक प्रत्यावर्तन रणनीति की आवश्यकता होती है। उन मॉड्यूल के साथ जो गैर-अशक्त स्तंभों को कोर तालिकाओं में जोड़ते हैं, यह अब भी असंभव हो जाता है, जबकि अभी भी एक प्रत्यावर्तन रणनीति को बनाए रखना होगा जो एक ऑडिट को पारित करेगा। किसी भी मॉड्यूल से नरक की तरह चलाएं जो अक्षम होने पर समस्याएँ पैदा करेगा (पढ़ें: SQL त्रुटियां)।

PCI-DSS v3

6.4.5.4 बैक-आउट प्रक्रियाएँ।

सत्यापित करें कि प्रत्येक नमूना परिवर्तन के लिए बैक-आउट प्रक्रिया तैयार की जाती है।

प्रत्येक परिवर्तन के लिए, परिवर्तन विफल होने या किसी एप्लिकेशन या सिस्टम की सुरक्षा को प्रतिकूल रूप से प्रभावित करने की स्थिति में, बैकस्ट प्रक्रियाओं का दस्तावेजीकरण किया जाना चाहिए, ताकि सिस्टम को अपनी पिछली स्थिति में वापस लाया जा सके।

यह, अन्य उत्तरों के अलावा। IMO में कुछ खतरनाक बकवास के लिए शर्म की दीवार होनी चाहिए जो इस मंच पर पैदा की गई है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.