जिस कोड में हम रहते हैं

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

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

मैं सारा मेव की शानदार रिपोर्ट "लिवेबल कोड" का अनुवाद प्रस्तावित करता हूं, जो पाठ के करीब है, जहां वह इन सभी मुद्दों पर विचार करती है।

एक मॉडल होना क्यों महत्वपूर्ण है?

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

सॉफ्टवेयर डेवलपमेंट प्रोसेस दो संबंधित, इंटरैक्टिंग का एक संयोजन है, लेकिन फिर भी अलग-अलग इकाइयाँ: कोड और टीम।

इसकी पुष्टि कॉनवे का कानून है। इन संस्थाओं का संबंध हमें बताता है कि कोड में समस्याएं टीम में समस्याओं से संबंधित हैं और इसके विपरीत। इसलिए, हमारे पास उन्हें हल करने के लिए दो विकल्प हैं: कोड पक्ष पर और टीम की तरफ।

कुछ समस्याएं केवल कोड के साथ समस्या लगती हैं, कुछ केवल टीम के साथ। वास्तव में, ये सभी दोनों घटकों के साथ समस्याएं हैं। इसलिए, नया मॉडल आधुनिक वास्तविकताओं के लिए उपयुक्त होना चाहिए और विकास प्रक्रिया के दोनों घटकों के बीच संबंध को प्रतिबिंबित करना चाहिए।

नए मॉडल का वर्णन

वह स्थान जिसमें एप्लिकेशन रहता है

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

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

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

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

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

अभी भी हमारे उद्योग में निर्माण कार्य की एक बड़ी मात्रा है, लेकिन हम में से अधिकांश अभी भी अंदरूनी (अनुप्रयोगों) पर काम कर रहे हैं।

विकास में नया लक्ष्य

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

Livable Code क्या है?

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

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

कोड के लिए Livable का मतलब एक ही है: आप जो चाहें बदल सकते हैं या जोड़ सकते हैं, लेकिन अत्यधिक जटिलता और झुंझलाहट के बिना। आप समझते हैं कि क्या है, इसलिए आसानी से कोड में सही जगह पर जाएं और इसके साथ काम करें। यहां सिद्धांत समान है: एक टीम के लिए रहने योग्य तथ्य दूसरे के लिए उपयुक्त नहीं है। एक सीनियर और चार जूनियर्स के लिए रहने योग्य क्या पांच सीनियर्स के लिए रहने योग्य है , और एक आउटसोर्स टीम के लिए रहने योग्य से बहुत अलग है।

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

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

कैसे एक परियोजना अव्यवस्थित हो जाती है

लेकिन क्या होगा अगर आपका कोड इस कमरे की तरह दिखता है? इसे टीम के लिए उपयुक्त कैसे बनाया जाए? कहाँ से शुरू करें?

सहमत हूं, चीजों को क्रम में कैसे रखा जाए, यह समझने के लिए यहां-वहां घूमना मुश्किल है। इस राज्य में घर क्यों पहुँचते हैं? अक्सर कहा जाता है कि यह आलस्य है। मनोवैज्ञानिक अलग तरीके से सोचते हैं: घर गलत तरीके से गलत निर्णयों की एक श्रृंखला के कारण ऐसी स्थिति में आता है।

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

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

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

हैबिट्स में बदलाव के माध्यम से मुक्ति

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

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

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

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

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

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

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

टीम की आदतें

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

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

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

दो चरम सीमाएं अपरिवर्तनीय हैं या किताबें काम क्यों नहीं करती हैं

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

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

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

हमें सहज महसूस करने के लिए थोड़ी गड़बड़ चाहिए। यह अपार्टमेंट और कोड दोनों के लिए सही है।

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

इसके अलावा, ये दोनों चरम एक ही परियोजना में एक साथ मौजूद हो सकते हैं। कभी-कभी एक-दूसरे के पड़ोस में भी। लिवेबल कोड कहीं बीच में है। साथ ही साथ रहने के लिए एक आरामदायक जगह है, यह कहीं न कहीं पत्रिकाओं के कवर से तस्वीरें और बरबाद अपार्टमेंट के बीच है।

इसलिए, आपको थोड़ी सी अव्यवस्था लेने में सक्षम होने की आवश्यकता है क्योंकि यह अंतरिक्ष को रहने योग्य बनाता है।

घोषणापत्र

आप कह सकते हैं: “यह सब, ज़ाहिर है, बहुत दिलचस्प है, लेकिन क्या होगा अगर मेरा कोड पहले से ही पूरी तरह से अव्यवस्थित है? या क्या होगा अगर परियोजना इतनी बुरी नहीं है, लेकिन मैं यह सुनिश्चित करना चाहता हूं कि यह गलत दिशा में नहीं बढ़ रहा है? "

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

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

यहाँ यह कैसे करना है। चार नियम हैं जो किसी भी भाषा और ढांचे पर लागू होते हैं।

कोई नुकसान नहीं

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

लगातार सुधारों पर विश्वास करें

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

वर्कफ़्लो का हाउसकीपिंग हिस्सा बनाएं

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

संपर्क में रहें

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

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

निष्कर्ष

— . — . , , , , .

. — . , , , , .

संदर्भ

2. , ,
3. बॉब मार्टिन से संबंधित सिद्धांत