आज एक धूप वाला दिन है। आप अपने गाँव की सड़क पर चल रहे हैं जहाँ आपके सभी दोस्त, आपका परिवार और आपका प्यारा कुत्ता रहता है। एक अद्भुत दिन! अचानक आप एक भयानक, दुःस्वप्न रोना सुनते हैं जो आसपास के वातावरण को फाड़ देते हैं। विशाल घृणित हाइड्रा इसे नष्ट करने के लिए गांव से संपर्क कर रहा है! आप एक तलवार पकड़ते हैं (निश्चित रूप से, आपके पास एक तलवार है!) और आप जिसे प्यार करते हैं, उसकी रक्षा करने की कोशिश करें। लेकिन एक छोटी सी समस्या है: राक्षस के कई लक्ष्य हैं, और जब आप उनमें से एक को काट देते हैं, तो एक नया तेजी से बढ़ता है!
ऐसा लगता है कि आप इस लड़ाई को नहीं जीत सकते। शायद आप हाइड्रा के साथ लंबे समय तक खेल सकते हैं ताकि पूरे गांव को भयानक खतरे से दूर उड़ने का समय मिले? अंत में, आप पूरी दुनिया के एक असली नायक बन जाएंगे! यह कौन नहीं चाहता है?
सॉफ्टवेयर में हाइड्रा की भूमिका एन्ट्रापी है: यह आपका दुश्मन है, वह आपको थका रहा है, लेकिन आप इससे पूरी तरह से छुटकारा नहीं पा सकते। लेकिन आपको अभी भी उससे लड़ने की ज़रूरत है ताकि आपके एप्लिकेशन (और सहकर्मी) स्वस्थ और समझदार रहें।
हम पता लगाएंगे:
- सॉफ्टवेयर में एंट्रॉपी क्या है और इसे अपने कोड में कैसे नोट करें।
- इसके संभावित कारण क्या हैं और एंट्रोपी कैसे कम रखें।
बात करने के लिए पर्याप्त, बात करने के लिए!
अपने शत्रु को जानो
एंट्रोपी क्या है और यह मेरे आवेदन में कैसे समाप्त हुआ?
कभी-कभी उपयोग किए गए शब्दों की व्युत्पत्ति का पता लगाना उपयोगी होता है, विशेष रूप से ऐसे विशिष्ट जैसे कि एन्ट्रॉपी। ग्रीक से अनुवादित, इसका अर्थ है "परिवर्तन।" बदलें। कुछ जो आपको एक सॉफ्टवेयर डेवलपर के रूप में इस्तेमाल करना चाहिए।
एंट्रोपी थर्मोडायनामिक्स के दूसरे नियम को संदर्भित करता है। यह कहता है कि एक बंद, अलग-थलग प्रणाली में, अराजकता की मात्रा समय के साथ कम नहीं होती है। यह स्थिर या बढ़ता रहता है।
सॉफ्टवेयर में एन्ट्रापी का विचार पुस्तक
ऑब्जेक्ट-ओरिएंटेड सॉफ्टवेयर इंजीनियरिंग के माध्यम से आया। जितना अधिक कार्यक्रम बदलता है, उतनी ही अराजकता होती है, इसकी एन्ट्रापी बढ़ जाती है।
गरीब डेवलपर्स के लिए सबसे पहली बात जो हमारे लिए स्पष्ट होनी चाहिए, वह दुखद सत्य है: हम अपने कार्यक्रमों में कितनी भी उलझनों से जूझ सकते हैं, लेकिन हम कभी इससे छुटकारा नहीं पा सकते हैं।
सर्वश्रेष्ठ टीम बनाएं (अपनी भागीदारी के साथ, निश्चित रूप से!), सबसे अच्छा वातावरण, सबसे अच्छा प्रबंधन, कंपनी में सर्वश्रेष्ठ संस्कृति, सर्वश्रेष्ठ परियोजना। समय के साथ क्या होगा?
- आप हर सुबह, "यह सबसे अच्छी परियोजना है!" एक हरे रंग की परियोजना जो एक सुंदर क्षेत्र की तरह दिखती है, एक अद्भुत सूर्योदय से रोशन होती है।
- आप और टीम अधिक से अधिक सुविधाएँ जोड़ेंगे। चूंकि आप सबसे अच्छे हैं, कुछ समय के लिए सब कुछ बहुत अच्छा लग रहा है।
- महीने या साल बीत जाएंगे। कोई भी अब किसी प्रोजेक्ट पर काम नहीं करना चाहता। भले ही यह अच्छी तरह से डिज़ाइन किया गया था, तकनीक पुरानी है, परियोजना को समझने के लिए बहुत अधिक प्रयास और समय की आवश्यकता है, यह पैमाने पर महंगा है। उसके अच्छे मानसिक मॉडल का निर्माण करना बहुत मुश्किल है।
आपने यह जटिलता कैसे पैदा की? आपको बस प्रोजेक्ट को स्केल करने की जरूरत है। अधिक तत्व अक्सर अधिक निर्भरता और उच्च जटिलता का मतलब है। मैंने पहले से ही इस बारे में एक
विस्तृत लेख लिखा था।
यदि आप अपने साथी विकासक लियोखा को यह समझाते हैं, तो वह जवाब देगा:
"Nifiga! क्या आप मूर्ख हैं? अराजकता और विकार का मेरे खूबसूरत ऐप में कोई स्थान नहीं है! कुछ बकवास से मेरी प्रतिष्ठा धूमिल नहीं होगी! मैं अपने भाग्य का स्वामी हूँ! अगर मैं अपना कार्यक्रम नहीं बदलता हूं, तो जटिलता नहीं बढ़ेगी, और विरोधाभास के इस सबूत के संबंध में, मैं घोषणा करता हूं कि आप गलत हैं, और मैं सबसे अच्छा हूं! "
आप ल्योका को शांत, आश्वस्त और निर्णायक रूप से समझा सकते हैं कि भले ही आप कार्यक्रम को नहीं बदलते हैं, लेकिन इसके आस-पास सब कुछ बदल जाएगा। यदि आपके पास तृतीय-पक्ष लाइब्रेरी है जिसे अपडेट नहीं किया जा रहा है, तो सुरक्षा मुद्दे होंगे। और यदि आप उन्हें अपडेट करते हैं, तो यह बदलने और एन्ट्रापी के लिए दरवाजा खोल देगा।
इसके अलावा, यदि एक दिन आपको लंबे समय के बाद अपने सॉफ़्टवेयर में कुछ बदलने की
आवश्यकता होती है, तो आपको सभी विवरण याद नहीं होंगे। और यहां तक कि सबसे अच्छा प्रलेखन आपकी मदद नहीं करेगा। दुनिया बदल गई है, और जो कल सच था वह कभी भी सच नहीं हो सकता है, दोनों तकनीकी स्तर पर और व्यावसायिक स्तर पर।
इस तरह के बदलाव एक बार बड़ी मात्रा में एन्ट्रापी लाते हैं।
तो सवाल इससे छुटकारा पाने में नहीं है, बल्कि संयम में है। यह एक वास्तविक लड़ाई है जिसे हम डेवलपर्स में फेंक देते हैं।
सॉफ्टवेयर में एन्ट्रॉपी की परिभाषा
सॉफ्टवेयर की गुणवत्ता
यह कैसे पता करें कि आपके आवेदन में उच्च स्तर की एन्ट्रापी है? एक अच्छा संकेतक कोड की गुणवत्ता है।
यह क्या है और इसे कैसे मापना है?
त्वरण के अनुसार
: देवों के पीछे का विज्ञान :
- यदि परिवर्तनों / विफलताओं का अनुपात बढ़ता है, तो गुणवत्ता घट जाती है। ट्रैक परिवर्तन, बग और क्रैश, उनकी एक-दूसरे से तुलना करें। यदि प्रत्येक परिवर्तन नए बग या क्रैश की ओर जाता है, तो आपके प्रोग्राम में एन्ट्रापी बढ़ जाती है।
- डेवलपर्स द्वारा परियोजना की व्यक्तिपरक धारणा द्वारा एक महत्वपूर्ण भूमिका निभाई जाती है। यदि सभी को यह महसूस होता है कि आवेदन को बिना तोड़े इसे बढ़ाना कठिन होता जा रहा है, तो एन्ट्रापी शायद अधिक है। हालांकि, यह सनसनी आम होनी चाहिए।
- यदि टीम बग को ठीक करने या विफलताओं से उबरने में बहुत समय बिताती है, तो एन्ट्रापी ने आपके आवेदन में एक घोंसला बनाया होगा।
यदि आप परिवर्तनों और विफलताओं के सहसंबंध के बारे में कुछ जानकारी प्राप्त कर सकते हैं, और बग को ठीक करने में समय बिता सकते हैं, तो आप किसी तरह के रिफैक्टरिंग की आवश्यकता के प्रबंधन को समझाने के लिए एक अच्छी अनुसूची के साथ आ सकते हैं।
कठिनाई का दानव
यहां तक कि अगर आपके पास उच्चतम गुणवत्ता का कोड है, तो जटिलता आसानी से बढ़ सकती है जब यह कार्यक्रम की बहुत क्षमताओं की बात आती है। व्यवसाय ही
आवश्यक जटिलता का एक स्रोत है जिससे आप छुटकारा नहीं पा सकते हैं।
व्यवसाय की अत्यधिक जटिलता को देखते हुए, डेवलपर्स को कंपनी के व्यवसाय का एक अच्छा
मानसिक मॉडल बनाने के लिए बहुत प्रयास करना होगा। इसलिए, वे व्यावसायिक आवश्यकताओं को कोड में अनुवाद करने की कोशिश करने में गलती करेंगे।
चलो व्यवसाय की जटिलता के बारे में अधिक विस्तार से बात करते हैं: क्या हमें वास्तव में इन सभी जटिल विशेषताओं की आवश्यकता है जो हमें निराश करते हैं?
एन्ट्रापी का कारण, और इससे कैसे निपटना है
एन्ट्रापी झरना
समस्या
अधिक या कम स्पष्ट, सॉफ्टवेयर में एन्ट्रॉपी का मुख्य कारण डेवलपर्स स्वयं है। वे आलसी हैं, उनके पास योग्यता की कमी है, विशेष रूप से सनका, जिनके साथ आप काम करते हैं। वह कई सवाल पूछता है!
मैं इस राय से पूरी तरह असहमत हूं। मेरे अनुभव में, एन्ट्रापी का मुख्य कारण नेतृत्व है, खासकर झरना प्रबंधन शैली वाली कंपनियों में।
जेराल्ड वेनबर्ग के रूप
में परामर्श के रहस्य में उल्लेख किया:
भले ही यह एक विशुद्ध रूप से तकनीकी समस्या है, लेकिन इसके मूल को हमेशा प्रबंधन की कार्रवाई या निष्क्रियता का पता लगाया जा सकता है।
मुझे पता है कि तुमने क्या सोचा: “तुम गलत हो! प्रबंधन हमेशा सब कुछ के लिए जिम्मेदार नहीं है! डेवलपर्स के लिए हर चीज के लिए मालिकों को दोष देना सुविधाजनक है! "
मैं यह नहीं कह रहा हूं कि नेतृत्व हर चीज के लिए दोषी है, लेकिन उसके पास हमेशा
कुछ हद तक जिम्मेदारी है । क्या डेवलपर ने कुछ बुरा किया? आपको हायरिंग प्रक्रिया की समीक्षा करने की आवश्यकता है। विनिर्देशों को खराब तरीके से लागू किया गया था? शायद कुछ नेताओं को नहीं पता कि वे वास्तव में क्या चाहते हैं, और इसलिए विनिर्देशों उनके लिए मायने नहीं रखती हैं।
इसलिए, एक नेता होना इतना मुश्किल है! आप पदानुक्रम में जितने लंबे होते हैं, उतना ही कठिन होता है।
डेवलपर्स के रूप में, आप निर्णय लेने को कितना प्रभावित करते हैं? यदि 100% है, तो बधाई हो, आपको हर चीज के लिए दोषी मानना है। यदि 0% पर है, तो आपकी गलती नहीं है। इन ध्रुवों के बीच प्रभाव का पूरा स्पेक्ट्रम निहित है। और यह झरना बड़ी संख्या में नहीं है।
Scrum, Kanban और पोकर योजना का उपयोग? बेशक आप झरने का उपयोग नहीं करते हैं! आप एजाइल का उपयोग उसी तरह करते हैं जैसे एक बच्चा पेचकश के साथ एक घर बनाता है।
बेशक, उपकरण महत्वपूर्ण हैं, लेकिन उनका महत्व
आपके सोचने के तरीके के महत्व से बहुत कम है , जो सही सॉफ्टवेयर विकास के लिए आवश्यक है। चंचल प्रकट करने के लिए बोली:
व्यक्तित्व और इंटरैक्शन प्रक्रियाओं और उपकरणों की तुलना में अधिक महत्वपूर्ण हैं।
स्क्रैम का उपयोग करने का मतलब यह नहीं है कि आप एजाइल का उपयोग कर रहे हैं, खासकर यदि आपके पास सोचने का तरीका नहीं है कि यह पद्धति सिखाने की कोशिश कर रही है।
झरने के प्रबंधन के साथ, आपसे अधिक कोई व्यक्ति निर्णय लेता है, उच्चतर, अन्य लोग नए निर्णय लेते हैं, और इसी तरह।
पदानुक्रम के निचले स्तरों पर ऐसे कर्मचारी होते हैं जिनका अभिशाप सभी निर्णयों का पालन करना है। उनका कार्य क्या है? बनाने के लिए, जैसे कि एक कार कारखाने की विधानसभा लाइन पर श्रमिक। उन्हें सोचने की जरूरत नहीं है,
उन्हें कार बनानी होगी ।
बुरी खबर: एक डेवलपर के रूप में, आप पदानुक्रम के निचले भाग में होंगे।
यदि शीर्ष पर कोई व्यक्ति आवेदन के कार्यों के संबंध में निर्णय लेता है, और आपके पास निर्णय लेने की प्रक्रिया को प्रभावित करने का व्यावहारिक रूप से कोई अवसर नहीं है, तो झरने में आपका स्वागत है! दुर्भाग्य से, सबसे अधिक बार वरिष्ठ प्रबंधन यह नहीं देखता है कि
सॉफ्टवेयर विकास की दुनिया में कोई उत्पादन चरण नहीं है । डेवलपर्स
सिस्टम के
डिजाइन में लगे हुए हैं, और यह कार्य केबिन के कन्वेयर असेंबली से बहुत दूर है।
क्यों? क्योंकि, एक कार के विपरीत, एप्लिकेशन लगातार बदल रहे हैं! आपको उन्हें सही ढंग से
डिज़ाइन करने की आवश्यकता है ताकि वे काम करें, उपयोगकर्ताओं की आवश्यकताओं को पूरा करें, कि अनुप्रयोगों में स्वीकार्य प्रदर्शन हो, कि वे परिवर्तनशील और बदलाव के प्रतिरोधी हों, जबकि निम्न स्तर पर एन्ट्रापी बनाए रखें। ऐसा करने के लिए, आपको अपने कोड में व्यावसायिक ज्ञान को
प्रतिबिंबित करने के तरीके के बारे में कई
निर्णय लेने की आवश्यकता है।
यदि आप उस जटिलता को प्रभावित नहीं करते हैं जो नेतृत्व आपके लिए उतरता है, तो आपको कोड में इसे प्रबंधित करने में बहुत प्रयास करना होगा। इसे एक "आवश्यक" जटिलता माना जाएगा: जिसे टाला नहीं जा सकता है।
संभावित परिणाम? एन्ट्रापी का स्तर बहुत तेजी से बढ़ सकता है।
संभव समाधान
कंपनी को संयुक्त रूप से निर्णय लेने और जिम्मेदारी के साथ सक्रिय रूप से अभ्यास करने की आवश्यकता है।
यदि आप अपनी कंपनी को मेरे द्वारा वर्णित जलप्रपात मॉडल में पहचानते हैं, तो आपको उन लोगों के साथ बात करने की ज़रूरत है जो निर्णय लेते हैं:
- डेटा और मजबूत तर्क क्यों और कैसे सुविधा एक्स या वाई को सरल बनाने के लिए दें। अब और भविष्य में एक जटिल विशेषता विकसित करने के संभावित मूल्य की व्याख्या करें।
- बताएं कि एजाइल सॉफ्टवेयर विकास का मतलब है कि लोगों को एक साथ काम करने की आवश्यकता है। प्रबंधकों, डिजाइनरों, डेवलपर्स और बाकी सभी को व्यावसायिक आवश्यकताओं के आधार पर निर्णय लेने की प्रक्रिया का हिस्सा होना चाहिए।
- यदि आपका नेतृत्व स्वचालित रूप से प्रस्ताव को अस्वीकार करता है, तो आपको यह समझने की आवश्यकता है कि उसने ऐसा क्यों किया। प्रश्न पूछें।
- इस बारे में बात करें कि निर्णयकर्ता सबसे महत्वपूर्ण क्या मानते हैं: पैसा और समय। उन्हें दिखाएं कि चंचल-शैली की सोच (और न केवल उपकरण) आप दोनों को बचा सकते हैं।
हालांकि, यदि आपको इसके बारे में नहीं पूछा गया है, तो समस्या को हल करने की कोशिश करना मुश्किल है। कई प्रबंधक झरने के मॉडल से बहुत खुश हैं, और अक्सर यह भी नहीं जानते हैं कि वे इसका पालन कर रहे हैं। आपको बहुत कूटनीति और चातुर्य की आवश्यकता होगी।
यह सब देखते हुए, अगर आपको लगता है कि व्यावसायिक समाधान आपके आवेदन में बहुत अधिक जटिलता जोड़ते हैं, और यह कि आप इसके बारे में कुछ भी नहीं कर सकते हैं यदि आप कोशिश करते हैं, तो मैं आपको एक और नौकरी खोजने की सलाह देता हूं। यह थकावट है - हर दिन उच्च एन्ट्रॉपी के साथ काम करने के लिए, और आनंद का एक फूला हुआ उत्पाद बनाने के लिए पर्याप्त नहीं है ... या इसका उपयोग करें। यह आपको उस सफलता के बारे में संकेत दे सकता है जो आपके उत्पाद को उम्मीद है।
और अंतिम: व्यवसाय के स्तर पर जो जटिल दिख सकता है, उसे सरल बनाया जा सकता है यदि आप व्यवसाय प्रक्रियाओं को अच्छी तरह जानते हैं। यह अत्यंत महत्वपूर्ण है। इसलिए, अपनी कंपनी की गतिविधियों के बारे में और जानें कि वे क्या कर रहे हैं और क्या नहीं कर रहे हैं, इससे सुविधाओं और कोड आधार को सरल बनाने में मदद मिलेगी।
जैसा कि हम अपनी वास्तुकला को व्यक्त करते हैं, हम कंप्यूटर को कुछ समझाते हैं। और इसके लिए हमें अच्छी तरह से समझने की जरूरत है कि हम क्या समझाते हैं।
डोनाल्ड कोड़ाकोड गुणवत्ता और तकनीकी कर्तव्य
समस्या
व्यवसाय द्वारा शुरू की गई "आवश्यक" जटिलता के अलावा, सॉफ़्टवेयर में एन्ट्रापी कोड गुणवत्ता और तकनीकी ऋण से निकटता से संबंधित है।
तकनीकी ऋण क्या है? सीधे शब्दों में कहें, ये सरलीकरण (हैक) हैं जो आप समय बचाने के लिए उपयोग करते हैं, यह जानते हुए कि बाद में यह आपके पास वापस आ सकता है। विशेष रूप से ऐसे मामलों में जहां अन्य विशेषताएं इन हैक पर निर्भर करती हैं: आपको इसे वास्तविक ब्याज के साथ, कठिनाइयों और सिरदर्द के रूप में ब्याज के साथ ठीक करना होगा।
आपके आवेदन के कार्य के आधार पर, तकनीकी ऋण कम या ज्यादा स्वीकार्य हो सकता है। यदि कार्यक्रम को कुछ महीनों तक रहना चाहिए, तो आप तकनीकी ऋण, एन्ट्रापी या गुणवत्ता के बारे में बिल्कुल नहीं सोच सकते हैं। बस कोड के टुकड़े एक साथ रखें और आपका काम हो गया!
उदाहरण के लिए, खरोंच से अधिक जटिल एप्लिकेशन बनाने से पहले यह एक अस्थायी समाधान हो सकता है। या इसलिए आप विचार को स्पष्ट करने के लिए एक प्रोटोटाइप लिख सकते हैं, और फिर सब कुछ फिर से लिख सकते हैं या अवधारणा को छोड़ सकते हैं।
दूसरी ओर, कंपनियां आमतौर पर लंबे समय तक रहने वाले एप्लिकेशन विकसित करना चाहती हैं। यह उचित है: किसी एप्लिकेशन को फिर से लिखना बहुत महंगा हो सकता है (विशेषकर यदि यह बड़ा है), और कोई भी गारंटी नहीं दे सकता है कि इसका एंट्रोपी स्तर कम होगा। नकल करना एक बहुत ही जोखिम भरा व्यवसाय है।
ऐसे मामलों में, आपको तकनीकी कर्तव्य और कोड गुणवत्ता के साथ बहुत सावधान रहने की आवश्यकता है। यह एक डेवलपर के रूप में आपके काम का एक महत्वपूर्ण हिस्सा है।
प्रसिद्ध पुस्तक
द प्रैजमैटिक प्रोग्रामर (जिसमें, अन्य बातों के अलावा,
डीआरवाई सिद्धांत पेश किया गया है) में, तकनीकी ऋण का एक दिलचस्प सादृश्य दिया गया है। यहां एक अध्ययन में वर्णित किया गया है कि शहरी इमारतों के विनाश की तुलना ... खिड़कियों से बाहर खटखटाया गया। टूटी खिड़की क्षेत्र में हर बदमाशी को प्रेरित करते हुए, परित्याग की छाप देती है। नतीजतन, टूटी हुई खिड़कियों वाली इमारतों को पूरी खिड़कियों वाले भवनों की तुलना में तेजी से बर्बरता मिलती है।
तकनीकी ऋण आपके कोड में एक सरलीकरण या हैक है, एक टूटी हुई खिड़की है। जब कोई अन्य डेवलपर, या यहां तक कि आप भविष्य में अपने आप को, यह नोटिस करते हैं, तो और भी अधिक तकनीकी ऋण जोड़ने का प्रलोभन होगा, क्योंकि "यहां अभी भी एक बुरा कोड है, तो क्यों ऊंची उड़ान भरना?"
उदाहरण: आपने एक जटिल बग के लिए वर्कअराउंड लिखा है, क्योंकि इसे देखने का कोई समय नहीं था। इस समाधान के शीर्ष पर एक और डेवलपर (या आप बाद में खुद) एक और समस्या को हल करते हुए, अलग कोड लिख सकते हैं। वर्कअराउंड की परतें जिन्हें कोई भी कभी भी समझ नहीं पाएगा वह बहुत जल्दी बढ़ेगा।
निर्णय
सबसे पहले, आपको कैसे पता चलेगा कि किसी कोड में तकनीकी ऋण है?
खुद से पूछें:
- क्या मैं बस और तार्किक रूप से समझा सकता हूं कि कोड क्या करता है?
- क्या यहां सही नामों का इस्तेमाल किया गया है? क्या वे यह समझाने में मदद करते हैं कि कोड क्या करता है?
- "DeleteUserAndShutDown" जैसे "और" के साथ लंबे नाम लागू करें? यह एक अच्छा संकेत है कि आपको किसी फ़ंक्शन, विधि या किसी अन्य निर्माण को अलग करने की आवश्यकता है।
- क्या ऐसा महसूस होता है कि आलस्य के कारण कुछ कोड जोड़ा गया था? क्या यह तर्क और अशुद्ध समझ का उल्लंघन करता है?
जितना अधिक आपका ज्ञान और अनुभव बढ़ता है, आप उतने ही जिज्ञासु होते हैं और जितनी बार आप अन्य डेवलपर्स के साथ स्वस्थ चर्चा करते हैं, उतनी ही बार आप तकनीकी ऋण के पैटर्न पर ध्यान देंगे। यह
एक चोक वाला
कोड है ।
ऐसे पैटर्न का सामना करते समय, कृपया उन्हें और भी तकनीकी ऋण जोड़ने की अनुमति न दें:
- तकनीकी लंबी वृद्धि से नई समस्याएं पैदा होंगी। वे वापस लौटेंगे और आपको (और आपकी टीम को) और भी आगे बढ़ाएंगे।
- एक तकनीकी ऋण मिले, इसे रिफलेक्टर करें। यह सबसे अच्छा विकल्प है। यदि आपके पास समय या ऊर्जा नहीं है, तो बस एक टिप्पणी जोड़ें // TODO: इस और उस कारण के लिए रिफ्लेक्टर। किसी समस्या की रिपोर्ट करें, उसे कोड आधार में छिपाकर न रखें।
यह मत भूलो कि आपको अन्य विशेषताओं के विकास के साथ समानांतर में रिफ्लेक्टर करने की आवश्यकता है ताकि वे वर्तमान वास्तुकला से मेल खाएं। सीधे शब्दों में कहें, तकनीकी ऋण की मरम्मत एक स्वतंत्र कार्य नहीं होना चाहिए, लेकिन एक सतत प्रक्रिया जो वर्तमान कार्य से संबंधित नहीं हो सकती है। एक विशेषता विकसित करते समय, अपने आप को मिले तकनीकी ऋण को सही करने का अधिकार दें।
एक समय में कोड के छोटे टुकड़े को रिफ्लेक्टर करते हैं और अक्सर यह सुनिश्चित करने के लिए परीक्षण चलाते हैं कि सिस्टम उम्मीद के मुताबिक व्यवहार कर रहा है।
अंत में, refactoring के दौरान, आपको कुछ अच्छे तर्क की आवश्यकता हो सकती है:
- पहला, अपने लिए। यह सोचना आसान है कि आपका सहकर्मी प्रोग्राम करने में सक्षम नहीं है और आप दूसरों से बेहतर जानते हैं। लेकिन अगर आप रिफैक्टरिंग के विशिष्ट लाभ नहीं देखते हैं, तो नहीं। शायद पूरी बात केवल आपके अहंकार में है, और आप कुछ बर्बाद कर सकते हैं।
- यदि रीफ़ैक्टरिंग कोड शैली से संबंधित है, तो इसका मतलब है कि आपकी टीम ने इसे स्पष्ट रूप से परिभाषित नहीं किया है। एक बैठक करें और एक साथ तय करें कि आप किस शैली का कोड अपनाना चाहते हैं। इसे नीचे कहीं लिखा जाना चाहिए, ताकि हर कोई आवश्यकतानुसार संभाल सके। टीम की जरूरतों के अनुसार समझौते को संपादित करें। अन्यथा, आपका कोड टिप्पणियों से भर जाएगा जैसे कि "हम टैब का उपयोग करते हैं !!!" नहीं !!!!! 11! 1 !!! ”। यह एक बेकार शोर है।
- अंत में, यदि कोई आपसे पूछता है कि आपने उसका सुंदर कोड क्यों बदला, तो आपको अपने निर्णय को समझाने के लिए वास्तविक तर्क होंगे।
अच्छे तर्क हमेशा भविष्य में सकारात्मक भूमिका निभाते हैं। उदाहरण के लिए, तृतीय-पक्ष लाइब्रेरी को लपेटना ताकि यह आपके कोड आधार में रिसाव का कारण न बने। यदि आप यह नहीं समझ पा रहे हैं कि मैं लीक के बारे में क्यों बात कर रहा हूँ, तो
मैंने अमूर्तता के बारे में जो
लिखा है उसे पढ़ें।
मध्यम और दीर्घ अवधि में पूर्वानुमान लगाना हम मनुष्यों के लिए कठिन है। इसलिए, किसी अनजान भविष्य के लिए आंख के साथ रिफ्लेक्टर या "बेचना" कुछ आसान नहीं है।
तकनीकी कर्तव्य
सरल और
सही मार्ग के बीच द्वैतवाद को दर्शाता है। पहला तेज़ और आकर्षक है, दूसरा आपके प्रोजेक्ट को स्केलेबल और बनाए रखने में आसान बना देगा। आपको जितनी बार संभव हो दूसरा रास्ता चुनने के लिए
आत्म-अनुशासन की आवश्यकता होगी। अन्यथा, भविष्य दुख से भर जाएगा।
यदि आप बहुत थके हुए, परेशान या अन्य विचारों या भावनाओं से भरे हुए हैं जो आपकी प्रेरणा को सही मार्ग पर ले जाने के लिए कम करते हैं, और सरल नहीं है, तो यह अभी तक प्रोग्राम नहीं करना बेहतर है। टहलें, सहकर्मियों से बात करें, विराम लें। ताजा दिमाग के साथ कोड पर लौटें।
सबसे अधिक बार, तकनीकी ऋण डिबगिंग के दौरान जोड़ा जाता है। यदि आप वर्कअराउंड
जोड़कर बग को ठीक करते हैं, तो आपने कुछ भी तय नहीं किया है। बग बना हुआ है, इसे चलाने के लिए मुश्किल है और गलती से यह मिल गया है। आपको कोड
को हटाने ,
बदलने या पूरी तरह से
हटाने के लिए बग को ठीक करने की आवश्यकता है। फिर यह सुनिश्चित करने के लिए कोड का परीक्षण करें कि बग दोबारा नहीं होता है।
अंतिम: गलतियों के लिए सहयोगियों को दोषी ठहराना अनुत्पादक है। यदि आप अपने कोड आधार के बारे में खराब या व्यंग्यात्मक तरीके से बोलते हैं, तो इससे समस्याएं भी हल नहीं होंगी, यह केवल स्थिति को खराब करेगा। टीम भावना को नष्ट न करें। आपको प्रोजेक्ट में एन्ट्रापी को कम करने की आवश्यकता है, न कि इसे मौखिक रूप से नष्ट करने की।
स्वचालित परीक्षण
समस्या
सॉफ्टवेयर विकास की जादुई दुनिया में मेरे लिए कुछ आकर्षक है, खासकर स्टार्टअप्स में: कई प्रोग्रामर अभी भी स्वचालित परीक्षण नहीं लिखना चाहते हैं।
यह मुझे क्यों मोहित करता है? इंजीनियरिंग के अन्य सभी क्षेत्रों में, वे एक कठोर प्रक्रिया का पालन करके परीक्षण करते हैं। जब आप एक रॉकेट का निर्माण करते हैं, तो आपको कई प्रणालियों का परीक्षण करने की आवश्यकता होती है, या रॉकेट गिर जाएगा। वही कार, पुल, हवाई जहाज - कुछ भी के लिए चला जाता है।
पैसे की बचत ।
एक सरल उदाहरण:
नासा अपने कोड का अच्छी तरह से परीक्षण कर रहा है (नियम 5 देखें) ।
, , ,
.
, , .
. .
, , — , . ? , . , , ( ), , - .
, : ,
. ,
.
, .
निर्णय
, , , .
.
- 1,3 . , . «» .
:
, , - ( ), :
- . , , .
- . , , - .
- . — , .
- , - . , - . !
- , . !
,
.
, . , . , .
, , .
.
, , . , , - .
, , . , , :
, . , . . , , , - , .
— , .
, .
,
:
. , , .
?
— . - , . , .
वह सब है! , .
, , .
, , : « , , ? , . !».
: , . , . , .
, , , . , , . !
. :
, . , . , , .
, , . ?
, . , , .
:
- , . «, ?» — , « ! ! !».
- , . , , , , . «, , ?» « , 289 ».
, . ,
!
( !) .
. , , .
, — , , . !
!
, , , ,
. ? ? - ? ?
. , . -, . , , , .
, , . . — .
So. ?
- — . . , .
- — .
- . / .
- , , .
- , . , .
- एक ऐसा वातावरण बनाएं, जो संयुक्त प्रोग्रामिंग, कोड विश्लेषण, या बस जानकारी के दिलचस्प स्रोतों (लेख, किताबें) के लिए लिंक बिछाने के माध्यम से एक दूसरे के साथ ज्ञान साझा करना आसान बनाता है।
आदर्श सॉफ्टवेयर मौजूद नहीं है। एन्ट्रॉपी हमेशा हमारे काम का हिस्सा होगा। इसका मतलब यह नहीं है कि हम पहले ही यह लड़ाई हार चुके हैं। इसका मतलब है कि पूरे कोड आधार में एन्ट्रापी को कम करना पहले से ही एक जीत है!उपयोगी लिंक: