👵🏼 ⛰️ 👨🏿‍🔬 कंपनी में विकास को आगे बढ़ाना: यह क्या है और इसे कैसे प्रभावी बनाया जाए 🙅🏽 ☔️ 👨‍👧

हम KORUS परामर्श CIS में दस वर्षों से अधिक समय से अपने ग्राहकों के लिए वेब सेवाओं के विकास का आयोजन कर रहे हैं। हमारे पास पहले से ही बैंकिंग क्षेत्र में कई दर्जन गंभीर परियोजनाएं हैं, जिनमें से कुछ को अंतरराष्ट्रीय मान्यता प्राप्त है।

पिछले दो वर्षों में, हमारी कंपनी में टीमों और परियोजनाओं की संख्या में कई गुना वृद्धि हुई है, जबकि सीमावर्ती विकास की प्रभावशीलता भी कई बार बढ़ी है। हमने सीखा कि कुछ महीनों के बजाय कुछ हफ्तों में आवेदन कैसे बनाएं।

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

इस लेख में, आप निम्नलिखित प्रश्नों के उत्तर देने के हमारे मार्ग के बारे में जानेंगे:

, ;
, ;
;
;
;
.

साइट या एप्लिकेशन का दृश्य भाग वह है जो आप अपने ब्राउज़र में देखते हैं, यह भाग सक्रिय रूप से सर्वर (बैकएंड) भाग के साथ सहभागिता करता है, जो किसी भी सर्वर पर स्थित है, इसके साथ लगातार डेटा का आदान-प्रदान होता है।

तकनीकी दृष्टिकोण से, एप्लिकेशन का फ्रंट-एंड फाइलों का एक समूह है, जिसमें HTML, CSS और JavaScript फाइलें, चित्र आदि हैं। CSS और HTML के साथ कार्य टाइपिंग, जावास्क्रिप्ट - प्रोग्रामिंग से संबंधित है। ये दोनों क्षेत्र काम के लिए बड़ी संख्या में उपकरण और प्रौद्योगिकियां प्रदान करते हैं, सक्रिय रूप से विकसित हो रहे हैं और बहुत अधिक ज्ञान की आवश्यकता है। यह जावास्क्रिप्ट के लिए विशेष रूप से सच है, जिसने वेब अनुप्रयोगों के "अधिक से अधिक कुशल" निर्माण के लिए बड़ी संख्या में चौखटे और पुस्तकालय लिखे हैं।

किसी तरह मुझसे पूछा गया कि अब मुझे क्या आवेदन करने की आवश्यकता है ताकि वे कई और वर्षों तक अप्रचलित न हों?

एक प्रोग्रामर के रूप में, मैं पूरी तरह से सटीक और पूरी तरह से बेकार जवाब दे सकता हूं: एचटीएमएल, सीएसएस और जावास्क्रिप्ट। वास्तव में क्या चुनना है, jQuery, कोणीय या प्रतिक्रिया - ये विवरण हैं।

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

अंतर क्या है?

उत्तर खोजने के लिए, आइए देखें कि सामने के छोर से व्यवसाय क्या चाहता है। मुझे लगता है कि मैं किसी को आश्चर्यचकित नहीं करूंगा यदि मैं कहता हूं कि व्यवसाय जल्दी और सस्ते में उच्च गुणवत्ता वाला परिणाम प्राप्त करना चाहता है।

तो, आपको अब क्या करने की आवश्यकता है, ताकि विकास जल्दी से, कुशलता से हो और ग्राहक को बर्बाद न करें?

विकास की गति

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

एक विशेष ढांचे का उपयोग करते हुए विकास की गति प्रोग्रामर्स के अनुभव और योग्यता पर निर्भर करती है जो उस पर लिखते हैं, रूपरेखा स्वयं माध्यमिक महत्व की है।

उत्पाद की गुणवत्ता

यहाँ भी ऐसा ही है: यह अच्छा और बुरा है जिसे आप किसी भी ढांचे पर लिख सकते हैं। आप कहीं भी सही और गलत आर्किटेक्चर बिछा सकते हैं।

यह सब डेवलपर के अनुभव और ज्ञान पर निर्भर करता है।

लागत

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

इसलिए निष्कर्ष: आपको प्रौद्योगिकी पर इतना भरोसा नहीं करना चाहिए जितना कि डेवलपर्स और उनके काम के संगठन पर।

लगभग किसी भी आधुनिक लोकप्रिय फ्रेमवर्क को बनाने के लिए काफी अच्छा है लगभग किसी भी एप्लिकेशन को जिसे आधुनिक व्यवसाय की आवश्यकता हो सकती है।

इसलिए, यह विकास के संगठन के संदर्भ में आगे के छोर की प्रभावशीलता के बारे में होगा।

हमारे साथ कैसा रहा?

2017 तक, हमारे पास जावास्क्रिप्ट दुनिया में लगभग हर चीज पर ध्यान देने योग्य अनुप्रयोग थे: jQuery से, विभिन्न प्रकार के एंगुलर और रिएक्ट पर टाइपस्क्रिप्ट और फ्लो। लेआउट और बैकएंड / फुलस्टैक डेवलपर्स ने हमारे अनुप्रयोगों के क्लाइंट पक्ष पर काम किया। प्रत्येक डेवलपर ने अपने कार्यों के लिए टूल चुना, जो कि फ्रंट-एंड प्रौद्योगिकियों के उनके ज्ञान पर निर्भर करता है।

अब मैं केवल अनुमान लगा सकता हूं, लेकिन यह मुझे लगता है कि फुलस्टैक / बैकएंड डेवलपर्स द्वारा चौखटे और पुस्तकालयों की पसंद कुछ इस तरह थी:

"चलो देखते हैं कि वे इंटरनेट पर क्या लिखते हैं ..."

ठीक है, आप समझते हैं।

जब कोई ढांचा / पुस्तकालय चुनते हैं, तो डेवलपर समय में सीमित होता है, सबसे अधिक बार उसके पास स्वतंत्र रूप से उसके लिए नए ढांचे को तैनात करने और परीक्षण एप्लिकेशन बनाने का समय नहीं होता है। इसलिए, वह किसी भी तरह कम या ज्यादा सुविचारित चुनाव करता है और फिर चुनी हुई दिशा में चलता है।

समय में विभिन्न बिंदुओं पर, यह विकल्प एक ही डेवलपर के लिए भी अलग हो सकता है (ऊपर चित्र देखें)। उसी समय, वह कम तर्कपूर्ण नहीं बन जाता है। फिर अलग-अलग अनुभवों वाले विभिन्न डेवलपर्स से क्या उम्मीद की जाए?

2017 तक अनजाने में, हम एक वास्तविक फ्रंट-एंड टेक्नोलॉजी चिड़ियाघर में बदल गए।

एक अलग इकाई के रूप में सामने

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

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

2017 में, हमारी कंपनी में एक फ्रंट-एंड डिवीजन दिखाई दिया, जो हमारी परियोजनाओं के फ्रंट-एंड हिस्से की गुणवत्ता और उनकी मात्रा के साथ-साथ प्रौद्योगिकियों की विविधता को स्थिर करने और विकास दक्षता को बढ़ाने के प्रयास पर बढ़ती मांगों के लिए एक प्रतिक्रिया थी।

यह हमारी कंपनी के विकास के लिए एक महत्वपूर्ण चरण था: अब हम क्या कर रहे हैं, यह सामने के अंत में विशेषज्ञता के बिना डेवलपर्स की मदद से करना असंभव होगा।

चिड़ियाघर को कैसे ठीक किया जाए?

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

इसलिए, हमारा अगला कदम नए डिवीजन के विशेषज्ञों की मदद से कंपनी के ढेर को एकजुट करना था।

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

एक एकल स्टैक डेवलपर को एक परियोजना से दूसरे में जल्दी से स्विच करने, क्रॉस-टीम समीक्षा आयोजित करने और सहकर्मियों के साथ अनुभव और सर्वोत्तम प्रथाओं को प्रभावी ढंग से साझा करने की क्षमता देता है।

यहां मुख्य कार्य यह तय करना नहीं है कि हम रिएक्ट या एंगुलर पर क्या लिख रहे हैं, बल्कि यह सुनिश्चित करने के लिए कि डेवलपर्स एप्लिकेशन बनाने के लिए समान टूल का उपयोग करें और समान समस्याओं को हल करने के लिए समान दृष्टिकोण का उपयोग करें।

संदर्भ के लिए: हमारा मुख्य उपकरण रिएक्ट है, लेकिन हम एंगुलर में विशेषज्ञता भी विकसित कर रहे हैं।

मज़ा यहां शुरू होता है। प्रोग्रामिंग की दुनिया में मजबूर बहुत खराब तरीके से काम करता है।

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

ऐसा करने के लिए, आपको चाहिए:

किसी तरह तय करना, विकास की आवश्यकताओं को औपचारिक बनाना;
डेवलपर्स को इन दिशानिर्देशों का पालन करने के लिए प्रोत्साहित करें।

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

हमने प्रेरणा मुद्दे को निम्नानुसार हल किया: डेवलपर को अर्ध-तैयार एप्लिकेशन (टेम्पलेट) देने के लिए किसी भी प्रलेखन से बेहतर है।

यह डेवलपर्स को तेज़ी से कार्यों को हल करने और अपनी उत्पादकता के साथ सहयोगियों को प्रभावित करने की अनुमति देता है और साथ ही उन्हें उन बुनियादी नियमों का पालन करने के लिए प्रोत्साहित करता है जो पहले से ही कोड में संरक्षित हैं।

एक तरफ, अंत में इसी तरह के अनुप्रयोग अनुभव के संचय, तैयार समाधान, एक गहरी समीक्षा और परियोजना से परियोजना पर स्विच करने की क्षमता के कारण विकास की गति में महत्वपूर्ण वृद्धि देते हैं। दूसरी ओर, प्रत्येक परियोजना की अपनी ख़ासियतें होती हैं, इसलिए यह भी महत्वपूर्ण है कि मानकीकरण के साथ इसे ज़्यादा न करें।

आपको एप्लिकेशन टेम्प्लेट में क्या रखना है

नई परियोजनाएं शुरू करते समय, डेवलपर्स आमतौर पर निम्नलिखित विशिष्ट कार्यों को हल करते हैं:

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

आपके कौन से कार्य आपके डेवलपर कुछ मिनटों में हल कर सकते हैं?

हमारे द्वारा विकसित किया गया एप्लिकेशन टेम्प्लेट इस सूची से पहले तीन आइटम बंद कर देता है। इस टेम्पलेट में, हमने न केवल विकास के लिए एक ढेर के लिए अपनी इच्छाओं को व्यक्त किया, बल्कि एप्लिकेशन आर्किटेक्चर के बुनियादी नियम भी।
उन लोकप्रिय समाधानों की तुलना में जो सार्वजनिक डोमेन में हैं (उदाहरण के लिए, create-react-app), हमारे टेम्पलेट में पहले से ही शामिल हैं:

तैयार फ़ोल्डर संरचना;
कॉन्फ़िगर राउटर (मार्गों);
कॉन्फ़िगर किया गया Redux संग्रहण
सर्वर अनुरोध मॉड्यूल;
रेडक्स के माध्यम से विभिन्न प्रकार के लोडर, सूचनाएं और मोडल विंडो प्रदर्शित करने के लिए तैयार तंत्र;
उपयोगकर्ता को संदेशों के उत्पादन के साथ त्रुटि प्रसंस्करण मॉड्यूल (सर्वर और उपयोगकर्ता);
टेम्पलेट पेज;

व्यापार तर्क टेम्पलेट मॉड्यूल जिसमें त्रुटि, लोडर, और सूचना हैंडलर जुड़े हुए हैं।

संक्षेप में, यह एक पृष्ठ के साथ एक उत्पादन-तैयार अनुप्रयोग है जो हैलो दुनिया कहता है। सुबह की कॉफी के साथ, दोपहर के भोजन से शुरू करके, डेवलपर एक कार्यशील परियोजना का पहला पृष्ठ दिखा सकता है।

लेकिन फिर अन्य दिलचस्प (और ऐसा नहीं) कार्यों की एक बड़ी संख्या डेवलपर का इंतजार करती है।

घटक पुस्तकालय चयन

सब कुछ जो लेआउट, इंटरफ़ेस घटकों (ड्रॉप-डाउन सूची, कैलेंडर, आदि), रूपों और सत्यापन की चिंता करता है, हमने अपने पुस्तकालय का उपयोग करने का फैसला किया। यह सबसे कठिन हिस्सा था।

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

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

;
;
.

( , , );
;
, . ;
, . .

;
;
.

;
, / ( ..);
( , , , ).

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

यह पता चला है कि आपको सीमाओं के एक समूह के साथ तुरंत तैयार कार्यक्षमता स्थापित करने और विकास पर अतिरिक्त संसाधनों को प्रतीक्षा करने और खर्च करने की आवश्यकता के साथ अपने स्वयं के समाधान विकसित करने के बीच चुनना होगा।

विकल्पों में से कोई भी पूरी तरह से हमारे अनुकूल नहीं है, और हमें एक और समाधान मिला।

हमने तैयार लाइब्रेरी के लिए अपना ऐड बनाने का फैसला किया।

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

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

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

हमने अपनी उपलब्धियों को सार्वजनिक डोमेन में रखने का फैसला किया, जल्द ही उन्हें डाउनलोड किया जा सकता है और हमारी परियोजनाओं में उपयोग किया जा सकता है, घोषणाओं का पालन करें।

आखिर में हमें क्या मिला?

अब हमारे पास 10 से अधिक फ्रंट-एंड डेवलपर्स हैं, जो एक ही स्टैक पर और कई तकनीकों के साथ काम कर रहे हैं। एक स्टैक पर, हमने पहले ही लगभग बीस प्रोजेक्ट बनाए हैं।

आंकड़े बताते हैं कि कार्य कुशलता दो वर्षों में तीन गुना से अधिक हो गई है। जिन परियोजनाओं पर हम 4-6 महीने खर्च करते थे, अब हम 1-2 महीने में करते हैं (हम फ्रंट-एंड भाग के बारे में बात कर रहे हैं)।

हमने प्रोग्रामर के कार्यों की संरचना को बदलकर विकास के समय को कम करना शुरू कर दिया। आइए देखें कि वे कैसे बदल गए हैं।

मैंने पहले ही उन कार्यों की एक सूची दी थी जो डेवलपर्स ने दो साल पहले हल किए थे:

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

इनमें से, हमारी कंपनी में आज, डेवलपर्स केवल पिछले तीन में लगे हुए हैं:

एक ग्राहक (व्यावसायिक तर्क) के आदेश द्वारा कार्यक्षमता का कार्यान्वयन;
को़ड समीक्षा;
परियोजना प्रलेखन बनाए रखना।

बाकी आवेदन टेम्पलेट और घटक पुस्तकालय में पहले से ही तय है।

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

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

दक्षता के लिए इच्छाओं के साथ और जल्द ही मिलते हैं!

कंपनी में विकास को आगे बढ़ाना: यह क्या है और इसे कैसे प्रभावी बनाया जाए