एक चुस्त और झरना प्रक्रिया समयरेखा के भीतर कोड रीफैक्टरिंग और ऑप्टिमाइज़ेशन कहां होना चाहिए?

Question

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

Answer 1

एक अतिव्यापी सिद्धांत है जो झरना और फुर्तीली दोनों में रिफ्लैक्टर और ऑप्टिमाइज़ करने की आवश्यकता को नियंत्रित करता है: YAGNI (यू ऐनोट गॉन नीड इट)। एक दूसरा सिद्धांत पहले का मूलाधार है: "समयपूर्व अनुकूलन सभी बुराई की जड़ है", सामान्य कहावत का कोडिंग समकक्ष "उत्कृष्टता का दुश्मन पूर्णता है"।

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

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

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

विकसित करते समय, आपको पता है कि आपके पास एक आवश्यकता है कि सिस्टम प्रति सेकंड 10KB कच्चे डेटा को संसाधित करने में सक्षम हो। आप एक लोड परीक्षण करते हैं और पाते हैं कि आपका प्रारंभिक मसौदा एल्गोरिथ्म 8KB / s संभालता है। खैर, यह AAT पास करने वाला नहीं है। आप एक नज़र डालते हैं और देखते हैं कि आपके एल्गोरिथ्म में कुछ O (मेरा भगवान) है -complexity लूप संरचना; आप इसे सुव्यवस्थित करते हैं और 12KB / s प्राप्त करते हैं। "बहुत अच्छा", आपको लगता है, "लेकिन अगर मेरे पास कोड में एक गरीब लूप था, तो मैं और क्या कर सकता हूं?" buzz आपने अभी-अभी "समयपूर्व अनुकूलन" नियम का उल्लंघन किया है। आपका कोड काम करता है, और सभी आवश्यकताओं को पारित करता है। आप "किए गए" हैं, जब तक कि आवश्यकताओं को 15KB / s की आवश्यकता के लिए अद्यतन नहीं किया जाता है। यदि और जब ऐसा होता है, तो आप कोड को वापस ऊपर खींचते हैं और चीजों को सुधारने के लिए देखते हैं।

विकसित करते समय इस सरल प्रक्रिया का पालन करें, चाहे वह फुर्तीली हो या पारंपरिक एसडीएलसी में: "पहले पास पर, उसे काम करें। दूसरे पास पर, इसे सुंदर बनाएं। तीसरे पास पर, इसे ठोस बनाएं।" इसका क्या मतलब है, जब आप पहली बार कोड की एक पंक्ति बनाते हैं, तो उस कोड को अपना काम सही और बग-मुक्त करें, लेकिन इस कोड के भीतर नियमों को डिजाइन करने के लिए बहुत ध्यान न दें, जैसा कि आप सभी जानते हैं कि अभी आप ' इस क्षेत्र को फिर कभी नहीं छूएंगे। अगली बार जब आप कोड की उस पंक्ति पर जाएँ, तो आपने अपने आप को गलत साबित कर दिया; यह अब सिस्टम का एक-बंद टुकड़ा नहीं है। यह पठनीयता, कोड की संक्षिप्तता और / या DRY सिद्धांतों के लिए इसे रिफ्लेक्टर करता है (आपके पास कुछ कोड करने के लिए कुछ कोड कॉपी-पेस्ट किया जा सकता है; रिफ्लेक्टर एक लूप और / या एक विधि कॉल में)। तीसरी बार जब आप कोड की उस लाइन में या उसके आसपास काम कर रहे हों,

Comments

+1 O(my God)-complexityअगर कुछ और नहीं, तो मुझे हंसी आ गई!

— जोएल सी।

+1 के लिए इसे पहले काम करें। बहुत से लोग पैटर्न लिखने की कोशिश करते हैं और समय से पहले बल्ले से अनुकूलन करते हैं।

— जस्टिन शील्ड

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

— टॉडआर

मैं व्यावहारिक aproach पसंद करता हूं, लेकिन मुझे "दूसरी पास पर, इसे सुंदर बनाएं" के साथ एक समस्या है: यदि दूसरा पास एक साल बाद है और आप यह सुनिश्चित करते हैं कि चर और विधि के नाम अर्थपूर्ण हैं और जादुई संख्या को प्रतीकात्मक स्थिरांक से बदल दिया गया है आपको शायद कोड को समझने में समस्या हो। इससे कैसे निपटें? एक महीने के बाद या एक साल के बाद "इसे सुंदर बनाओ" की तुलना में "इसे सुंदर बनाओ" काम करने के 1 घंटे बाद "बहुत सुंदर है"। मैं सहमत हूँ कि जब अगला कोड परिवर्तन उपयोगी हो तो "इसे सुंदर बनाएं" यदि "सुंदर बनाते हैं" तो पहले स्थान पर नहीं किया गया।

— k3b

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

— कीथ्स

Answer 2

यदि यह काम करता है, और परीक्षण किया गया है, तो इसे ठीक क्यों करें?

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

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

जब आप "किए गए" कार्य को कॉल करते हैं, तो यह आपकी ओर से एक निर्णय कॉल है; यदि आप अपने राज्य के साथ सहज नहीं हैं तो आपका कार्य पूरा नहीं होगा।

Comments

मैं "तकनीकी ऋण" अवधारणा का प्रशंसक बन गया हूं, इस संदर्भ में इसे लाने के लिए +1।

— पैट्रिक ह्यूजेस

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

— कीथ्स

Answer 3

क्या यह "मैं बेहतर कर सकता हूं" समय वास्तव में समयरेखा के भीतर कहीं फिट होता है?

हाँ।

इससे पहले कि आप अगली रिलीज़ को कोड करना शुरू करें ।

"अंतर्ज्ञान" पर आधारित रिफ्लेक्टर न करें।

अगली स्प्रिंट की वास्तविक कहानियों के आधार पर रिफ्लेक्टर।

Answer 4

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

मैं टीडीडी के लाल हरे रंग की रिफैक्टर विधि का उपयोग करता हूं। इसलिए मेरा विकास मेरे विकास में निर्मित है। अंतर्निहित मॉडल को बदलने या कुछ इसी तरह के बड़े रिफैक्टरिंग के लिए, मुझे पहले समय बिताने के लिए प्रबंधन खरीद मिलेगी।

Comments

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

— कीथ्स

Answer 5

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

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

तो एक असली जवाब के लिए: यदि आप जानते हैं कि आप रिफ्लेक्टर करना चाहते हैं तो उस समय को कार्य के हिस्से के रूप में शेड्यूल करें। यदि आप scrum / agile कर रहे हैं, तो टाइम बॉक्स एक क्लीन-अप कार्य करें। यदि आप झरना / सर्पिल हैं, तो मॉड्यूल की समीक्षा करने और उसे स्वीकार करने के लिए प्रक्रिया का रिफलेक्टर हिस्सा बनाएं।

Answer 6

अगर मैं काम कर रहे कार्यक्षमता का एक टुकड़ा पाने के लिए वैकल्पिक तरीकों की कोशिश कर रहा हूं, तो इसका मतलब यह नहीं है कि मुझे सबसे अच्छा समाधान मिल गया है,

... जिस मामले में आप अभी तक 100% नहीं हुए हैं ...

या इसे अन्य डेवलपर्स के साथ समीक्षा करने के बाद कुछ सुधार की आवश्यकता नहीं होगी।

यदि कोड की समीक्षा और बाद की पुनरावृत्ति आपके विकास के जीवन चक्र का हिस्सा है, तो फिर से यह सुविधा तब तक नहीं की जाती है जब तक कि ये सभी समाप्त नहीं हो जाते हैं।

मैं अक्सर कुछ के साथ काम करता हूं, वापस कदम रखता हूं, और फिर खुद से पूछता हूं कि व्यावसायिक नियमों से संतुष्ट होने के बाद मैं क्या बेहतर कर सकता हूं। क्या यह "मैं बेहतर कर सकता हूं" समय वास्तव में समयरेखा के भीतर कहीं फिट होता है?

निर्भर करता है। यदि इसका मतलब है कि रिफैक्टिंग, यह मूल विकास कार्य का हिस्सा होना चाहिए। यदि इसका अर्थ है संभावित रूप से बेहतर एल्गोरिदम के साथ प्रयोग करना, तो यह एक अलग कार्य हो सकता है।

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

संक्षेप में, क्योंकि कोड को कई स्तरों पर तोड़ा जा सकता है।

यह एक बात है कि यह अभी काम करता है। यह एक पूरी तरह से अलग बात है कि क्या यह लंबे समय में साफ, विस्तार योग्य और बनाए रखने योग्य है।

अधिक विस्तृत उत्तरों के लिए, यह धागा देखें ।

Answer 7

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

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

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

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

Comments

"तथ्य यह है कि चंचलता के लिए फुर्तीली में कोई जगह नहीं है" - मुझे नहीं लगता कि यह एक सच बयान है। चंचलता में, किसी भी प्रकार के विकास के लिए एक जगह है, जिसमें रिफैक्टरिंग शामिल है, जब तक कि इसके लिए एक व्यावसायिक मामला है। यदि इसके लिए कोई व्यावसायिक मामला नहीं है, तो आप ऐसा क्यों कर रहे हैं?

— ब्रायन ओकले

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

— ब्लाइंडकोडिफायर9734