बदलती आवश्यकताओं और छोटी सुविधाओं के लाभों की दुनिया में जीवन के बारे में

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

इसलिए, हमारे पास सरकारी एजेंसियों के साथ एकीकृत करने के लिए केवल दो तरीके हैं: तब तक प्रतीक्षा करें जब तक सब कुछ बसता नहीं है और बाजार के नेतृत्व को याद नहीं करता है या बदलती आवश्यकताओं की दुनिया में एक प्रणाली विकसित करता है।

हमने दूसरे को चुना - सिर्फ लचीली कार्यप्रणाली की भावना में। मुझे लगता है कि फुर्तीली लागू समस्याओं को हल करने में वास्तव में मदद कर सकती है। और हमेशा बदलती मांगों की दुनिया में जीवन वह क्षेत्र है जिसमें आप घूम सकते हैं।

मेरा नाम मैक्सिम सुखारेंको है, मैं MySklad सर्विस प्लेटफॉर्म की टीम लीड हूं। और आज मैं आपको बताऊंगा कि हम बदलती आवश्यकताओं के साथ कैसे काम करते हैं।

क्लासिक से स्क्रेम तक

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

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

लॉजिक बताता है कि लगातार बदलते इंटरफ़ेस के साथ एक सिस्टम विकसित करने के लिए, आपको कुछ समय में आवश्यकताओं को ठीक करना होगा। लेकिन केवल किस पर? जब तक हम कार्यक्षमता का कुछ हिस्सा विकसित नहीं करते हैं?

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

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

"डॉक्टर, जब मैं इसे इस तरह कर रहा हूं, तो यह मुझे तकलीफ देता है।"
"और आप ऐसा नहीं करते हैं।"

जो नहीं समझता, वह बड़ी सुविधाएँ नहीं बनाता । आप स्प्रिंट के साथ मेल खाने के लिए एक या दो सप्ताह के लिए आवश्यकताओं को ठीक कर सकते हैं, और स्प्रिंट के उद्देश्य के लिए आवश्यकताओं के अनुसार कार्यात्मक के कार्यान्वयन को निर्धारित करते हैं। और कार्यक्षमता को ऐसे टुकड़ों में पीटना चाहिए ताकि वे एक या दो स्प्रिंट में फिट हो जाएं। बहुत मुश्किल लगता है? और फिर! आप टिकट कटवाना नहीं जानते। देखा, शूरा, देखा, वे सुनहरे हैं।

बेशक, यह इतना आसान नहीं है, हमें इस दिशा में उद्देश्यपूर्ण ढंग से आगे बढ़ने की आवश्यकता है - विकास को छोड़ने के लिए "हम इसे छह महीने तक करेंगे, फिर हम परीक्षण के लिए एक नया संस्करण रोल करेंगे।"

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

मिशनों का मुकाबला करने के लिए

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

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

हमने इसे छोटे कार्यों में काट दिया और पूरी टीम में बिखेर दिया। मैं शराब के साथ क्रिप्टोग्राफी की तुलना करता हूं: कंपनी में और एक मध्यम खुराक में, यह बहुत अधिक और अकेले की तुलना में बेहतर है।
चूंकि हम क्लाउड सेवा विकसित कर रहे हैं, इसलिए हमारे लिए CryptoPro EDS ब्राउज़र प्लग-इन का उपयोग करना आसान था (यह विज्ञापन नहीं है, यह निराशाजनक है)। यह CryptoPro CSP को वेब पेज पर कुंजियों और एन्क्रिप्शन विधियों का विस्तार करने की अनुमति देता है।

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

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

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

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

परीक्षण कार्यक्षमता

मैं यह पता लगाने का प्रस्ताव करता हूं कि परीक्षण के साथ क्या करना है और क्या करना है अगर हम एक लाइव प्रोजेक्ट में एकीकरण जोड़ते हैं।

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

हमारे पास स्वीकृति और प्रतिगमन परीक्षणों का एक निश्चित सेट है, उनमें से कुछ स्वचालित हैं, कुछ हाथ से पकड़े हुए हैं।

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

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

आमतौर पर आपको परीक्षणों के तीन से पांच पूर्ण रन मिलते हैं - हाथों की कार्यक्षमता और प्रत्यक्षता की जटिलता पर निर्भर करता है। लेकिन प्रक्रिया को और भी तेज किया जा सकता है - यदि आप छोटी सुविधाओं पर हराते हैं।

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

प्रोजेक्ट में जोड़ें

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

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

यह समझने के लिए बना रहता है कि ठेस पर आंशिक रूप से कार्यात्मक कार्यक्षमता कैसे रोल करें। जवाब काफी सरल है: यह उपयोगकर्ता के लिए सुलभ नहीं होना चाहिए। यदि आप यह पूछना चाहते हैं कि आपको ऐसा क्यों करना चाहिए, तो आप ऊपर कुछ पैराग्राफ वापस कर सकते हैं।

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

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