ज़ेन और द आर्ट ऑफ़ प्योर कोड सपोर्ट

नमस्कार, हेब्र!

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

अच्छा पढ़ा है।

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

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

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

कॉरपोरेट गैराज में ऑर्डर देना

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

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

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

सॉफ्टवेयर डेवलपमेंट में ऑर्डर देना

आइए एक विशिष्ट उदाहरण देखें: वृद्धिशील परावर्तन।

यह अभिव्यक्ति कई लोगों को हैरान कर रही है। मुझे नहीं पता कि कौन सा शब्द उन्हें भ्रमित करता है: "वृद्धिशील" या "पुन: सक्रिय करना"।

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

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

धीरे-धीरे परावर्तन

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

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

स्काउट नियम

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

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

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

"दीर्घकालिक" आमतौर पर ऐसा नहीं होता है जब तक ऐसा लगता है

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

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

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

क्या तेजी है, क्या धीमी है?

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

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

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

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

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

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

एक रूपक के रूप में तकनीकी ऋण

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

जो लोग ऐसा कहते हैं वे इस रूपक को नहीं समझते हैं, और शायद कोई रूपक भी नहीं।

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

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

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

जल्दी से काम सौंपने के लिए कोनों को काटना तकनीकी ऋण का संचय नहीं है। यह एक सामान्य हैक है।

कौन है जिम्मेदार?

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

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