🎾 👏🏻 🌽 हम किसी विशिष्ट ग्राहक के लिए उत्पाद को कैसे संशोधित करते हैं 📷 🏭 🦅

इसलिए, हमने ग्राहक को एक बी 2 बी सॉफ्टवेयर उत्पाद बेचा।

प्रस्तुति में, उन्होंने सब कुछ पसंद किया, लेकिन कार्यान्वयन के दौरान यह पता चला कि कुछ अभी भी फिट नहीं था। आप निश्चित रूप से कह सकते हैं कि आपको "सर्वोत्तम अभ्यास" का पालन करने की आवश्यकता है, और अपने आप को एक उत्पाद में बदलना है, न कि इसके विपरीत। यह काम कर सकता है यदि आपके पास एक मजबूत ब्रांड है (उदाहरण के लिए, तीन बड़े अक्षर, और आप सभी तीन छोटे अक्षर भेज सकते हैं)। अन्यथा, वे आपको जल्दी से समझाएंगे कि ग्राहक ने अपनी अनूठी व्यावसायिक प्रक्रियाओं के लिए सब कुछ प्राप्त किया, और चलो अपने उत्पाद को बेहतर ढंग से बदलें या यह काम नहीं करेगा। इस तथ्य से इनकार करने और संदर्भित करने का एक विकल्प है कि लाइसेंस पहले ही खरीदे जा चुके हैं, और पनडुब्बी से कहीं नहीं जाना है। लेकिन अपेक्षाकृत संकीर्ण बाजारों में, ऐसी रणनीति लंबे समय तक काम नहीं करेगी।

हमें संशोधित करना होगा।

दृष्टिकोण

उत्पाद अनुकूलन के लिए कई बुनियादी दृष्टिकोण हैं।

केवल पत्थर का खंभा

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

प्रतिलिपि

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

विलयन

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

प्रतिरूपकता

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

विवरण

उदाहरण के साथ आगे मैं दिखाऊंगा कि कैसे हम खुले और मुक्त lsFusion मंच के आधार पर विकसित उत्पादों का विस्तार करते हैं।

सिस्टम का एक प्रमुख तत्व मॉड्यूल है। एक मॉड्यूल एक पाठ फ़ाइल है जिसमें lsf एक्सटेंशन होता है, जिसमें lsFusion कोड होता है । प्रत्येक मॉड्यूल में, दोनों डोमेन लॉजिक (फ़ंक्शंस, क्लासेस, एक्शन) और प्रेजेंटेशन लॉजिक (फॉर्म, नेविगेटर) घोषित किए जाते हैं। मॉड्यूल, एक नियम के रूप में, एक तार्किक सिद्धांत द्वारा विभाजित निर्देशिकाओं में स्थित हैं। एक उत्पाद मॉड्यूल का एक संग्रह है जो इसकी कार्यक्षमता को लागू करता है और एक अलग भंडार में संग्रहीत होता है।

मॉड्यूल अन्योन्याश्रित हैं। एक मॉड्यूल दूसरे पर निर्भर करता है यदि वह अपने तर्क का उपयोग करता है (उदाहरण के लिए, गुणों या रूपों को संदर्भित करता है)।

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

व्यवहार में आने वाले सुधारों के कई मुख्य मामलों पर विचार करें:

मान लें कि हमारे पास उत्पाद में एक ऑर्डर मॉड्यूल है, जो मानक आदेश तर्क का वर्णन करता है:

आदेश मॉड्यूल

MODULE Order;

CLASS Book '' ;
name '' = DATA ISTRING [ 100 ] (Book) IN id;

CLASS Order '' ;
date '' = DATA DATE (Order) IN id;
number '' = DATA STRING [ 10 ] (Order) IN id;

CLASS OrderDetail ' ' ;
order '' = DATA Order (OrderDetail) NONULL DELETE ;

book '' = DATA Book (OrderDetail) NONULL ;
nameBook '' (OrderDetail d) = name(book(d));

quantity '' = DATA INTEGER (OrderDetail);
price '' = DATA NUMERIC [ 14 , 2 ] (OrderDetail);
sum '' (OrderDetail d) = quantity(d) * price(d);

FORM order ''
OBJECTS o = Order PANEL
PROPERTIES (o) date, number

OBJECTS d = OrderDetail
PROPERTIES (d) nameBook, quantity, price, NEW , DELETE
FILTERS order(d) = o

EDIT Order OBJECT o
;

FORM orders ''
OBJECTS o = Order
PROPERTIES (o) READONLY date, number
PROPERTIES (o) NEWSESSION NEW , EDIT , DELETE
;

NAVIGATOR {
NEW orders;
}

ग्राहक एक्स ऑर्डर लाइन के लिए छूट प्रतिशत और छूट मूल्य जोड़ना चाहता है।
सबसे पहले, ग्राहक के भंडार में एक नया ऑर्डरएक्स मॉड्यूल बनाया जाता है। इसके शीर्षलेख में, मूल आदेश मॉड्यूल पर एक निर्भरता रखी गई है:

REQUIRE Order;

इस मॉड्यूल में, हम नए गुणों की घोषणा करते हैं जिसके तहत तालिकाओं में अतिरिक्त क्षेत्र बनाए जाएंगे, और उन्हें फॉर्म में जोड़ें:

discount ', %' = DATA NUMERIC [ 5 , 2 ] (OrderDetail);
discountPrice ' ' = DATA NUMERIC [ 14 , 2 ] (OrderDetail);

EXTEND FORM order
PROPERTIES (d) AFTER price(d) discount, discountPrice READONLY
;

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

WHEN LOCAL CHANGED (price(OrderDetail d)) OR CHANGED (discount(d)) DO
discountPrice(d) <- price(d) * ( 100 (-) discount(d)) / 100 ;

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

sum '' = ABSTRACT CASE NUMERIC [ 16 , 2 ] (OrderDetail);
sum (OrderDetail d) += WHEN price(d) THEN quantity(d) * price(d);

इस मामले में, संपत्ति का मूल्य एक मामले में एकत्र किया जाएगा, जहां WHEN को अलग-अलग मॉड्यूल में बिखेर दिया जा सकता है। यह गारंटी दी जाती है कि यदि मॉड्यूल A मॉड्यूल B पर निर्भर करता है, तो मॉड्यूल B के सभी WHEN बाद में मॉड्यूल A के WHEN की तुलना में काम करेंगे। रियायती राशि की सही गणना करने के लिए, निम्नलिखित घोषणा को ऑर्डरएक्स मॉड्यूल में जोड़ा जाता है:

sum(OrderDetail d) += WHEN discount(d) THEN quantity(d) * discountPrice(d);

नतीजतन, यदि कोई छूट निर्धारित है, तो राशि इसके अधीन होगी, अन्यथा मूल अभिव्यक्ति।

मान लीजिए कि एक ग्राहक एक प्रतिबंध जोड़ना चाहता है कि आदेश राशि एक निश्चित निर्दिष्ट राशि से अधिक नहीं होनी चाहिए। समान ऑर्डरएक्स मॉड्यूल में, हम एक संपत्ति घोषित करते हैं जिसमें बाधा मूल्य संग्रहीत किया जाएगा, और इसे मानक विकल्प फॉर्म में जोड़ें (यदि आप चाहें तो सेटिंग्स के साथ एक अलग रूप बना सकते हैं):

orderLimit ' ' = DATA NUMERIC [ 16 , 2 ] ();
EXTEND FORM options
PROPERTIES () orderLimit
;

फिर, उसी मॉड्यूल में, हम ऑर्डर की राशि की घोषणा करते हैं, इसे फॉर्म पर दिखाते हैं और इसकी अतिरिक्त सीमा को जोड़ते हैं:

sum '' (Order o) = GROUP SUM sum(OrderDetail d) IF order(d) = o;
EXTEND FORM order
PROPERTIES (o) sum
;
CONSTRAINT sum(Order o) > orderLimit() MESSAGE ' ' ;

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

DESIGN order {
OBJECTS {
NEW pane {
fill = 1 ;
type = SPLITH ;
MOVE BOX (o);
MOVE BOX (d) {
PROPERTY (price(d)) { pattern = '#,##0.00' ; }
PROPERTY (discountPrice(d)) { pattern = '#,##0.00' ; }
}
}
}
}

नतीजतन, हमें दो ऑर्डर मॉड्यूल (उत्पाद में) मिलते हैं , जिसमें ऑर्डर के मूल तर्क को लागू किया जाता है, और ऑर्डरएक्स (ग्राहक पर), जिसमें आवश्यक छूट तर्क को लागू किया जाता है:

क्रम

MODULE Order;

CLASS Book '' ;
name '' = DATA ISTRING [ 100 ] (Book) IN id;

CLASS Order '' ;
date '' = DATA DATE (Order) IN id;
number '' = DATA STRING [ 10 ] (Order) IN id;

CLASS OrderDetail ' ' ;
order '' = DATA Order (OrderDetail) NONULL DELETE ;

book '' = DATA Book (OrderDetail) NONULL ;
nameBook '' (OrderDetail d) = name(book(d));

quantity '' = DATA INTEGER (OrderDetail);
price '' = DATA NUMERIC [ 14 , 2 ] (OrderDetail);
sum '' = ABSTRACT CASE NUMERIC [ 16 , 2 ] (OrderDetail);
sum (OrderDetail d) += WHEN price(d) THEN quantity(d) * price(d);

FORM order ''
OBJECTS o = Order PANEL
PROPERTIES (o) date, number

OBJECTS d = OrderDetail
PROPERTIES (d) nameBook, quantity, price, NEW , DELETE
FILTERS order(d) = o

EDIT Order OBJECT o
;

FORM orders ''
OBJECTS o = Order
PROPERTIES (o) READONLY date, number
PROPERTIES (o) NEWSESSION NEW , EDIT , DELETE
;

NAVIGATOR {
NEW orders;
}

OrderX

MODULE OrderX;

REQUIRE Order;

discount ', %' = DATA NUMERIC [ 5 , 2 ] (OrderDetail);
discountPrice ' ' = DATA NUMERIC [ 14 , 2 ] (OrderDetail);

EXTEND FORM order
PROPERTIES (d) AFTER price(d) discount, discountPrice READONLY
;

WHEN LOCAL CHANGED (price(OrderDetail d)) OR CHANGED (discount(d)) DO
discountPrice(d) <- price(d) * ( 100 (-) discount(d)) / 100 ;

sum(OrderDetail d) += WHEN discount(d) THEN quantity(d) * discountPrice(d);

orderLimit ' ' = DATA NUMERIC [ 16 , 2 ] ();
EXTEND FORM options
PROPERTIES () orderLimit
;

sum '' (Order o) = GROUP SUM sum(OrderDetail d) IF order(d) = o;
EXTEND FORM order
PROPERTIES (o) sum
;
CONSTRAINT sum(Order o) > orderLimit() MESSAGE ' ' ;

DESIGN order {
OBJECTS {
NEW pane {
fill = 1 ;
type = SPLITH ;
MOVE BOX (o);
MOVE BOX (d) {
PROPERTY (price(d)) { pattern = '#,##0.00' ; }
PROPERTY (discountPrice(d)) { pattern = '#,##0.00' ; }
}
}
}
}

यह ध्यान दिया जाना चाहिए कि ऑर्डरएक्स मॉड्यूल को ऑर्डरडिसकाउंट कहा जा सकता है और सीधे उत्पाद में स्थानांतरित किया जा सकता है। फिर, यदि आवश्यक हो, तो प्रत्येक ग्राहक को आसानी से छूट के साथ कार्यक्षमता को जोड़ना संभव होगा।

यह उन सभी संभावनाओं से दूर है जो प्लेटफ़ॉर्म व्यक्तिगत मॉड्यूल में कार्यक्षमता का विस्तार करने के लिए प्रदान करता है। उदाहरण के लिए, वंशानुक्रम का उपयोग करके, आप रजिस्टर लॉजिक को मॉड्यूलर रूप से लागू कर सकते हैं।

यदि उत्पाद के स्रोत कोड में कोई परिवर्तन होता है जो कि निर्भर मॉड्यूल में कोड के विपरीत होता है, तो सर्वर शुरू होने पर एक त्रुटि उत्पन्न होगी। उदाहरण के लिए, यदि ऑर्डर फॉर्म को ऑर्डर मॉड्यूल में हटा दिया जाता है , तो स्टार्टअप पर एक त्रुटि होगी कि ऑर्डर फॉर्म को ऑर्डरएक्स मॉड्यूल में नहीं मिला है। साथ ही, आईडीई में त्रुटि को उजागर किया जाएगा। इसके अलावा, आईडीई के पास परियोजना में सभी त्रुटियों की खोज करने के लिए एक फ़ंक्शन है, जो आपको उत्पाद संस्करण को अपडेट करने के कारण होने वाली सभी समस्याओं की पहचान करने की अनुमति देता है।

व्यवहार में, हमारे पास एक ही परियोजना से जुड़े सभी रिपॉजिटरी (उत्पाद और सभी ग्राहक) हैं, इसलिए हम ग्राहक मॉड्यूल में तर्क को बदलते हुए, उत्पाद को शांत रूप से रिफ्लेक्टर करते हैं जहां इसका उपयोग किया जाता है।

निष्कर्ष

इस तरह के माइक्रोमॉड्यूलर आर्किटेक्चर निम्नलिखित लाभ प्रदान करते हैं:

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

प्रोग्रामिंग में एक्सटेंशन की मदद से ऊपर वर्णित मॉड्यूलरिटी स्कीम को अक्सर मिक्स इन कहा जाता है । उदाहरण के लिए, माइक्रोसॉफ्ट डायनेमिक्स ने हाल ही में विस्तार की अवधारणा पेश की, जो आपको आधार मॉड्यूल का विस्तार करने की भी अनुमति देता है। हालांकि, वहां निचले स्तर की प्रोग्रामिंग की आवश्यकता होती है, जिसके लिए डेवलपर्स की उच्च योग्यता की आवश्यकता होती है। इसके अलावा, lsFusion के विपरीत, घटनाओं और प्रतिबंधों के विस्तार का लाभ उठाने के लिए उत्पाद में प्रारंभिक "प्रवेश बिंदु" की आवश्यकता होती है।

फिलहाल, ऊपर वर्णित योजना के अनुसार, हम 30 से अधिक अपेक्षाकृत बड़े ग्राहकों के साथ रिटेलिंग के लिए ईआरपी सिस्टम का समर्थन और कार्यान्वयन करते हैं, जिसमें 1000 से अधिक मॉड्यूल शामिल हैं। ग्राहकों में FMCG नेटवर्क, साथ ही साथ फ़ार्मेसीज़, क्लोथिंग स्टोर्स, ड्रगी चेन स्टोर्स, होलसेलर्स और अन्य शामिल हैं। उत्पाद में क्रमशः मॉड्यूल की अलग-अलग श्रेणियां होती हैं जो उद्योग और उपयोग की जाने वाली व्यावसायिक प्रक्रियाओं के आधार पर जुड़ी होती हैं।

हम किसी विशिष्ट ग्राहक के लिए उत्पाद को कैसे संशोधित करते हैं