निम्न-कोड प्लेटफ़ॉर्म: एक रामबाण या जोखिम भरा दांव?

कम-कोड प्लेटफ़ॉर्म (लो कोड एप्लिकेशन प्लेटफ़ॉर्म, LCAP) आधुनिक सॉफ़्टवेयर डेवलपमेंट टूल्स की जटिलता और विविधता की प्रतिक्रिया के रूप में उत्पन्न हुआ।

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

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

यही है, डेवलपर्स की अब जरूरत नहीं है?

खैर ... कुछ वर्षों के बाद, मेंडिक्स स्वीकार करने के लिए मजबूर है:

"अब डेवलपर्स को पहले से कहीं ज्यादा जरूरत है।"

यह एक ट्विस्ट है!

ऐसा लगता है कि मेंडिक्स ने पहचान लिया कि डेटा के साथ बुनियादी काम की तुलना में अधिक कठिन कुछ के लिए, एक पेशेवर डेवलपर की आवश्यकता है, ठीक उसी तरह जैसे कि एक कार की सेवा के लिए एक पेशेवर मैकेनिक की आवश्यकता होती है।

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

महान प्रोटोटाइप उपकरण

विश्लेषकों या उन्नत उपयोगकर्ताओं के लिए उपलब्ध सरल प्रक्रियाओं या प्रोटोटाइप को स्वचालित करने के लिए मेंडिक्स एक बहुत अच्छा विकल्प है।

दृश्य संपादक आपको डेटा मॉडल का वर्णन करने की अनुमति देता है, जल्दी से विजेट और टेम्पलेट्स के सेट का उपयोग करके स्क्रीन बनाते हैं, और यहां तक ​​कि तथाकथित माइक्रोफ़्लो का उपयोग करके तर्क का वर्णन करते हैं:

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

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

विकास धीमा

किसी भी तर्क - यह कंप्यूटिंग या उपयोगकर्ता बातचीत हो - एक माइक्रोफ्लो फ्लोचार्ट में वर्णित किया जाना चाहिए, जैसा कि ऊपर दिखाया गया है।

यहां कई मुद्दे हैं।

सबसे पहले, यह एक लंबा समय है । जाहिर है, ड्रैग और ड्रॉप की तुलना में एक अच्छे IDE में कोड की 10 पंक्तियां लिखना और दर्जनों ब्लॉक्स को कस्टमाइज़ करना और तेज करना है।

दूसरी बात, पठनीयता । ब्लॉक सुंदर दिखते हैं, लेकिन इस Sub_RegistrationValidation का क्या अर्थ है ? ब्लॉक में गिरने के बिना इसे समझना असंभव है। जैसे ही ब्लॉकों की संख्या कई दसियों तक बढ़ जाती है, तर्क को समझना बेहद मुश्किल हो जाएगा।

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

आखिरी चीज जिसका मैं उल्लेख करना चाहता था वह था संस्करण नियंत्रण।

अच्छी खबर यह है कि वह है। बुरी बात यह है कि यह तोड़फोड़ का एक छीन लिया गया संस्करण है। गिट प्रवाह के बारे में भूल जाओ।

नियंत्रण की कमी

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

मेंडिक्स के साथ, आप इसके बारे में भूल सकते हैं। यह एक बंद वाणिज्यिक ढांचा है, और इसके अंदर क्या हो रहा है यह एक वास्तविक ब्लैक बॉक्स है। आपके लिए जो कुछ भी शेष है वह भुगतान किया गया समर्थन खरीदना है या किसी फोरम पर प्रति माह ~ 200 प्रश्नों के साथ मदद के लिए प्रतीक्षा करना है (स्टैकओवरफ़्लो पर #spring टैग के साथ तुलना करें!)।

विक्रेता निर्भरता

मेंडिक्स शायद बहुत बार इस बात का खंडन करता है। उन्होंने यह भी एक लेख प्रकाशित किया कि वास्तव में कोई लत नहीं है। यदि आप शब्द के बीच में पढ़ते हैं, तो यह पढ़ता है:

आप अपना डेटा, डीडीएल, यूआई संसाधन और कोड (माइक्रोफ़्लो जादुई रूप से जावा कोड में परिवर्तित) प्राप्त कर सकते हैं।

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

सीमित स्केलेबिलिटी

मेंडिक्स मार्केटिंग सबसे बड़ी कंपनियों पर केंद्रित है, इसलिए "स्केलेबिलिटी" शब्द मार्केटिंग सामग्रियों में लगातार चमकती है।

2017 में, मेंडिक्स ने स्टेटलेस रनटाइम की शुरुआत की - अर्थात, सभी सत्र की जानकारी या तो क्लाइंट की तरफ या लगातार स्टोरेज में संग्रहीत की जाती है।

सैद्धांतिक रूप से, इसका मतलब असीमित क्षैतिज मापनीयता है। यह बहुत अच्छा लगता है, लेकिन हमेशा की तरह एक अति सूक्ष्म अंतर है - डेटाबेस।

एक डेटाबेस लगभग हमेशा एक कॉर्पोरेट अनुप्रयोग में एक अड़चन बन जाता है। तो, कई मेंडिक्स स्टेटलेस सर्वर के पीछे डेटा स्टोर क्या करता है? कोई आश्चर्य नहीं - यह एक अच्छा पुराना संबंधपरक डेटाबेस है। क्लाउड मेंडिक्स में - पोस्टग्रेक्यूएल। इसके अलावा, उत्पन्न मेंडिक्स डीडीएल, इसे हल्के ढंग से रखने के लिए, पूरी तरह से इष्टतम नहीं है। उदाहरण के लिए, मैंने एक मध्यवर्ती तालिका देखी जो आमतौर पर N: M संबंधों को मॉडल करने के लिए उपयोग की जाती है, जिसे 1: N संबंध के लिए बनाया गया है।

स्केलेबिलिटी समस्या को मानक विधियों द्वारा हल किया जा सकता है: डेटाबेस संरचना, कैशिंग या यहां तक ​​कि साइटस जैसे समाधानों का उपयोग करके। लेकिन निश्चित रूप से ऐसी कोई संभावना नहीं है।

डेटाबेस को स्केल करने का एकमात्र तरीका रीड प्रतिकृति (उदाहरण के लिए, अमेज़ॅन आरडीएस) का उपयोग करके स्केल करना है। लेकिन रिकॉर्ड के लिए, यह काम नहीं करेगा।

पूर्वगामी को सारांशित करते हुए, मेंडिक्स की स्केलबिलिटी पर एक मौलिक सीमा है और प्रदर्शन को अनुकूलित करने का कोई साधन नहीं है।

HR प्रश्न

योग्य कर्मियों की तलाश हमेशा एक मुश्किल काम है। ऐसा लगता है कि इस मेंडिक्स में किसी भी प्रबंधक का सपना है, क्योंकि योग्यता की आवश्यकताओं में तेजी से कमी आई है।

वास्तव में, हमने पहले ही पता लगा लिया है कि अधिकांश परियोजनाओं को उपकरण की परवाह किए बिना एक पेशेवर टीम की आवश्यकता होती है। लेकिन यह संभावना नहीं है कि कोई भी स्वाभिमानी डेवलपर मेंडिक्स के साथ काम करने के लिए सहमत होगा, क्योंकि यह उसके करियर का एक स्पष्ट मृत अंत है।

कीमतों

अंतिम लेकिन कम से कम नहीं। एक आवेदन के लिए लाइसेंस की लागत 1875 डॉलर प्रति माह से शुरू होती है, जो तीन साल की सदस्यता के अधीन है, लाइसेंस 50 आंतरिक उपयोगकर्ताओं तक सीमित है।

स्थानीय तैनाती की संभावना के साथ एक कॉर्पोरेट लाइसेंस की कीमत $ 7,825 से शुरू होती है, जो एक वर्ष में लगभग $ 100,000 है।

कई सौ उपयोगकर्ताओं के साथ एक मध्यम आकार का उद्यम सालाना लाखों रूबल के बिलों का भुगतान करेगा।

यह मत भूलो कि हम अपेक्षाकृत सरल अनुप्रयोगों के बारे में बात कर रहे हैं, जैसा कि आप ऊपर से समझ सकते हैं। मेरे लिए, यह पागल है। यह मूल्य निर्धारण मॉडल वस्तुतः आपके द्वारा बनाए गए एप्लिकेशन को दोहराने में भी असंभव बनाता है।

फिर LCAP अभी भी लोकप्रिय क्यों हैं?

मेरी राय में, इसका कारण मौजूदा प्रक्रियाओं में निराशा है। एक बड़े संगठन में विकास टीम का प्रबंधन करना - चाहे वह आंतरिक टीम हो या आउटसोर्सिंग - बहुत जटिल है।

बजट की योजना, अंतहीन अनुमोदन, जिम्मेदारी लेने के लिए तैयार लोगों की कमी - मुझे लगता है कि यह बहुतों से परिचित है।

मजेदार बात यह है कि पहली बात यह है कि जब आईटी परियोजनाएं बहुत धीरे-धीरे आगे बढ़ रही हैं, तो यह और भी अधिक डेवलपर्स को किराए पर लेना है, और निश्चित रूप से, प्रबंधकों। कहने की जरूरत नहीं है, यह केवल स्थिति को खराब करता है। मुझे पता है कि 10,000 से अधिक (!!!) डेवलपर्स वाले कुछ बैंक हैं, और उनमें से कम से कम आधे बेकार काम कर रहे हैं।

हताशा में, व्यापार के नेता LCAP के रूप में ऐसी "जादू की छड़ी" में एक समाधान की तलाश कर रहे हैं, माना जाता है कि सभी समस्याओं को हल करने में सक्षम है।

इस दुष्चक्र से कैसे निकला जाए यह एक अलग लेख के लिए एक विषय है। लेकिन यह प्रबंधन का विषय है, तकनीक का नहीं।

विवरण में जाने के बिना, यदि आप पूरी तरह से परियोजना में शामिल 3-10 लोगों की एक छोटी सी योग्य टीम बनाने का प्रबंधन करते हैं, तो निर्णय निर्माता के सीधे संपर्क के साथ, आप अपनी अपेक्षा से अधिक तेजी से और सस्ता परिणाम प्राप्त करेंगे।

विकल्प क्या हैं?

अब डेवलपर्स के लिए टूल और फ्रेमवर्क का एक विशाल चयन है।

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

यदि आप परिणाम को तेज़ी से प्राप्त करना चाहते हैं, तो आपको RAD उपकरण जैसे CUBA प्लेटफ़ॉर्म पर विचार करना चाहिए।

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

अंतिम विकल्प कार्य पर निर्भर होना चाहिए, साथ ही टीम के कौशल और आपकी प्राथमिकताएं।

निष्कर्ष

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

चूंकि बहुत कम प्रोटोटाइप उपयोगकर्ता हैं, इसलिए इस स्तर पर लागत भी कम है। और यह इस समय रुकने लायक है!

एक पूर्ण प्रणाली विकसित करने के लिए LCAP का उपयोग करते समय, काम की गति अनिवार्य रूप से गिर जाएगी, और आप महंगे स्वामित्व वाले प्लेटफॉर्म पर निर्भर होंगे जो आपको सीमित करता है।