तकनीकी ऋण को कम करने के लिए मुझे भुगतान कैसे किया जा सकता है?


16

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

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

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

समस्या यह है, मैं अपना खुद का समय बिताता हूं। मुझे वास्तव में परिणाम पसंद हैं, लेकिन मुझे प्रति दिन 12 घंटे काम करना पसंद नहीं है। क्या आप कभी ऐसी ही स्थिति में आए हैं? मुझे क्या प्रयास करना चाहिए? मैंने पहले ही इस पर चर्चा करने की कोशिश की है, लेकिन अभी भी कोई सफलता नहीं मिली है।

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

कोई विचार?


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

3
ठीक है, तो आपका विशिष्ट प्रश्न क्या है? यदि आप अपने समय पर विकसित की गई वास्तुकला बेहतर हैं तो आप इसे प्रक्रियात्मक क्यों रखना चाहेंगे?
रॉबर्ट हार्वे

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

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

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

जवाबों:


37

चरण 1: अवैतनिक ओवरटाइम काम करना बंद करें।

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

चरण 2: नोट्स बनाएं

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


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

17
"अनपेड ओवरटाइम काम करना बंद करो" भले ही आप नौकरी से प्यार करते हों, लागू करना चाहिए। आप अपने अतिरिक्त घंटों से लाभ नहीं उठा रहे हैं; वो हैं। यदि आप कंप्यूटर के सामने समय बिताना चाहते हैं, तो इसे अपनी परियोजनाओं के लिए, अपने घर पर करें।
क्रिस्टोफर महान

1
इस उद्योग में एक दशक से अधिक समय के बाद, मैंने अभी भी "एक धीमी गति से हिट" नहीं किया है। मैं क्या गलत कर रहा हूं?
sbi

@sbi मुझे लगता है कि "यह सही कर सकता है" :)
स्टीफन

13

... कोड को बनाए रखना वास्तव में कठिन है।

यह प्रबंधन के साथ आपका तरीका है। दर्शाते हैं कि बगों को ठीक करने और नई कार्यक्षमता जोड़ने की लागत कोड को रिफैक्ट करने और फिर से लिखने की तुलना में अधिक है।

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

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


7

बॉय स्काउट नियम लागू करें : हर बार जब आप इसे छूते हैं तो कोड को थोड़ा सा कम (यानी कम तकनीकी ऋण के साथ) छोड़ दें।

आपके द्वारा दिए गए सभी अनुमानों में ऐसा करने का समय दें। फिर, जादुई रूप से, समय के साथ तकनीकी ऋण गायब हो जाएगा और आपको इसे करने के लिए भुगतान किया जाएगा।

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


हालांकि, यह दृष्टिकोण किसी भी अधिक महत्वपूर्ण रीफैक्टरिंग को करना असंभव बना देगा।
sbi

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

@ एसएसबी: किसी को वास्तव में कभी भी पर्याप्त रिफैक्टरिंग नहीं करनी चाहिए - एक समय में केवल एक परिवर्तन / रीफैक्टरिंग। काम की छोटी इकाइयाँ, छोटे-छोटे बदलाव, और निश्चित रूप से सभी परीक्षणों को चलाने और बनाने के लिए (दोगुना) सुनिश्चित करें कि आपने कुछ भी नहीं तोड़ा।
Cululhu

@ कथुलु: यदि आपके पास अच्छी इकाई परीक्षण हैं, तो आप नीचे दस्तक दे सकते हैं और लगभग जितने चाहें कोड पुनर्निर्माण कर सकते हैं, क्योंकि परीक्षण अधिकांश त्रुटियों को पकड़ लेंगे।
sbi

4

यह रखरखाव प्रोग्रामिंग की दुखद वास्तविकता है। जिसे आप बनाए रखने के लिए दिए गए हैं, उसके साथ आप फंस गए हैं और यदि बिल का भुगतान करने वाला व्यक्ति बिना लाभ के बदलाव के लिए भुगतान नहीं करना चाहता है, तो वे परिवर्तन नहीं किए जाते हैं।

यदि आप इन परिवर्तनों को वित्त पोषित करने के लिए मामला बनाना चाहते हैं, तो उन सभी स्थानों का लॉग रखें, जिन्हें आपको सबसे सरल अद्यतन के लिए भी बदलना है। कुछ परिवर्तनों के बाद, अपने प्रबंधक के साथ लॉग पर चर्चा करें। यदि आप इसे दस्तावेज कर सकते हैं, तो एक मौका है (यद्यपि बहुत पतला है) कि पर्स वाले व्यक्ति को एहसास होगा कि यह कोड को साफ करने के लिए लंबे समय में वास्तव में सस्ता है क्योंकि यह भविष्य के बदलावों को सस्ता कर देगा।

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

इसे छोड़कर, सीखें कि आप क्या कर सकते हैं और कम रखरखाव के साथ दूसरी स्थिति में आगे बढ़ सकते हैं।


3

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

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

इसलिए ... आपको प्रबंधन को यह विश्वास दिलाना होगा कि आपके द्वारा प्रस्तावित बदलावों से कंपनी को मदद मिलेगी:

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

3

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

बेशक, उसे एक ऑटोमोटिव रूपक में लपेटना था ताकि उसके दर्शक उससे संबंधित हो सकें।

"वन पीस एट ए टाइम" - जॉनी कैश


2

ऐसा लगता है कि आप ग्राहक को उस समय के लिए चार्ज कर सकते हैं जब परिवर्तन "लेना" चाहिए और फिर भी लंबे समय में WAY आगे आएगा।

यदि आपको कोड को साफ करने में मज़ा आता है (और ऐसा लगता है कि आप कम से कम थोड़ा करते हैं) तो आगे बढ़ें और इसे करते रहें लेकिन खुद को इससे बाहर न जलाएं। वह आपको, आपकी कंपनी या आपके अन्य ग्राहकों को कोई अच्छा काम नहीं देता है।

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


1
@robertharvey: हाँ, वह अपने समय पर कोड को साफ कर रहा है ताकि ग्राहकों को अपडेट के लिए बिल भेजा जाए, यदि कोड अच्छी तरह से लिखा गया था, तो इससे अधिक भुगतान नहीं करना पड़ेगा। मुझे लगता है कि उनकी कंपनी को लागत का बहुमत खाने की जरूरत है (यदि वे होते हैं)। यह उचित है कि ग्राहक कुछ समय का भुगतान करता है, लेकिन अगर आप ओवरबिल करते हैं क्योंकि कोड बकवास है जो अच्छी-इच्छा और भविष्य के व्यवसाय को खोने का एक अच्छा तरीका है।
DKnight

2

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

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


1

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

एक बार जब वे समझ जाते हैं कि आप किस बारे में बात कर रहे हैं, तो तकनीकी ऋण को कम करने की दिशा में थोड़ा समय लगाने के लिए बातचीत करने का प्रयास करें। मेरी कंपनी में हम तकनीकी ऋण में कमी के लिए काम करने के लिए प्रत्येक डेवलपर्स समय के 10% के लिए याचिका के साथ यथोचित सफल रहे हैं।

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


1

और बेहतर उपकरणों में कारक के लिए मत भूलना। Resharper एक बढ़िया रीफ़ैक्‍टेयरिंग टूल है जो विज़ुअल स्टूडियो में प्लग इन करता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.