जटिल सॉफ्टवेयर सिस्टम में बदलाव हमेशा के लिए लगता है, है ना? यहां तक ​​कि इंजीनियर भी अक्सर सोचते हैं कि जो होना चाहिए उससे परे बदलाव हो रहा है, हालांकि हम सिस्टम की जटिलता से अवगत हैं!

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

इसलिए, जल्दी या बाद में, ग्राहक एक पत्र भेजेगा: "नरक में इतना समय क्यों लगता है?" चलो यह नहीं भूलना चाहिए कि हम, सॉफ्टवेयर इंजीनियर के रूप में, दुनिया में एक खिड़की है, जिसकी उन्हें अक्सर कमी है। वे हम पर बहुत भरोसा करते हैं, लेकिन कभी-कभी एक बहुत ही तुच्छ परिवर्तन वास्तव में बहुत समय लगता है। इस वजह से सवाल उठते हैं।

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

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

एक पत्र

प्रिय ग्राहक,

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

अपने नोट को छिन्न-भिन्न करने के लिए:

मेल द्वारा अधिसूचना के लिए एक दिन में कार्यों को पूरा करने की समय सीमा को बदलना चाहिए। 4-8 घंटे कैसे लग सकते हैं? मुझे क्या याद आ रहा है?

एक तरफ, मैं आपसे सहमत हूं। केवल tasks due <= today अनुरोध भाग को tasks due <= today के tasks due <= tomorrow बदलें।

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

भाग 1. यह छोटा परिवर्तन जितना लगता है उससे अधिक क्यों है?

यह एक सरल, छोटा परिवर्तन, कोड की एक पंक्ति है। उस पर पूरे दिन खर्च करना, यहां तक ​​कि आधा दिन, अत्यधिक लगता है।

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

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

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

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

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

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

और फिर अधिसूचना तर्क आपके विचार से अधिक जटिल है। यह सामान्य और व्यक्तिगत कार्यों, खुले और निजी, बार-बार, एक अतिदेय कार्य के मामले में प्रबंधक की अतिरिक्त अधिसूचना के कार्य आदि के बीच अंतर करता है, लेकिन हम जल्दी से पता लगा सकते हैं कि वास्तव में अतिदेय कार्य की 6 में से 2 परिभाषाएँ केवल सूचनाओं के लिए उपयोग की जाती हैं। और लक्ष्य को पाने के लिए केवल एक चीज को बदलने की जरूरत है।

इस तरह की समीक्षा आसानी से एक या आधे घंटे का समय ले सकती है, शायद कम यदि आप हाल ही में कोड बेस के इस हिस्से में हैं। इसके अलावा, अव्यक्त जटिलता का अर्थ है कि हम मैन्युअल परीक्षण के लिए अपने अनुमान को पार कर सकते हैं। लेकिन अतिरिक्त प्रयास के लिए केवल 30 मिनट जोड़ दें।

इस प्रकार, हमें यह महसूस करने के लिए 1.5 घंटे तक पहुंच गया कि परिवर्तन अपेक्षित रूप से किया जाएगा।

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

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

इस प्रकार, हम इस काम को पूरा करने के लिए 2-2.5 घंटे की सीमा में चले गए कि उपयोगकर्ता के काम में बिना किसी दुष्प्रभाव या भ्रम के सब कुछ ठीक हो जाएगा।

भाग 2. मैं इस समय को कैसे कम कर सकता हूं?

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

स्थिति को मापने के लिए दो मुख्य रणनीति हैं:

1. दोहराव और जटिलता को कम करने के लिए कोड बेस को सक्रिय रूप से साफ करें।
   
2. स्वचालित परीक्षण लिखें।

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

आपने देखा कि इनमें से कोई भी रणनीति हमारे 2-2.5 घंटों में शामिल नहीं है।

उदाहरण के लिए, स्वच्छ कोड आधार बनाए रखने का अर्थ है कि केवल कार्य पूरा करने के बजाय, हम प्रश्न पूछते हैं:

• ऐसे कार्यों की पहचान करने के लिए विभिन्न तरीके क्यों हैं जिनकी समय सीमा समाप्त हो गई है / समाप्त हो गई है?
  
• क्या उन सभी को जरूरत है और उन पर काम करें?
  
• क्या इन विधियों को एक या दो अवधारणाओं / विधियों में घटाया जा सकता है?
  
• यदि अवधारणा को पुरानी और नई प्रणालियों के बीच विभाजित किया जाता है, तो क्या इसे समेकित किया जा सकता है?

और इसी तरह।

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

लेकिन अंत में, कोड आधार का यह हिस्सा बहुत सरल हो जाएगा, इसे पढ़ना और संशोधित करना आसान होगा।

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

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

1. परिवर्तन सही ढंग से काम करता है;
   
2. परिवर्तन कुछ भी नहीं तोड़ता है (यह पहले पैराग्राफ की तुलना में अधिक मूल्यवान जानकारी है)।

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

भाग 3. हम कहाँ से आए थे? हम कहां जा रहे हैं?

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

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

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

हम चलते-चलते कोड को साफ़ करने का प्रयास करते हैं, और हम हमेशा अच्छी तरह से परीक्षण करते हैं। लेकिन सावधान और मेहनती होना, सक्रिय स्वचालित परीक्षण के लिए आवश्यक रिफैक्टरिंग या बुनियादी ढाँचे का निर्माण नहीं है।

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

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

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

आपका धन्यवाद
ई