Konfiguryabelnost

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



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



अगले स्टैंड-अप पर, मैं एक तरफ खड़ा हूं, किसी को भी स्पर्श न करें, उस समय लोग एक परियोजना के टुकड़ों पर चर्चा कर रहे हैं, और फिर स्लावका (हमारे नेता) मेरे अस्तित्व को याद करते हैं, मुझे कहते हैं और कहते हैं:

- सरयुग, क्या आप अभी कुछ खास नहीं कर रहे हैं?

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

"बहुत बढ़िया," स्लावका कहते हैं, "मेरे पास आपके लिए करने के लिए बस कुछ है।" क्या आप लेंगे?

"ठीक है, क्यों नहीं, एक बार यह कुछ है।" जरूर आना।

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

"ठीक है, ठीक है," मैं कहता हूँ। - यह विचार उचित है, और बहुत बार उन्हें संपादन करना पड़ा? - मैं पूछता हूं।

"हाँ, वह गलत है," स्लावका जवाब देता है, "लोग कहते हैं कि परिवर्तन के लिए कोई अनुरोध नहीं थे, क्योंकि वे इस आर # $ @ ओ-कोड में आने से डरते थे। इसलिए मुझे नहीं पता कि यह कितना उपयोगी है, लेकिन मैं यह सुनिश्चित करने के लिए जानता हूं कि वे विन्यास के बिना कहीं भी नहीं चाहते हैं।

- ओकी, मुझे एक दिन दे दो, मैं पुराने सिस्टम के कोड को समझता हूं और आपने पहले से ही नए संस्करण के लिए क्या किया है, लेकिन मैं सोच रहा हूं कि क्या यह इस विन्यास को खराब करने के लायक है।



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



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

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

"हां, यह पूरी तरह से बकवास है," मैं निरंकुश बना रहा, "दूसरे धर्म में विन्यास से वे कैसे खुश नहीं हैं?"

स्लाव एक झाड़ी के साथ जवाब देता है, "उनका मानना ​​है कि हमें सिस्टम के फर्श को फिर से लिखना होगा, अगर हम इसे तुरंत नहीं करते हैं।"

"ठीक है, इसे धिक्कार है, यदि आप एक जगह लिखते हैं, तो आपको इसे पूरी तरह से फिर से लिखना होगा," मैं जोर देता हूं।

साशा बातचीत में हस्तक्षेप करती है, "आप इस बारे में चिंतित क्यों हैं," आप परवाह नहीं करते हैं, ठीक है, ग्राहक इसे चाहता है, तो चलो इसे करते हैं, और चलो इसके बारे में भूल जाते हैं ... "

"हाँ, हम (और केवल हमारा ही नहीं) सभी प्रणालियों में एक ही स्थान पर ठीक-ठीक लिखा है क्योंकि वे अलग-अलग होटल व्यवसायियों को यह नहीं समझाते कि उनकी इच्छाएँ क्या हो सकती हैं," मैंने कहा। - तो हम उन प्रणालियों को प्राप्त करते हैं जिन्हें कार्यालय से सिस्टम के लेखकों को फिर से लिखने की आवश्यकता होती है। हम अपने विशेष मामले में क्या देखते हैं।

"सामान्य तौर पर," जय कहते हैं। "बेशक, आप एक बार फिर उन्हें समझाने की कोशिश कर सकते हैं कि वे गलत हैं, लेकिन मैं ऐसा नहीं करूंगा।" सामान्य तौर पर, इसकी चर्चा पर इतना प्रयास और समय बिताने के लिए विन्यास करना इतना मुश्किल काम नहीं लगता है।

- ठीक है, लेकिन चूंकि मैंने ग्राहक के साथ पिछली चर्चा में भाग नहीं लिया था, इसलिए मैं इसे एक ही बार कोशिश करता हूं।

- ठीक है, ठीक है, इसके लिए जाओ। बस बहुत अधिक कसें नहीं। आज की बैठक में उनके साथ इस पर चर्चा करते हैं, “स्लावका कहते हैं। - क्या आपके पास पर्याप्त समय है, इस समय तक आपको किस तरह के दस्तावेज़ की आवश्यकता है?

"हां, काफी," मैं खुशी से कहता हूं, चुपके से उम्मीद कर रहा है कि यह मेरे लिए ऐसा करने के लिए सामने आएगा जो मेरे सहयोगियों ने पहले सफल नहीं किया था।



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



ठीक है, दस्तावेज़ तैयार है, लोगों द्वारा अनुमोदित है। हम शाम की रैली के लिए तत्पर हैं।

- जॉन, स्कॉट, शुभ दोपहर। यहाँ हमारे विन्यास के बारे में अतिरिक्त विचार थे, क्या आपने सर्गेई द्वारा भेजे गए दस्तावेज़ को पढ़ा था? - बातचीत की शुरुआत से ही स्लाव हॉर्न्स द्वारा सांड को पकड़ लेता है। - आप इस बारे में क्या सोचते हैं?

"ठीक है, मैं क्या कह सकता हूं," ग्राहक के हिस्से पर इस परियोजना के "हितधारक" स्कॉट का जवाब देते हैं। - विचार बुरा नहीं लगता है, और आधिकारिक लिंक, लेकिन, अफसोस, तर्क आश्वस्त नहीं हैं ...

"कैसे आश्वस्त नहीं," मैं हस्तक्षेप करता हूं और फिर से इस सब के बारे में बात करने की कोशिश करता हूं ...



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

"अरे, यह अच्छा है," कोल्यान बातचीत में शामिल हो गए। - अभी हमें अभिव्यक्ति पार्सर के कुछ धागे मिलेंगे, इसे और सभी चीजों को पेंच करना होगा!

"हाँ, और आप अभी भी इसे करने के लिए कोडडोम का उपयोग कर सकते हैं," स्लावका ने सुझाव दिया, या तो मजाक के रूप में या गंभीरता से।

"हाँ," मैंने लोगों का समर्थन किया, "और क्या आपके अंगों को काटने के अलावा आत्महत्या के कोई और अधिक परिष्कृत तरीके हैं?" यह गौरैयों पर एक बंदूक से है! दो दर्जन शर्तों की जांच के लिए सभी बकवास को पेंच करने के लिए, जो कि किसी को कॉन्फिगर करना चाहता है! इसके अलावा, किसी को भी नहीं पता कि ये स्थितियां कितनी बार बदलेंगी या जोड़ी जाएंगी।

- क्या आप डिबग प्रक्रिया की कल्पना करते हैं, जब उपयोगकर्ता आपको बताता है कि आपका आर्केड सिस्टम काम नहीं करता है जैसा कि यह सुझाव देता है? - मैं हार नहीं मानता। "आपने एक गॉन्फ़िग में गड़बड़ नहीं की है ..."

"ठीक है, हमारे लिए क्या रहता है?" - महिमा मुझे शांत करने की कोशिश करती है। "कई कार्यान्वयन विकल्पों का हवाला देते हुए, प्रत्येक अपने स्वयं के पेशेवरों और विपक्षों के साथ, और उन्हें अपने स्वयं के विकल्प बनाने के लिए आमंत्रित करते हैं।"

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



***************************************



"ठीक है, इस कहानी के साथ क्या हुआ?" - सान्या अधीर होकर पूछती है। - तो आप सही थे या नहीं? क्या इस विन्यास से कोई मतलब था? कम से कम, किसी ने इसका इस्तेमाल किया? - सान्या ने उत्साह से बात की।

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

- तो तुम किस पर रुक गए? - सान्या को रोकती है।

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

यहां तक ​​कि इस संस्करण में, हम पहले से ही डिबगिंग और डायग्नोस्टिक्स की कठिनाइयों का सामना कर चुके हैं, लेकिन इस तथ्य के कारण कि मैं न केवल संकलित कार्यों को बचाता हूं, बल्कि खुद को "fleas" को पकड़ने के लिए भी हल करने के लिए एक समस्या है।



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



प्रोग्रामिंग स्टफ के माध्यम से